GHSA-Q3G2-M552-3R9C

Vulnerability from github – Published: 2026-07-24 21:52 – Updated: 2026-07-24 21:52
VLAI
Summary
swift-nio-http2: Missing CR/LF/NUL validation in header values
Details

Summary

SwiftNIO HTTP/2 was missing validation on inbound HEADERS frames that let CR, LF, NUL, SP and other control characters reach an HTTP/1.1 backend through NIOHTTP2's HTTP/2-to-HTTP/1 codec, enabling HTTP request smuggling or response splitting.

Impact

Two related gaps in inbound header validation, against any application using HTTP2ToHTTP1Codec (or HTTP2FramePayloadToHTTP1Codec) to front an HTTP/1.1 backend:

Regular header field values were only checked against a forbidden-name list (connection, transfer-encoding, proxy-connection, keep-alive, upgrade); the value itself was never inspected. An attacker-controlled regular header field value containing CR or LF passed validation and, once serialized as name: value CRLF by the codec, terminated the field early and injected extra header lines into the outbound HTTP/1.1 message.

Pseudo-header values (:path in particular) were only checked against CR, LF and NUL. A :path value containing SP serializes into the request-target of METHOD SP request-target SP HTTP-version CRLF, so a value like /a HTTP/1.1 produces GET /a HTTP/1.1 HTTP/1.1 — a parser-differential request line depending on whether a downstream reader takes the first or last SP-delimited token as the version.

Neither of these is reachable on a stock pipeline: NIOHTTP1's outbound validator (enableOutboundHeaderValidation, on by default) already rejects these characters on write. The exposure is pipelines that skip outbound validation, or any code that reads validated-looking HTTPRequestHead.headers and forwards the values on trusting that HTTP/2 already checked them.

Fix

Fixed in 48bfd90 and 45bdf67.

Mitigation

Upgrade to 1.45.0

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "SwiftURL",
        "name": "swift-nio-http2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.45.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-64785"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113",
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T21:52:10Z",
    "nvd_published_at": "2026-07-23T20:17:21Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nSwiftNIO HTTP/2 was missing validation on inbound HEADERS frames that let\nCR, LF, NUL, SP and other control characters reach an HTTP/1.1 backend\nthrough NIOHTTP2\u0027s HTTP/2-to-HTTP/1 codec, enabling HTTP request smuggling\nor response splitting.\n\n## Impact\n\nTwo related gaps in inbound header validation, against any application\nusing HTTP2ToHTTP1Codec (or HTTP2FramePayloadToHTTP1Codec) to front an\nHTTP/1.1 backend:\n\nRegular header field values were only checked against a forbidden-name\nlist (connection, transfer-encoding, proxy-connection, keep-alive,\nupgrade); the value itself was never inspected. An attacker-controlled\nregular header field value containing CR or LF passed validation and, once\nserialized as `name: value CRLF` by the codec, terminated the field early\nand injected extra header lines into the outbound HTTP/1.1 message.\n\nPseudo-header values (`:path` in particular) were only checked against\nCR, LF and NUL. A `:path` value containing SP serializes into the\nrequest-target of `METHOD SP request-target SP HTTP-version CRLF`, so a\nvalue like `/a HTTP/1.1` produces `GET /a HTTP/1.1 HTTP/1.1` \u2014 a\nparser-differential request line depending on whether a downstream reader\ntakes the first or last SP-delimited token as the version.\n\nNeither of these is reachable on a stock pipeline: NIOHTTP1\u0027s outbound\nvalidator (`enableOutboundHeaderValidation`, on by default) already rejects\nthese characters on write. The exposure is pipelines that skip outbound\nvalidation, or any code that reads validated-looking `HTTPRequestHead.headers`\nand forwards the values on trusting that HTTP/2 already checked them.\n\n## Fix\n\nFixed in 48bfd90 and 45bdf67.\n\n## Mitigation\n\nUpgrade to 1.45.0",
  "id": "GHSA-q3g2-m552-3r9c",
  "modified": "2026-07-24T21:52:10Z",
  "published": "2026-07-24T21:52:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apple/swift-nio-http2/security/advisories/GHSA-q3g2-m552-3r9c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64785"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apple/swift-nio-http2/commit/45bdf670248be5f16ec0340e125dca285536f0fb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apple/swift-nio-http2/commit/48bfd9067d7d1d15c4789440127a0cf36222ea43"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apple/swift-nio-http2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apple/swift-nio-http2/releases/tag/1.45.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "swift-nio-http2: Missing CR/LF/NUL validation in header values"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…