CVE-2026-120639 in CGI
Summary
by MITRE • 11/04/2026
CGI versions before 5.00 for Perl allow HTTP header injection via entity decoding after the newline check in header and unchecked values in multipart_start and do_push.
With autoEscape off, header decodes HTML entities in extra header values after its newline check, so an encoded CR or LF reaches the response. multipart_start does not check header values for newlines, and do_push does not check the type it prints in each part.
An application that passes request data into these header values can be made to add headers or split the response.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in CGI versions prior to 5.00 for Perl represents a critical HTTP Header Injection flaw rooted in insufficient input validation and improper handling of encoded characters within the module's core functions. This issue specifically affects the processing of extra header values, multipart form data boundaries, and push headers used in server-push scenarios. The root cause lies in the sequence of operations performed by the CGI.pm library when parsing incoming HTTP requests or constructing responses. In a secure implementation, any user-supplied input intended for HTTP headers must be strictly validated to ensure it contains no control characters such as carriage returns (CR) or line feeds (LF), which are used to delimit header fields and terminate messages in the HTTP protocol. The failure to enforce this validation consistently across different code paths allows attackers to inject arbitrary data into the HTTP response stream, potentially leading to cache poisoning, cross-site scripting attacks via injected headers, or session hijacking if cookies can be manipulated through crafted responses.
The technical mechanism of exploitation involves two distinct vectors within the CGI.pm module: the handling of extra header values and the processing of multipart form data. In the first vector, when autoEscape is disabled, the library decodes HTML entities in extra header values after performing a newline check. This ordering error means that while literal newlines might be caught by an initial validation step, encoded representations such as %0D%0A (URL-encoded CR LF) or <CR><LF> are decoded into their actual control character equivalents only after the safety check has already passed. Consequently, these injected carriage return and line feed characters reach the HTTP response layer unimpeded. This allows an attacker to break out of the intended header field and inject additional headers or even a complete new HTTP response body by appending CRLF sequences followed by malicious content.
The second vector involves the multipart_start function, which is responsible for initiating multipart/form-data responses often used in file uploads or complex form submissions. This function fails to validate header values for newline characters before writing them to the output stream. Similarly, the do_push function, utilized for HTTP server push mechanisms, does not verify the type of data being printed in each part of a multi-part response. The lack of sanitization in these functions means that if an application passes user-controlled request data directly into header values or multipart boundaries without additional filtering, an attacker can inject arbitrary headers or corrupt the structure of the multipart message. This structural corruption can lead to parsing errors on the client side or allow for the injection of malicious scripts and other payloads within the response body itself.
The operational impact of this vulnerability is severe, particularly for web applications that rely heavily on CGI.pm for handling HTTP requests and responses. By exploiting header injection, an attacker can manipulate cache behavior by injecting Cache-Control headers to poison shared caches with malicious content or disrupt legitimate caching strategies. More critically, if the application reflects user input in headers without proper encoding, it may facilitate Cross-Site Scripting (XSS) attacks where injected scripts are executed in the context of the victim's browser session. Furthermore, attackers could potentially forge Set-Cookie headers to hijack user sessions, alter authentication states, or perform clickjacking by injecting X-Frame-Options headers with permissive values. The ability to split responses also allows for response splitting attacks, where a single request results in two distinct HTTP responses being sent back to the client, complicating security monitoring and potentially bypassing web application firewalls that expect standard one-to-one request-response patterns.
Mitigation strategies must focus on immediate patching and robust input validation practices. The primary remediation is to upgrade CGI.pm to version 5.00 or later, where these specific flaws have been addressed with stricter validation logic that checks for control characters after all decoding operations are complete. For applications unable to immediately update the library, developers should implement rigorous input sanitization on any data passed into header values, multipart boundaries, and push types. This includes explicitly rejecting or encoding carriage return (0x0D) and line feed (0x0A) characters in user-supplied inputs before they are processed by CGI functions. Additionally, setting the autoEscape option to true can provide an additional layer of protection by ensuring that HTML entities are handled safely, although this should not be relied upon as a sole defense mechanism given the specific flaw related to post-decode validation gaps.
From a classification perspective, this vulnerability aligns with CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component and CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers. In terms of attack behavior, it maps to the MITRE ATT&CK technique T1059 Command and Scripting Interpreter if used for XSS payloads or T1189 Drive-by Compromise if leveraged for cache poisoning leading to malware distribution. Security teams should prioritize patching this vulnerability due to its direct impact on HTTP protocol integrity and potential for widespread exploitation in legacy Perl-based web applications that have not been migrated to modern frameworks with built-in protections against header injection attacks.