CVE-2024-45806
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedEnvoy is a cloud-native high-performance edge/middle/service proxy. A security vulnerability in Envoy allows external clients to manipulate Envoy headers, potentially leading to unauthorized access or other malicious actions within the mesh. This issue arises due to Envoy's default configuration of internal trust boundaries, which considers all RFC1918 private address ranges as internal. The default behavior for handling internal addresses in Envoy has been changed. Previously, RFC1918 IP addresses were automatically considered internal, even if the internal_address_config was empty. The default configuration of Envoy will continue to trust internal addresses while in this release and it will not trust them by default in next release. If you have tooling such as probes on your private network which need to be treated as trusted (e.g. changing arbitrary x-envoy headers) please explicitly include those addresses or CIDR ranges into `internal_address_config`. Successful exploitation could allow attackers to bypass security controls, access sensitive data, or disrupt services within the mesh, like Istio. This issue has been addressed in versions 1.31.2, 1.30.6, 1.29.9, and 1.28.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceEnvoy proxy incorrectly trusted all RFC1918 private addresses as internal by default, allowing external clients on those networks to manipulate x-envoy headers and bypass security controls within the service mesh.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data< 1.28.7>= 1.29.0, < 1.29.9>= 1.30.0, < 1.30.6>= 1.31.0, < 1.31.2CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- Low
- Availability
- None
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Determine installed Envoy versionRun `envoy --version` or check the container/daemon metadata to find the exact version numberAffected if The version is < 1.28.7, >= 1.29.0 and < 1.29.9, >= 1.30.0 and < 1.30.6, or >= 1.31.0 and < 1.31.2
-
Check if internal_address_config is explicitly configuredSearch Envoy configuration files (YAML/JSON) for the `internal_address_config` setting under the bootstrap or listener configurationAffected if The setting is absent and Envoy uses the default behavior of treating all RFC1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) as internal
-
Inspect listener configuration for external network exposureReview Envoy listener definitions to identify if any listeners bind to RFC1918 addresses that are accessible to untrusted external clientsAffected if Listeners accept connections from RFC1918 addresses that are not truly trusted internal networks (e.g., guest WiFi, shared hosting networks)
-
Examine header handling for x-envoy internal validationCheck if Envoy configuration relies on x-envoy-internal header or remote IP validation for access control decisionsAffected if Security policies trust x-envoy-internal headers or internal address classification without explicit configuration
You are affected if your Envoy version falls within the vulnerable ranges AND you have not explicitly configured internal_address_config AND your Envoy listeners accept connections from RFC1918 networks that contain untrusted external clients.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped1.28.71.29.91.30.6
Upgrade to Envoy versions 1.31.2, 1.30.6, 1.29.9, or 1.28.7; alternatively, explicitly configure internal_address_config to only include truly trusted CIDR ranges.
Upgrade to Envoy 1.31.2 (or 1.30.6/1.29.9/1.28.7 depending on your release cadence)
- 1. Identify the current Envoy version running in your environment using `envoy --version` or checking your deployment manifests
- 2. Select an appropriate fixed version from: 1.31.2, 1.30.6, 1.29.9, or 1.28.7 (prefer 1.31.2 for the latest stable release with the fix)
- 3. Update your package manager or container image to the selected fixed version
- 4. If you have tooling or probes on private networks that need to be trusted (e.g., to modify x-envoy headers), explicitly add those addresses/CIDR ranges to the `internal_address_config` in your Envoy configuration
- 5. Deploy the upgraded Envoy version
- 6. Verify the new version is running: `envoy --version`
- 7. Test that your mesh services (including Istio) function correctly after the upgrade
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation4.0 h
- Implementation8.0 h
- Testing4.0 h
- Review / QA2.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $5,120.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2024-45806 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2024-45806 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data