Indico Indico vulnerabilities

Indico is an event management system that uses Flask-Multipass, a multi-backend authentication system for Flask. Prior to 3.3.13, users who can create content, including speakers who can create minutes, can store crafted HTML in event minutes. When concurrent edits are made to the same minutes, the minute editor conflict UI can execute attacker-controlled script in the viewer's browser in the Indico origin. This issue is fixed in version 3.3.13.

Indico is an event management system that uses Flask-Multipass, a multi-backend authentication system for Flask. Prior to 3.3.13, users who can manage events or create content, including speakers who can upload material, can store crafted javascript URLs in fields that accept custom URLs. A user who follows one of these URLs can execute attacker-controlled script in the user's browser in the Indico origin. This issue is fixed in version 3.3.13.

Indico is an event management system that uses Flask-Multipass, a multi-backend authentication system for Flask. Prior to 3.3.13, an authenticated user can misuse the legacy session export API to retrieve details for a restricted session without access to that session, as long as the containing event is accessible. The missing access check can disclose session metadata such as the title, description, and conveners. This issue is fixed in version 3.3.13.

Indico is an event management system that uses Flask-Multipass, a multi-backend authentication system for Flask. Prior to 3.3.13, the previous fix for CVE-2026-25738 did not cover an edge case, allowing an event organizer to submit a crafted URL that points to a prohibited local target but is accepted as valid by Indico. The organizer can read data returned by the target through affected Indico features. This issue is fixed in version 3.3.13.

Indico is an event management system that uses Flask-Multipass, a multi-backend authentication system for Flask. In versions prior to 3.3.11, the API endpoint used to manage event series is missing an access check, allowing unauthenticated/unauthorized access to this endpoint. The impact of this is limited to getting the metadata (title, category chain, start/end date) for events in an existing series, deleting an existing event series, and modifying an existing event series. This vulnerability does NOT allow unauthorized access to events (beyond the basic metadata mentioned above), nor any kind of tampering with user-visible data in events. Version 3.3.11 fixes the issue. As a workaround, use the webserver to restrict access to the series management API endpoint.

Indico is an event management system that uses Flask-Multipass, a multi-backend authentication system for Flask. Versions prior to 3.3.10 are vulnerable to cross-site scripting when uploading certain file types as materials. Users should upgrade to version 3.3.10 to receive a patch. To apply the fix itself updating is sufficient, but to benefit from the strict Content Security Policy (CSP) Indico now applies by default for file downloads, update the webserver config in case one uses nginx with Indico's `STATIC_FILE_METHOD` set to `xaccelredirect`. For further directions, consult the GitHub Security advisory or Indico setup documentation. Some workarounds are available. Use the webserver config to apply a strict CSP for material download endpoints, and/or only let trustworthy users create content (including material uploads, which speakers can typically do as well) on Indico.

Indico is an event management system that uses Flask-Multipass, a multi-backend authentication system for Flask. Versions prior to 3.3.10 are vulnerable to server-side request forgery. Indico makes outgoing requests to user-provides URLs in various places. This is mostly intentional and part of Indico's functionality but is never intended to let users access "special" targets such as localhost or cloud metadata endpoints. Users should upgrade to version 3.3.10 to receive a patch. Those who do not have IPs that expose sensitive data without authentication (typically because they do not host Indico on AWS) are not affected. Only event organizers can access endpoints where SSRF could be used to actually see the data returned by such a request. For those who trust their event organizers, the risk is also very limited. For additional security, both before and after patching, one may also use the common proxy-related environment variables (in particular `http_proxy` and `https_proxy`) to force outgoing requests to go through a proxy that limits requests in whatever way you deem useful/necessary. These environment variables would need to be set both on the indico-uwsgi and indico-celery services.