CVE-2026-25738: Indico Event Management SSRF Vulnerability

CVE-2026-25738 Overview

CVE-2026-25738 is a Server-Side Request Forgery (SSRF) vulnerability affecting Indico, an event management system that uses Flask-Multipass for multi-backend authentication. The vulnerability exists in versions prior to 3.3.10 and allows attackers to make the server perform unintended outgoing requests to user-controlled URLs.

Indico makes outgoing requests to user-provided URLs as part of its core functionality. However, the application failed to properly restrict access to "special" targets such as localhost, internal network addresses, and cloud metadata endpoints. This SSRF vulnerability can be exploited via DNS rebinding techniques to bypass URL validation and access sensitive internal resources.

Critical Impact
Attackers can leverage this SSRF vulnerability to access internal services, cloud metadata endpoints (particularly dangerous on AWS), and sensitive data that should not be accessible from external networks.

Affected Products

Indico versions prior to 3.3.10
Deployments hosted on cloud platforms (AWS, GCP, Azure) with accessible metadata endpoints
Environments where event organizers are untrusted

Discovery Timeline

2026-02-19 - CVE CVE-2026-25738 published to NVD
2026-02-19 - Last updated in NVD database

Technical Details for CVE-2026-25738

Vulnerability Analysis

This SSRF vulnerability stems from insufficient URL validation when Indico processes user-provided URLs for outgoing requests. The flaw is compounded by a Time-of-Check Time-of-Use (TOCTOU) race condition (CWE-367) in the DNS resolution process, commonly known as DNS rebinding.

In a DNS rebinding attack, an attacker controls a malicious DNS server that initially resolves a hostname to a safe IP address during validation, then rapidly changes the DNS response to point to an internal IP address (such as 127.0.0.1 or 169.254.169.254 for AWS metadata) when the actual request is made. This allows attackers to bypass URL blocklist protections.

The vulnerability is particularly concerning for cloud-hosted instances where metadata endpoints expose sensitive information such as IAM credentials, instance configuration, and other cloud provider secrets. Only event organizers can access the endpoints where SSRF responses are visible, which provides some risk mitigation for environments with trusted organizers.

Root Cause

The root cause is a TOCTOU race condition (CWE-367) in URL validation. The application validates the destination IP address at one point in time but the DNS resolution may return a different IP address when the actual HTTP request is made. This gap between validation and use allows DNS rebinding attacks to succeed.

The fix introduces patch_socket_getaddrinfo() which patches the socket address resolution mechanism to protect against DNS rebinding by ensuring consistent IP address validation throughout the request lifecycle.

Attack Vector

The attack is network-based and requires no authentication for initial access, though viewing the SSRF response data requires event organizer privileges. An attacker could:

Set up a malicious DNS server with a short TTL
Configure the DNS to initially return a safe external IP address
Submit a URL to Indico using the attacker-controlled domain
The DNS quickly rebinds to an internal IP (localhost, cloud metadata, etc.)
Indico makes the request to the internal resource
The attacker (if an event organizer) can view the response containing sensitive data

python

# Security patch in indico/__init__.py - Protect against SSRF via DNS rebinding (#7283)
# Source: https://github.com/indico/indico/commit/70d341826116fac5868719a6133f2c26d9345137

 # LICENSE file for more details.
 
 from indico.util.mimetypes import register_custom_mimetypes
+from indico.util.network import patch_socket_getaddrinfo
 
 
 __version__ = '3.3.10-dev'
 PREFERRED_PYTHON_VERSION_SPEC = '~=3.12.2'
 
 register_custom_mimetypes()
+patch_socket_getaddrinfo()

The patch imports and applies patch_socket_getaddrinfo() at application startup to ensure DNS resolution is protected throughout the application lifecycle.

Detection Methods for CVE-2026-25738

Indicators of Compromise

Outbound HTTP/HTTPS requests from Indico to internal IP ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x, 127.0.0.1)
Requests to cloud metadata endpoints (169.254.169.254 on AWS, metadata.google.internal on GCP)
Unusual DNS queries with very short TTL values followed by rapid IP changes
Event organizer accounts making repeated requests to external URLs that resolve to internal addresses

Detection Strategies

Monitor web application firewall (WAF) logs for outbound requests to RFC 1918 private IP ranges
Implement network segmentation monitoring to detect traffic from Indico servers to sensitive internal services
Review Indico application logs for URL submission patterns that may indicate SSRF probing
Deploy DNS monitoring to detect rebinding attempts with short TTL values

Monitoring Recommendations

Configure alerting for any Indico server connections to cloud metadata IP addresses (169.254.169.254)
Implement egress filtering rules and monitor for bypass attempts
Enable verbose logging for Indico's URL processing functions
Monitor for unusual event organizer activity patterns that could indicate exploitation attempts

How to Mitigate CVE-2026-25738

Immediate Actions Required

Upgrade Indico to version 3.3.10 or later immediately
Review recent event organizer activity for suspicious URL submissions
Audit any data that may have been accessed via SSRF if exploitation is suspected
Implement network-level egress filtering to block requests to internal IP ranges and cloud metadata endpoints

Patch Information

The vulnerability is fixed in Indico version 3.3.10. The patch introduces DNS rebinding protection via the patch_socket_getaddrinfo() function imported from indico.util.network. This ensures that URL validation and request execution use consistent IP address resolution, preventing TOCTOU attacks.

Update to the patched version using your package manager or by downloading from the GitHub Release v3.3.10. The specific fix can be reviewed in the GitHub Commit Details.

Workarounds

Configure HTTP proxy environment variables (http_proxy and https_proxy) to route all outbound requests through a filtering proxy
Apply these environment variables to both the indico-uwsgi and indico-celery services
Implement network-level egress filtering to block requests to localhost, private IP ranges, and cloud metadata endpoints
Limit event organizer privileges to trusted users only, as SSRF response data is only visible to organizers

bash

# Configuration example - Set proxy environment variables for Indico services
# Add to indico-uwsgi and indico-celery service configurations

export http_proxy="http://your-filtering-proxy:8080"
export https_proxy="http://your-filtering-proxy:8080"
export no_proxy="localhost,127.0.0.1"

# For systemd services, add to the [Service] section:
# Environment="http_proxy=http://your-filtering-proxy:8080"
# Environment="https_proxy=http://your-filtering-proxy:8080"