Impact A legacy API to retrieve session details could be misused to retrieve metadata (such as title, description and conveners) of a restricted session within without having access to that session, as long as the event itself was accessible.
Patches You should to update to Indico 3.3.13 as soon as possible. See the docs for instructions on how to update.
Workarounds Restrict access to the event itself
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
Impact Indico makes outgoing requests to user-provides URLs in various places. This is mostly intentional and part of Indico's functionality, but of course it is never intended to let you access "special" targets such as localhost or cloud metadata endpoints. The previous fix (CVE-2026-25738) did not cover an edge case so it was still possible to craft a URL that pointed to a local target but was accepted as valid by Indico.
Patches You should to update to Indico 3.3.13 as soon as possible. See the docs for instructions on how to update.
Workarounds If you do not have IPs that expose sensitive data without authentication (typically because you do not host Indico on AWS), this vulnerability doesn't impact you and you can ignore it (but please upgrade anyway). Also, only event organizers can access endpoints where SSRF could be used to actually see the data returned by such a request. So if you trust your event organizers, the risk is also very limited.
For additional security, both before and after patching, you could also use the common proxy-related environment variables (in particular httpproxy and httpsproxy) 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. Please note that setting up such a proxy is not something we can help you with.
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
[!NOTE] If server-side LaTeX rendering is not in use (ie XELATEXPATH was not set in indico.conf), this vulnerability does not apply.
Impact Due to vulnerabilities in TeXLive and obscure LaTeX syntax that allowed circumventing Indico's LaTeX sanitizer, it is possible to use specially-crafted LaTeX snippets which can read local files or execute code with the privileges of the user running Indico on the server.
Patches It is recommended to update to Indico 3.3.12 as soon as possible. See the docs for instructions on how to update.
It is also strongly recommended to enable the containerized LaTeX renderer (using podman), which isolates it from the rest of the system. See the docs for details - it is very easy and from now on the only recommended/supported way of using LaTeX.
Workarounds Remove the XELATEXPATH setting from indico.conf (or comment it out or set it to None) and restart the indico-uwsgi and indico-celery services to disable LaTeX functionality.
For more information For any questions or comments about this advisory:
- Open a thread in the forum - Send an email to indico-team@cern.ch
Impact 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: This just removes the series metadata, ie (if enabled) the links between events in the same series and the lecture series number in the event title - Modifying an existing event series: Just like for deleting, it would only allow to toggle the metadata display. It could also be used to set an event title pattern for the series, but this is only used when cloning an event from that series.
That 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.
Patches Developers should to update to Indico 3.3.11 as soon as possible. See the docs for instructions on how to update.
Workarounds - Developers can configure their webserver to restrict access to the series management API endpoint
For more information If there are any questions or comments about this advisory:
- Open a thread in our forum - Email Indico privately at indico-team@cern.ch
Impact There is a Cross-Site-Scripting vulnerability when uploading certain file types as materials.
Patches You should to update to Indico 3.3.10 as soon as possible. See the docs for instructions on how to update.
Please be aware that to apply the fix itself updating is sufficient, but to benefit from the strict Content-Security-Policy we now apply by default for file downloads, you need to update your webserver config in case you use nginx with Indico's STATICFILEMETHOD set to xaccelredirect and add the following line to the .xsf/indico/ location block (you can consult the Indico setup documentation for the full configuration snippet):
nginx addheader Content-Security-Policy $upstreamhttpcontentsecuritypolicy;
Workarounds - Use your webserver config to apply a strict CSP for material download endpoints. - Only let trustworthy users create content (including material uploads, which speakers can typically do as well) on Indico.
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
Impact Indico makes outgoing requests to user-provides URLs in various places. This is mostly intentional and part of Indico's functionality, but of course it is never intended to let you access "special" targets such as localhost or cloud metadata endpoints.
Patches You should to update to Indico 3.3.10 as soon as possible. See the docs for instructions on how to update.
Workarounds If you do not have IPs that expose sensitive data without authentication (typically because you do not host Indico on AWS), this vulnerability doesn't impact you and you can ignore it (but please upgrade anyway). Also, only event organizers can access endpoints where SSRF could be used to actually see the data returned by such a request. So if you trust your event organizers, the risk is also very limited.
For additional security, both before and after patching, you could also use the common proxy-related environment variables (in particular httpproxy and httpsproxy) 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. Please note that setting up such a proxy is not something we can help you with.
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
Impact There is a Cross-Site-Scripting vulnerability during account creation when redirecting after the account has been successfully created. Exploitation requires the user to initiate the account creation process with a maliciously crafted link, and then finalize the signup process. Because of this, it can only target newly created (and thus unprivileged) Indico users so the benefits of exploiting it are very limited.
Patches You should to update to Indico 3.3.4 as soon as possible. See the docs for instructions on how to update.
Workarounds - If you build the Indico package yourself and cannot upgrade for some reason, you can simply update the flask-multipass dependency to >=0.5.5 which fixes the vulnerability. You would do that by editing requirements.txt before building the package (see commit 7dcb573837), or possibly cherry-picking that particular commit. - Otherwise you could configure your web server to disallow requests containing a query string with a parameter that starts with javascript:
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch
Impact There is a Cross-Site-Scripting vulnerability in confirmation prompts commonly used when deleting content from Indico. Exploitation requires someone with at least submission privileges (such as a speaker) and then someone else to attempt to delete this content.
Considering that event organizers may want to delete suspicious-looking content when spotting it, there is a non-negligible risk of such an attack to succeed. The risk of this could be further increased when combined with some some social engineering pointing the victim towards this content.
Patches You need to update to Indico 3.2.6 as soon as possible. See the docs for instructions on how to update.
Workarounds Only let trustworthy users manage categories, create events or upload materials ("submission" privileges on a contribution/event). This should already be the case in a properly-configured setup when it comes to category/event management.
Note that a conference doing a Call for Abstracts actively invites external speakers (who the organizers may not know and thus cannot fully trust) to submit content, hence the need to update to a a fixed version ASAP in particular when using such workflows.
For more information
If you have any questions or comments about this advisory:
Open a thread in our forum Email us privately at indico-team@cern.ch
Impact An external audit of the Indico codebase has discovered a vulnerability in Indico's URL generation logic which could have allowed an attacker to make Indico send a password reset link with a valid token pointing to an attacker-controlled domain by sending that domain in the Host header. Had a user clicked such a link without realizing it does not point to Indico (and that they never requested it), it would have revealed their password reset token to the attacker, allowing them to reset the password for that user and thus take over their Indico account.
- If the web server already enforces a canonical host name, this cannot be exploited (this was not part of the default config from the Indico setup guide) - If only SSO is used (LOCALIDENTITIES set to False), the vulnerability cannot be exploited for password reset links, but other links in emails set by Indico could be tampered with in the same way (with less problematic impact though)
Patches You need to update to Indico 2.3.4 as soon as possible. See the docs for instructions on how to update.
Workarounds You can configure the web server to canonicalize the URL to the hostname used for Indico. See this commit for the changes in our setup docs; they can be easily applied to your existing web server config.
For more information If you have any questions or comments about this advisory:
- Open a thread in our forum - Email us privately at indico-team@cern.ch