☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]

CVE-2024-45806

CVE-2024-45806 Unauthorized Access in Envoy
📅 PUBLISHED: 2024-09-19 23:34 UTC 🔄 UPDATED: 2026-09-23 20:25 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: CONFIRMED — 3+ independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.38%
👁️
0.38% probability
9.4× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Patch available — upgrade to latest release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
6.5
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-45806 is a security vulnerability in Envoy proxy that allows external attackers to manipulate Envoy-specific headers (e.g., x-envoy-*) by exploiting the default trust boundary configuration. Envoy historically treated all RFC1918 private IP addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) as internal by default, even when internal_address_config was empty. This means any client with a spoofed source IP from these ranges could inject or modify internal headers, potentially bypassing security controls, accessing sensitive data, or disrupting service mesh operations (e.g., in Istio). The vulnerability has a CVSS score of 6.5 (Medium) and affects all Envoy versions prior to 1.31.2, 1.30.6, 1.29.9, and 1.28.7. No public exploit code or PoC is available at this time.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

Envoy is a critical component in many cloud-native environments, often deployed as a sidecar proxy in service meshes like Istio. This vulnerability impacts the supply chain by potentially allowing external attackers to impersonate internal services, manipulate routing, or bypass authentication. Organizations using Envoy in their infrastructure should treat this as a high-priority update, as the default behavior change may break existing configurations that rely on automatic trust of private IPs.

CVSS Breakdown & Threat Level

  • CVSS Score: 6.5 (Medium)
  • Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
  • Attack Vector: Network (AV:N) – Exploitable remotely without physical access.
  • Attack Complexity: Low (AC:L) – No special conditions required.
  • Privileges Required: None (PR:N) – No authentication needed.
  • User Interaction: None (UI:N) – No user action required.
  • Scope: Unchanged (S:U) – Vulnerability affects only the vulnerable component.
  • Confidentiality Impact: Low (C:L) – Limited information disclosure possible.
  • Integrity Impact: Low (I:L) – Limited modification of data possible.
  • Availability Impact: Low (A:L) – Limited service disruption possible.

Threat Level: Medium. While the CVSS score is moderate, the potential for bypassing security controls in service mesh environments (e.g., Istio) elevates the risk. The lack of public exploits reduces immediate threat, but the widespread use of Envoy makes this a significant concern for cloud-native deployments.

Deep Dive & Mechanics

Envoy uses the concept of "internal addresses" to determine trust for certain headers, such as x-envoy-external-address, x-envoy-decorator-operation, and x-envoy-downstream-service-cluster. By default, Envoy considered any request originating from an RFC1918 private IP address as internal, allowing those requests to set or modify these headers. This behavior was intended for internal network traffic but could be abused by external attackers who spoof their source IP to appear as if they are from a private range.

The vulnerability arises because the default internal_address_config was empty, yet Envoy still treated RFC1918 addresses as internal. The fix changes this behavior so that only explicitly configured addresses or CIDR ranges in internal_address_config are considered internal. In the current release, the old default is preserved for backward compatibility, but a future release will remove this automatic trust.

Attack Scenario: An external attacker sends a request with a spoofed source IP in the 10.0.0.0/8 range and includes a malicious x-envoy-external-address header. Envoy, believing the request is internal, trusts the header and forwards it to upstream services, potentially bypassing access controls or manipulating routing decisions.

Vulnerable vs. Patched Code

Vulnerable Configuration (Default):

# Envoy configuration with empty internal_address_config
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 0.0.0.0, port_value: 10000 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          codec_type: AUTO
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: service_cluster }
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
# No internal_address_config specified

Patched Configuration (Explicit Trust):

# Envoy configuration with explicit internal_address_config
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 0.0.0.0, port_value: 10000 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          codec_type: AUTO
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: service_cluster }
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
          internal_address_config:
            cidr_ranges:
            - address_prefix: 10.0.0.0
              prefix_len: 8
            - address_prefix: 172.16.0.0
              prefix_len: 12
            - address_prefix: 192.168.0.0
              prefix_len: 16

Key Difference: In the patched version, internal_address_config must be explicitly defined to trust any IP ranges. Without it, no addresses are considered internal, preventing header manipulation from external sources.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

  • A vulnerable Envoy instance (version < 1.31.2, < 1.30.6, < 1.29.9, < 1.28.7) with default configuration.
  • Ability to send HTTP requests with spoofed source IP (e.g., using curl with --interface or raw socket programming).

