CVE-2025-62504

Executive Summary

CVE-2025-62504 is a high-severity (CVSS 6.5) use-after-free vulnerability in the Envoy proxy's Lua filter. When a Lua script rewrites a response body during the response phase, and the new body size exceeds the per_connection_buffer_limit_bytes (default 1MB), Envoy generates a local reply that overrides the original response headers. This leaves dangling references to freed memory, causing a crash and resulting in a denial of service (DoS). The vulnerability affects all Envoy versions prior to 1.36.2, 1.35.6, 1.34.10, and 1.33.12. While increasing buffer limits can reduce the likelihood of triggering the condition, it does not fix the underlying memory safety flaw. No public proof-of-concept (PoC) or exploit code is currently available, and the EPSS score is 0.0%, indicating low exploitation activity in the wild.

Supply Chain & Package Security

Envoy is a widely used open-source edge and service proxy, often deployed as a sidecar in Kubernetes environments or as an API gateway. The vulnerability is in the Lua filter, which is an optional component. Organizations using Envoy with Lua scripting for request/response manipulation are at risk. The supply chain risk is moderate, as the vulnerability is in a specific filter that may not be enabled in all deployments. However, if the Lua filter is used, an attacker who can trigger a response body rewrite that exceeds buffer limits can cause a DoS. The patch is available in the official Envoy releases, and organizations should prioritize upgrading to the fixed versions.

CVSS Breakdown & Threat Level

• CVSS Score: 6.5 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
• Attack Vector (AV): Network – The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low – No special conditions are required.
• Privileges Required (PR): None – No authentication needed.
• User Interaction (UI): None – No user action required.
• Scope (S): Unchanged – The exploit does not affect other components.
• Confidentiality (C): None – No data exposure.
• Integrity (I): None – No data modification.
• Availability (A): High – The vulnerability causes a crash, leading to denial of service.

Threat Level: Medium. The vulnerability is remotely exploitable with low complexity and no authentication, but it only affects availability. The lack of public exploit code and low EPSS score reduce immediate risk, but the potential for DoS in critical infrastructure is significant.

Deep Dive & Mechanics

The vulnerability resides in the Lua filter of Envoy, which allows users to execute Lua scripts to inspect and modify HTTP requests and responses. When a Lua script is executed during the response phase and rewrites the response body, Envoy must manage memory for the new body. If the new body size exceeds the per_connection_buffer_limit_bytes (default 1MB), Envoy generates a local reply (e.g., a 413 Payload Too Large or 500 Internal Server Error) to replace the original response. However, the code that handles this local reply does not properly clean up references to the original response headers. Specifically, the Lua filter's state still holds pointers to the original headers, which are freed when the local reply is generated. When the Lua script continues execution or when the filter is destroyed, these dangling pointers are dereferenced, leading to a use-after-free condition and a crash.

The root cause is a memory management flaw in the Lua filter's response path. The fix involves ensuring that when a local reply is generated due to buffer limit violations, all references to the original response headers are invalidated or properly released before the Lua script continues.

Vulnerable vs. Patched Code

The vulnerable code is in the Lua filter's response handling, specifically in the onResponseBody or similar callback. The following is a simplified representation of the vulnerable logic:

Vulnerable Code (Conceptual):

void LuaFilter::onResponseBody(Buffer::Instance& data) {
    // Lua script rewrites the body
    std::string new_body = lua_script->rewrite(data.toString());
    if (new_body.size() > per_connection_buffer_limit_bytes_) {
        // Generate local reply - this frees original headers
        generateLocalReply(Code::PayloadTooLarge, "Body too large", nullptr, absl::nullopt);
        // Dangling reference: original_headers_ still points to freed memory
        // Later access to original_headers_ causes use-after-free
    }
    // ... continue processing
}

Patched Code (Conceptual):

void LuaFilter::onResponseBody(Buffer::Instance& data) {
    std::string new_body = lua_script->rewrite(data.toString());
    if (new_body.size() > per_connection_buffer_limit_bytes_) {
        // Invalidate all references before generating local reply
        original_headers_.reset();
        generateLocalReply(Code::PayloadTooLarge, "Body too large", nullptr, absl::nullopt);
        return; // Stop further processing
    }
    // ... continue processing
}

The patch ensures that any dangling references to the original response headers are cleared before the local reply is generated, preventing the use-after-free.

Exploitation & Lab Setup

