CVE-2022-3918 in swift-corelibs-foundation
Summary
by MITRE • 01/20/2023
A program using FoundationNetworking in swift-corelibs-foundation is potentially vulnerable to CRLF ( ) injection in URLRequest headers. In this vulnerability, a client can insert one or several CRLF sequences into a URLRequest header value. When that request is sent via URLSession to an HTTP server, the server may interpret the content after the CRLF as extra headers, or even a second request. For example, consider a URLRequest to http://example.com/ with the GET method. Suppose we set the URLRequest header "Foo" to the value "Bar Extra-Header: Added GET /other HTTP/1.1". When this request is sent, it will appear to the server as two requests: GET / HTTP/1.1 Foo: Bar Extra-Header: Added GET /other HTTP/1.1 In this manner, the client is able to inject extra headers and craft an entirely new request to a separate path, despite only making one API call in URLSession. If a developer has total control over the request and its headers, this vulnerability may not pose a threat. However, this vulnerability escalates if un-sanitized user input is placed in header values. If so, a malicious user could inject new headers or requests to an intermediary or backend server. Developers should be especially careful to sanitize user input in this case, or upgrade their version of swift-corelibs-foundation to include the patch below.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 04/02/2025
The vulnerability described in CVE-2022-3918 represents a critical server-side request forgery issue within the swift-corelibs-foundation library's FoundationNetworking implementation. This flaw specifically affects applications that utilize URLSession to make HTTP requests, creating a pathway for malicious actors to manipulate HTTP header values through CRLF (Carriage Return Line Feed) injection techniques. The vulnerability stems from insufficient input validation and sanitization of header values, allowing attackers to insert CRLF sequences that can alter the structure of HTTP requests being transmitted. When a URLRequest contains a header value with embedded CRLF characters, these sequences can cause the HTTP server to interpret subsequent content as additional headers or even a completely separate HTTP request, fundamentally altering the request's intended behavior and potentially enabling unauthorized access to backend systems.
The technical execution of this vulnerability relies on the HTTP protocol's fundamental parsing mechanism where CRLF sequences serve as delimiters between HTTP headers and the request body. In the specific scenario described, when a header value contains the string "Bar Extra-Header: Added GET /other HTTP/1.1", the HTTP server processes this as two distinct requests rather than a single request with a malformed header value. This occurs because HTTP parsers treat CRLF sequences as request terminators, allowing an attacker to inject additional HTTP headers or even entire HTTP requests that bypass normal request validation. The vulnerability operates at the application layer (layer 7) and can be classified under CWE-115 as "Improper Neutralization of CRLF Sequences in HTTP Headers" and CWE-94 as "Improper Control of Generation of Code ('Code Injection')". The attack vector aligns with ATT&CK technique T1071.004 for Application Layer Protocol: DNS, though the specific implementation involves HTTP protocol manipulation rather than DNS.
The operational impact of this vulnerability extends beyond simple header injection, potentially enabling attackers to perform unauthorized operations against backend services or intermediate proxies that process these malformed requests. When user input flows directly into HTTP header values without proper sanitization, malicious actors can craft requests that redirect traffic, inject malicious headers, or even construct entirely new requests to different endpoints within the same network. This creates a significant risk for applications that process untrusted input in header values, particularly those that rely on HTTP-based authentication or authorization mechanisms. The vulnerability becomes especially dangerous when combined with other weaknesses such as insecure header validation or lack of proper input filtering, as it can be exploited to bypass security controls and gain unauthorized access to internal resources. Applications using swift-corelibs-foundation versions prior to the patched release are particularly at risk, as the vulnerability allows for sophisticated attacks that can compromise the integrity and confidentiality of HTTP communications.
Mitigation strategies for this vulnerability require immediate attention from developers and system administrators. The primary recommendation involves upgrading to patched versions of swift-corelibs-foundation that properly sanitize header values and prevent CRLF injection. Additionally, developers should implement comprehensive input validation and sanitization for all user-provided data that may be used in HTTP headers, ensuring that CRLF sequences are properly escaped or removed before header values are constructed. Organizations should also consider implementing network-level controls such as HTTP request filtering and header validation at reverse proxies or API gateways to detect and block malformed requests. The implementation of proper logging and monitoring for suspicious header patterns can help detect exploitation attempts. Security teams should conduct thorough code reviews focusing on HTTP header construction and user input handling, particularly in areas where HTTP requests are dynamically built from external data sources. This vulnerability highlights the importance of following secure coding practices and adhering to the principle of least privilege in HTTP request processing, as well as maintaining up-to-date dependencies to protect against known vulnerabilities in third-party libraries.