CVE-2025-62504
BaseFortify
Publication date: 2025-10-16
Last updated on: 2025-10-29
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| envoyproxy | envoy | to 1.33.12 (exc) |
| envoyproxy | envoy | From 1.34.0 (inc) to 1.34.10 (exc) |
| envoyproxy | envoy | From 1.35.0 (inc) to 1.35.6 (exc) |
| envoyproxy | envoy | From 1.36.0 (inc) to 1.36.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a use-after-free flaw in the Lua filter of Envoy proxy versions earlier than 1.36.2, 1.35.6, 1.34.10, and 1.33.12. When a Lua script modifies a response body during the response phase so that its size exceeds a configured buffer limit (default 1MB), Envoy generates a local reply that overrides the original response headers but leaves dangling references in memory. This causes Envoy to crash.
How can this vulnerability impact me? :
The vulnerability can cause Envoy to crash, resulting in a denial of service (DoS). This means that services relying on Envoy as a proxy could become unavailable or disrupted when the vulnerability is triggered.
What immediate steps should I take to mitigate this vulnerability?
Update Envoy to versions 1.36.2, 1.35.6, 1.34.10, or 1.33.12 to fix the use-after-free vulnerability. Alternatively, 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 these do not fix the underlying memory safety flaw.