CVE-2026-28970
CVE-2026-28970 is a security vulnerability in github.com/apple/swift-nio. O3 Security confirms whether CVE-2026-28970 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
SwiftNIO: CRLF Injection in outbound HTTP request URI via NIOHTTPRequestHeadersValidator
Real-World Exposure
github.com/apple/swift-nioReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects SwiftURL packages — download data is not available via public APIs for these ecosystems.
Description
Programs using swift-nio is vulnerable to HTTP request smuggling and HTTP response splitting attacks, caused by insufficient validation of outbound HTTP/1.1 request and response start line components.
This vulnerability affects all swift-nio versions from 2.0.0 to 2.99.0. It is fixed in 2.100.0 and later releases.
This vulnerability is caused by the NIOHTTPRequestHeadersValidator and NIOHTTPResponseHeadersValidator channel handlers only validating header field names and values, while leaving the request URI, request method, and response reason phrase unvalidated. An attacker who can influence the content of these fields — for example by controlling a URL path or a custom HTTP method in a proxy application — can inject CR/LF sequences or other control characters into the HTTP start line. This allows construction of arbitrary additional HTTP requests or responses on the wire, a classic HTTP request smuggling or HTTP response splitting attack.
Exploiting this vulnerability requires the attacker to influence the content of outbound HTTP start line fields. In proxy applications that forward attacker-controlled URIs or methods, this is straightforward. For clients, a malicious server that triggers a redirect to a crafted URL could exploit the URI validation gap. For servers, any client that can cause the server to emit a crafted response reason phrase could exploit the response splitting gap.
In vulnerable applications, where attacker controlled data is supplied to these fields, the attack is low-effort: injecting a CRLF sequence into a URI or reason phrase requires only a single crafted request. Successful exploitation can allow an attacker to smuggle additional HTTP requests past intermediaries or split HTTP responses, potentially bypassing WAFs or poisoning web caches. However, most applications are not vulnerable at all.
The risk can be mitigated by ensuring that all user-controlled input is sanitized before being used in HTTP start line components. However, this mitigation places the burden on application developers and is error-prone.
The issue is fixed by extending NIOHTTPRequestHeadersValidator to validate request URIs against the character set defined in RFC 9112 Section 3.2 and RFC 3986 Section 3, and to validate custom HTTP methods against the token grammar defined in RFC 9110. NIOHTTPResponseHeadersValidator is extended to validate custom response reason phrases against RFC 9112 Section 4. Applications that use these validator channel handlers — which are installed by default when using addHTTPClientHandlers() or addHTTPServerHandlers() — will reject invalid outbound messages with an HTTPParserError.invalidHeaderToken error rather than emitting them to the network.
SwiftNIO is grateful to @kuranikaran and @YLChen-007 for their reporting and assistance with the project's process.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦SwiftURL | github.com/apple/swift-nio | ≥ 2.0.0&&< 2.100.0 | 2.100.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/apple/swift-nio. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/apple/swift-nio to 2.100.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-28970 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-28970 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to CVE-2026-28970. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-28970 in your dependencies?
O3 detects CVE-2026-28970 across SwiftURL dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.