Bug 2404627 (CVE-2025-62504)

Summary: CVE-2025-62504 envoy: Envoy Lua filter use-after-free when oversized rewritten response body causes crash
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A vulnerability has been identified in the Envoy edge and service proxy, where use-after-free flaw exists within the Lua filter. An attacker can exploit this flaw by using a malicious Lua script to significantly increase the size of a response body, exceeding the connection's buffer limit. This action causes Envoy to incorrectly manage memory, leading to dangling references and a subsequent crash of the proxy. The immediate consequence is a denial of service condition, which makes the affected service completely unresponsive to all users and traffic.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2025-10-16 22:01:32 UTC 
Envoy is an open source edge and service proxy. Envoy versions earlier than 1.36.2, 1.35.6, 1.34.10, and 1.33.12 contain a use-after-free vulnerability in the Lua filter. When a Lua script executing in the response phase rewrites a response body so that its size exceeds the configured per_connection_buffer_limit_bytes (default 1MB), Envoy generates a local reply whose headers override the original response headers, leaving dangling references and causing a crash. This results in denial of service. Updating to versions 1.36.2, 1.35.6, 1.34.10, or 1.33.12 fixes the issue. Increasing per_connection_buffer_limit_bytes (and for HTTP/2 the initial_stream_window_size) or increasing per_request_buffer_limit_bytes / request_body_buffer_limit can reduce the likelihood of triggering the condition but does not correct the underlying memory safety flaw.