CVE-2026-25738: 
Python vulnerability analysis and mitigation

CVE-2026-25738 is a Server-Side Request Forgery (SSRF) vulnerability in Indico, an open-source event management system developed by CERN. The flaw affects all versions of Indico prior to 3.3.10 and arises because the application makes outgoing HTTP requests to user-provided URLs without adequately restricting access to sensitive internal targets such as localhost or cloud metadata endpoints. The vulnerability was published on February 17, 2026, and patched in the same release. It carries a CVSS v3.1 base score of 4.3 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (Github Advisory).

The root cause is a combination of CWE-918 (Server-Side Request Forgery) and CWE-367 (Time-of-Check Time-of-Use / TOCTOU Race Condition). Indico's validate_request_url function performs a DNS lookup to check whether a user-supplied URL resolves to a private IP address before making the outbound request; however, an attacker can exploit DNS rebinding to pass this check — the initial DNS resolution returns a public IP, but a subsequent resolution (at connection time) returns a private/internal IP, bypassing the block. The patch (commit 70d3418) monkey-patches socket.getaddrinfo to cache resolved addresses per request context and raises an InsecureRequestError if a new resolution for the same host yields a private IP not seen in the first lookup, effectively closing the TOCTOU window (Github Commit, Github Advisory).

Successful exploitation allows an authenticated event organizer to cause the Indico server to issue HTTP GET requests to internal network resources, including localhost services and cloud instance metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254), and retrieve the responses. The impact is limited to confidentiality — no integrity or availability impact is expected — and is most severe in cloud-hosted deployments where metadata endpoints expose credentials or configuration without authentication. Organizations that do not expose sensitive unauthenticated services on internal IPs, or that fully trust their event organizers, face minimal practical risk (Github Advisory, Indico Release).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation as of the time of writing. The EPSS score is approximately 0.075% (roughly the 20th percentile), indicating a low near-term exploitation probability. Exploitation requires an attacker to hold event organizer privileges within an Indico instance, which limits the attack surface. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Github Advisory).

1. Obtain event organizer access: Register or compromise an account with event organizer privileges on a target Indico instance running a version prior to 3.3.10.
2. Identify SSRF-susceptible endpoints: Locate Indico features that accept user-provided URLs and trigger outbound server-side requests (e.g., Mastodon URL checks, LaTeX image retrieval, static site generation).
3. Set up a DNS rebinding server: Configure a malicious DNS server that initially resolves an attacker-controlled domain to a public IP (passing the is_private_url check), then rapidly switches the DNS response to a target internal IP (e.g., 169.254.169.254 for AWS metadata, or 127.0.0.1 for localhost services).
4. Submit the malicious URL: Supply the attacker-controlled domain as a user-provided URL in the relevant Indico endpoint, triggering the server-side request.
5. Retrieve sensitive data: The second DNS resolution at connection time returns the internal IP, causing Indico to fetch the internal resource. The response data is returned to the event organizer through the application's normal response flow, potentially exposing cloud credentials, internal API tokens, or other sensitive information (Github Advisory, Github Commit).

• Network: Outbound HTTP GET requests from the Indico server to 169.254.169.254 (AWS IMDSv1), fd00::/8 (IPv6 link-local), or other RFC-1918 addresses (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) that are not expected in normal operation.
• Network: Repeated DNS queries from the Indico server for the same hostname in rapid succession, potentially indicating DNS rebinding activity.
• Logs: Indico application logs showing InsecureRequestError: Possible DNS rebinding attack messages (present only after patching to 3.3.10).
• Logs: Web server or application logs recording event organizer accounts submitting unusual external URLs to Indico endpoints that trigger outbound requests (e.g., Mastodon profile URL fields, LaTeX image URLs).
• Logs: Unexpected HTTP responses from internal services appearing in Indico's response payloads or error logs.

Upgrade Indico to version 3.3.10 or later, which patches the DNS rebinding vector by caching getaddrinfo results and blocking subsequent resolutions that yield private IPs (Indico Release). As a defense-in-depth measure (applicable both before and after patching), configure the http_proxy and https_proxy environment variables on both the indico-uwsgi and indico-celery services to route outbound requests through a proxy that enforces allowlists or blocklists for internal IP ranges. Additionally, restrict event organizer privileges to fully trusted users, and implement network-level controls (e.g., host-based firewall rules or cloud security groups) to prevent the Indico server from reaching sensitive internal endpoints such as the cloud instance metadata service (Github Advisory).

The vulnerability was reported by three independent researchers (rahulgovind, inkz, and yueyueL) and was promptly addressed by the Indico maintainer (ThiefMaster) in the same release that disclosed it. A blog post from PentesterLab titled "When the patch doesn't fix the vulnerability" was published in a later timeframe, suggesting ongoing community interest in the completeness of the fix. Red Hat also tracked the advisory, indicating awareness among enterprise Linux distributors (Github Advisory).