CVE-2026-107449 in Heimdall
Summary
by MITRE • 10/08/2026
linuxserver Heimdall through 2.8.3 applies its SafeUrlFetcher SSRF protection mechanism only to ItemController; the enhanced-application test and live-stats requests occur via SupportedApps::execute(), a GuzzleHttp client that lacks IP address restrictions. In some realistic installations, the POST /test_config (and GET /get_stats) endpoints are accessible through CSRF, and thus an unauthenticated attacker can force the server to send requests to arbitrary internal hosts and ports (including 169.254.169.254) and read a status/port oracle in addition to partial response data.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in linuxserver Heimdall versions through 2.8.3 represents a critical Server-Side Request Forgery (SSRF) flaw resulting from an incomplete implementation of security controls within the application's request handling logic. While the developers implemented a SafeUrlFetcher mechanism to mitigate SSRF risks, this protection was narrowly scoped and applied exclusively to requests processed by the ItemController. This selective enforcement created a significant architectural gap where other critical endpoints remained exposed to malicious manipulation because they bypassed the IP address restriction checks designed to prevent access to internal or reserved network resources.
The technical root cause lies in the execution path for enhanced-application tests and live statistics, which are handled via SupportedApps::execute(). This function utilizes the GuzzleHttp client library to make outbound requests but fails to enforce strict allow-listing of destination IPs or domains. Consequently, an attacker can craft specific HTTP POST requests to the /test_config endpoint or GET requests to the /get_stats endpoint that instruct the server to connect to arbitrary internal hosts and ports. The lack of validation allows these requests to target sensitive infrastructure addresses, most notably the cloud metadata service at 169.254.169.254, which is commonly used by virtual machines and containers to retrieve instance-specific configuration data such as access keys and credentials.
From an operational perspective, this vulnerability poses a severe risk due to its potential for unauthenticated exploitation through Cross-Site Request Forgery (CSRF). In many realistic deployment scenarios where session cookies are not properly protected against CSRF attacks or when the application does not enforce strict origin checks on these specific endpoints, an attacker can trick an authenticated user into triggering malicious requests. Even without valid sessions in some configurations, the ability to force the server to interact with internal services allows for a sophisticated port scanning and service enumeration technique known as a status oracle. By analyzing response times or error messages from different ports, attackers can map out the internal network topology and identify running services that are not directly exposed to the public internet.
Furthermore, the SSRF capability enables partial data exfiltration. When the server fetches content from an attacker-controlled URL or an internal service like the metadata endpoint, parts of the response body may be reflected back in the application's output or error messages. This allows attackers to retrieve sensitive information such as AWS IAM role credentials, Docker registry tokens, or other secrets stored within the container environment. The combination of SSRF and CSRF effectively transforms a local configuration testing feature into a powerful remote code execution precursor by facilitating lateral movement and credential theft from within the compromised host.
This vulnerability aligns with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws where web applications fetch resources specified by users without validating them against an allow-list of expected destinations. Additionally, it maps to MITRE ATT&CK technique T1504, specifically the sub-technique for Web Session Hijacking if CSRF is leveraged, and T1651 which covers Cloud Infrastructure Discovery using SSRF to probe internal metadata services. The failure to apply consistent security controls across all HTTP handlers highlights a common oversight in application development where protective measures are added incrementally without a holistic review of the request lifecycle.
To mitigate this vulnerability, immediate remediation should focus on enforcing strict IP allow-listing for all outbound requests made by GuzzleHttp clients within the SupportedApps::execute() function, mirroring the protections already present in ItemController. Developers must ensure that any endpoint capable of initiating network connections validates destination addresses against a predefined list of trusted domains and explicitly blocks access to private RFC 1918 address ranges as well as link-local addresses like 169.254.0.0/16. Implementing egress filtering at the container or host level provides an additional layer of defense by restricting outbound traffic to only necessary external endpoints. Furthermore, applying robust CSRF protections such as synchronizer tokens and strict SameSite cookie attributes will prevent attackers from forcing authenticated users to execute these malicious requests. Regular security audits should verify that all code paths involving network I/O are subject to the same rigorous validation standards to eliminate similar blind spots in future updates.