Red Team

Prerequisites:

• An Envoy instance (version < 1.36.2, < 1.35.6, < 1.34.10, or < 1.33.12) with the Lua filter enabled.
• A Lua script that rewrites response bodies (e.g., adding data to the body).
• Ability to send HTTP requests that trigger a response body rewrite exceeding the buffer limit.

Exploitation Steps:

1. Deploy a vulnerable Envoy instance with a Lua filter configured to rewrite response bodies. Example configuration:

   http_filters:
   - name: envoy.filters.http.lua
     typed_config:
       "@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
       inline_code: |
         function envoy_on_response(response_handle)
           response_handle:logInfo("Response phase")
           -- Rewrite body to exceed buffer limit
           local body = response_handle:body()
           if body then
             local new_body = body:getBytes(0, -1) .. string.rep("A", 2 * 1024 * 1024) -- 2MB
             response_handle:body():set(new_body)
           end
         end
   

2. Send a request to a route that triggers the Lua filter. For example:

   curl -X GET http://envoy-host:10000/any-path
   

3. The Lua script will attempt to set a response body that exceeds the default 1MB buffer limit. Envoy will generate a local reply, and the use-after-free will cause a crash.
4. Observe the crash in Envoy logs (e.g., segfault or abort).

Note: No public exploit code is available. The above steps are for educational purposes only.

Blue Team

Detection:

• Monitor Envoy logs for crashes, especially segfaults or abort signals.
• Look for repeated 413 Payload Too Large or 500 Internal Server Error responses from Envoy.
• Use the detection rules provided in the Detection Engineering section.

Mitigation:

• Immediately upgrade Envoy to versions 1.36.2, 1.35.6, 1.34.10, or 1.33.12.
• If upgrading is not possible, increase per_connection_buffer_limit_bytes (and for HTTP/2, initial_stream_window_size) to reduce the likelihood of triggering the condition. Note that this is not a complete fix.
• Disable the Lua filter if not required.

Indicators of Compromise (IOCs)

• Log Entries: Envoy crash logs containing "segfault", "SIGABRT", "use-after-free", or "dangling reference".
• Network Traffic: HTTP responses with status code 413 (Payload Too Large) or 500 (Internal Server Error) from Envoy, especially when Lua filter is enabled.
• Memory Dumps: Core dumps showing corrupted heap or freed memory in the Lua filter context.
• Process Behavior: Envoy process unexpectedly terminating with a non-zero exit code.

Detection Engineering

YARA Rule

rule CVE_2025_62504_Envoy_Lua_UseAfterFree {
    meta:
        description = "Detects Envoy crash logs indicating use-after-free in Lua filter"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-62504"
    strings:
        $crash1 = "segfault" nocase
        $crash2 = "SIGABRT" nocase
        $crash3 = "use-after-free" nocase
        $crash4 = "dangling reference" nocase
        $lua = "lua" nocase
    condition:
        any of ($crash*) and $lua
}

Sigma Rule

title: Envoy Lua Filter Use-After-Free Crash
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects Envoy crashes related to CVE-2025-62504
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-62504
logsource:
    product: envoy
    service: proxy
detection:
    selection:
        - EventID: 1000  # Application Error (Windows)
        - EventID: 6008  # Unexpected shutdown (Windows)
        - Keywords: "*segfault*" or "*SIGABRT*" or "*use-after-free*"
    condition: selection
falsepositives:
    - Legitimate crashes due to other bugs
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-62504 Envoy Lua Filter Use-After-Free Attempt"; flow:to_server; content:"413"; http_stat_code; content:"Payload Too Large"; http_server_body; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Remediation:

• Upgrade Envoy to version 1.36.2, 1.35.6, 1.34.10, or 1.33.12. This is the only complete fix.

Mitigation (if upgrade is not possible):

• Increase per_connection_buffer_limit_bytes to a higher value (e.g., 10MB) to reduce the chance of triggering the condition.
• For HTTP/2, also increase initial_stream_window_size.
• Increase per_request_buffer_limit_bytes or request_body_buffer_limit if applicable.
• Disable the Lua filter if it is not essential for your use case.
• Implement network segmentation to limit exposure to untrusted clients.

Long-Term Recommendations:

• Regularly update Envoy to the latest stable version.
• Review and minimize the use of Lua scripts in Envoy configurations.
• Implement monitoring and alerting for Envoy crashes.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert