VYPR
← All advisories
Unrated severityOSV Advisory· Published Apr 25, 2019· Updated Aug 4, 2024

CVE-2019-9900

CVE-2019-9900

Description

When parsing HTTP/1.x header values, Envoy 1.9.0 and before does not reject embedded zero characters (NUL, ASCII 0x0). This allows remote attackers crafting header values containing embedded NUL characters to potentially bypass header matching rules, gaining access to unauthorized resources.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Envoy 1.9.0 and before does not reject HTTP/1.x headers with embedded NUL characters, allowing remote attackers to bypass header matching rules and potentially access unauthorized resources.

Vulnerability

Envoy versions 1.9.0 and before [1] do not reject embedded zero characters (NUL, ASCII 0x0) when parsing HTTP/1.x header values [2]. The HTTP/1.x codec, HTTP router, external authorization, rate limiting service, and access logging are among the affected components [2]. This condition is reachable by any remote client sending crafted headers containing NUL characters [2].

Exploitation

An attacker needs only network access to send an HTTP/1.x request with a header value containing embedded NUL characters; no authentication is required [2]. For example, if a route rule uses suffix matching to deny certain headers (e.g., deny any header ending with _special_cluster), an attacker can send x-foo: some_special_cluster\0. The header match logic in Envoy uses string_view, which ignores the NUL, so the deny rule is not triggered, but downstream cluster routing uses c_str, which terminates at the NUL, routing to the forbidden cluster [2]. Alternatively, an external authorization (ext_authz) filter may permit a request when the header value contains NUL, as the filter sees a truncated value, while the backend may interpret the full value (including NUL) if it does not reject NUL characters [2].

Impact

Successful exploitation allows an attacker to bypass header matching rules, potentially gaining access to unauthorized resources, such as routing requests to a forbidden cluster or bypassing authorization checks [1][2]. The CVSS score is 8.3 (High) with network attack vector, low complexity, no privileges required, and no user interaction, and the scope is changed (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L) [2].

Mitigation

Envoy fixed the vulnerability in version 1.9.1, released April 5, 2019, by rejecting HTTP/1.x headers with embedded NUL characters [1]. Users should upgrade to Envoy 1.9.1 or later. Red Hat also released an update for Istio-Proxy (used in Red Hat OpenShift Service Mesh) as RHSA-2019:0741, upgrading to servicemesh-proxy-0.9.1-1 [3]. No workaround is available for versions prior to 1.9.1.

References
  1. Version history — envoy tag-v1.9.1 documentation
  2. NUL characters in HTTP/1 headers allow access control bypass (CVE-2019-9900)
  3. https://access.redhat.com/errata/RHSA-2019:0741

AI Insight generated on May 26, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2

Patches

0

No patches discovered yet.

Vulnerability mechanics

Root cause

"Missing validation of HTTP/1.x header values allows embedded NUL characters, causing inconsistent views between string_view and c_str accessors."

Attack vector

An attacker sends an HTTP/1.x request containing a header value with an embedded NUL (0x00) character. Because Envoy's http-parser does not reject such values, the header is accepted and stored in a HeaderString. Two different accessors — `c_str()` and `getStringView()` — then see inconsistent views of the same header: `getStringView()` sees the full value including the NUL, while `c_str()` treats the NUL as a terminator and sees only the prefix. This inconsistency allows an attacker to craft header values that bypass route matching rules (e.g., suffix or exact matching) while still being routed to a different target via `c_str()`-based logic [ref_id=1].

Affected code

The vulnerability resides in the HTTP/1.x codec, specifically in how Envoy's http-parser integration handles header values. The advisory notes that the HTTP/1.x issue is the most serious, as it propagates deeply into Envoy's routing and authorization components [ref_id=1].

What the fix does

The advisory does not include a patch diff, but it states that the fix involves rejecting embedded NUL characters in HTTP/1.x header values during parsing. The remediation guidance is to upgrade to a version of Envoy that validates header values per RFC 7230 section 3.2.6, which prohibits NUL characters. No patch is published in this advisory, but the fix is expected to be included in a subsequent Envoy release [ref_id=1].

Preconditions

  • networkThe attacker must be able to send arbitrary HTTP/1.x requests to an Envoy proxy.
  • configThe Envoy configuration must use header matching rules (e.g., route matching, ext_authz) that rely on string_view-based comparisons.
  • authNo authentication is required; the attack is unauthenticated.

Generated on May 25, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

5

News mentions

0

No linked articles in our index yet.