CVE-2026-120633 in CGI
Summary
by MITRE • 11/04/2026
CGI versions before 5.00 for Perl trust the client X-Forwarded-Host header in url, self_url, virtual_host and virtual_port.
These take the host name and port from the X-Forwarded-Host request header when present, and otherwise from Host, without validating either. The URLs from url and self_url are the default redirect location and the start_html(-base=>1) base href, and the default start_form action when REQUEST_URI is not set.
A client can poison shared caches, and URLs the application stores or sends, with redirects, links and scripts that point at a host it controls.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
CGI versions prior to 5.00 for Perl contain a critical input validation flaw related to how they process HTTP headers during URL generation. The vulnerability stems from the unconditional trust placed in the X-Forwarded-Host header when determining the hostname and port for various internal functions such as url, self_url, virtual_host, and virtual_port. In standard web architectures behind reverse proxies or load balancers, this header is commonly used to convey the original client's host information since the direct connection appears to originate from the proxy rather than the end user. However, CGI.pm fails to validate whether this header originates from a trusted source or if it has been tampered with by an untrusted party. Consequently, any HTTP request containing a maliciously crafted X-Forwarded-Host header will cause these functions to generate URLs based on attacker-controlled data instead of the legitimate server configuration.
The operational impact of this flaw is significant because the generated URLs serve as foundational elements for web application behavior and security controls. Specifically, the url and self_url functions determine the default redirect location after form submissions or authentication processes. Additionally, they define the base href used in HTML headers via start_html with a base parameter set to one, which influences how relative links are resolved by browsers. Furthermore, these values dictate the action attribute for forms generated by start_form when the REQUEST_URI environment variable is not explicitly provided. If an attacker can manipulate these URLs through header injection, they effectively control where users are redirected after interactions and what resources their browser considers as part of the application's origin context.
This lack of validation enables several severe attack vectors including cache poisoning, cross-site scripting, and session hijacking. By injecting a malicious domain into the X-Forwarded-Host header, an attacker can poison shared caches such as CDNs or reverse proxy caches with links pointing to their controlled server. This means that subsequent legitimate users may be served cached responses containing scripts or redirects directed at the attacker's infrastructure. Moreover, if these poisoned URLs are embedded in HTML pages sent back to clients, it facilitates stored cross-site scripting attacks where malicious JavaScript executes within the context of the trusted domain. Attackers can also use this mechanism for phishing by crafting redirect links that appear legitimate but lead to fraudulent sites designed to steal credentials or distribute malware.
From a classification perspective, this vulnerability aligns with CWE-601 URL Redirection to Untrusted Site and CWE-295 Improper Certificate Validation in the context of trusting external headers without verification. It also maps to MITRE ATT&CK techniques such as T1189 Drive-by Client Side Injection where attackers exploit vulnerabilities to deliver malicious content, and potentially T1498 Network Denial via Service Exhaustion if cache poisoning leads to resource exhaustion or service degradation for legitimate users. The core issue is a failure in input validation specifically regarding the source of HTTP headers used for constructing absolute URLs within server-side logic.
To mitigate this vulnerability, organizations should upgrade CGI.pm to version 5.00 or later where these issues have been addressed with improved handling of forwarded headers. For systems that cannot immediately update due to compatibility constraints, administrators can implement a workaround by configuring the web server or reverse proxy to strip or override the X-Forwarded-Host header before it reaches the Perl application if it does not match expected values. Alternatively, developers should avoid relying on CGI.pm's automatic URL generation for security-critical redirects and instead hardcode trusted base URLs within the application logic. It is also advisable to implement strict Content Security Policy headers to mitigate potential script injection resulting from any residual exposure until full remediation is achieved. Regular auditing of header handling practices across all web-facing applications remains essential to prevent similar trust boundary violations in other components.