Lab Setup:

  1. Deploy a vulnerable Envoy proxy using Docker:
    docker run -d --name envoy-vuln -p 10000:10000 envoyproxy/envoy:v1.28.6
    
  2. Create a simple backend service (e.g., using Python):
    from http.server import HTTPServer, BaseHTTPRequestHandler
    class Handler(BaseHTTPRequestHandler):
        def do_GET(self):
            self.send_response(200)
            self.end_headers()
            self.wfile.write(b"Backend response")
    HTTPServer(('0.0.0.0', 8080), Handler).serve_forever()
    
  3. Configure Envoy to route to the backend (use the vulnerable config above).

Exploitation Steps:

  1. Send a request with a spoofed source IP from a private range and a malicious x-envoy-external-address header:

    curl -H "x-envoy-external-address: 10.0.0.1" --interface lo http://localhost:10000/
    

    Note: Spoofing source IP may require raw socket capabilities or a local network setup.

  2. Observe that Envoy trusts the header and forwards it to the backend, potentially bypassing access controls.

Expected Outcome: The backend receives the manipulated header, demonstrating the vulnerability.

Blue Team (Detection & Defense)

Detection:

  • Monitor for requests with x-envoy-* headers originating from external networks.
  • Log and alert on any requests from private IP ranges that are not expected to be internal.
  • Use network flow analysis to detect IP spoofing attempts.

Defense:

  • Immediately upgrade Envoy to patched versions (1.31.2, 1.30.6, 1.29.9, 1.28.7).
  • Explicitly configure internal_address_config with trusted CIDR ranges.
  • Implement network segmentation to prevent external spoofing of private IPs.
  • Use eBPF or other kernel-level tools to detect and block IP spoofing.

Indicators of Compromise (IOCs)

  • Network Indicators:
    • HTTP requests containing x-envoy-external-address, x-envoy-decorator-operation, or x-envoy-downstream-service-cluster headers from unexpected sources.
    • Source IP addresses in RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) appearing on external interfaces.
  • Log Indicators:
    • Envoy access logs showing requests with internal headers from non-internal IPs.
    • Unusual routing or access control bypass events in service mesh logs.
  • File Indicators:
    • Envoy configuration files with empty internal_address_config (vulnerable state).

Detection Engineering

YARA Rule

rule CVE_2024_45806_Envoy_Header_Manipulation {
    meta:
        description = "Detects Envoy configuration files vulnerable to CVE-2024-45806"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-45806"
    strings:
        $internal_config = "internal_address_config"
        $empty_config = "internal_address_config:" nocase
    condition:
        $empty_config and not $internal_config
}

Sigma Rule

title: CVE-2024-45806 - Envoy Internal Header Manipulation
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects HTTP requests with Envoy internal headers from external sources
author: Valters IT
date: 2024/10/27
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-45806
logsource:
    category: proxy
    product: envoy
detection:
    selection:
        http.request.headers|contains:
            - 'x-envoy-external-address'
            - 'x-envoy-decorator-operation'
            - 'x-envoy-downstream-service-cluster'
    filter:
        source.ip|startswith:
            - '10.'
            - '172.16.'
            - '192.168.'
    condition: selection and not filter
falsepositives:
    - Legitimate internal traffic from trusted networks
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-45806 - Envoy Internal Header Manipulation Attempt"; flow:to_server; content:"x-envoy-external-address"; http_header; sid:1000001; rev:1; reference:cve,2024-45806; classtype:attempted-admin; priority:1;)

Remediation & Mitigation

Immediate Actions:

  1. Upgrade Envoy to versions 1.31.2, 1.30.6, 1.29.9, or 1.28.7.
  2. If upgrade is not possible, explicitly configure internal_address_config with trusted CIDR ranges to restore the previous behavior.
  3. Review and update any security policies that rely on automatic trust of private IPs.

Long-term Mitigations:

  • Implement network segmentation to prevent external IP spoofing.
  • Use mutual TLS (mTLS) for service-to-service communication in service meshes.
  • Regularly audit Envoy configurations for insecure defaults.
  • Monitor for unusual header manipulation attempts.

Workarounds: No known workarounds exist. The only reliable fix is upgrading to a patched version.


Valters IT

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-45806/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.