Database/Container, Kubernetes & orchestration

Envoy: use-after-free in the Lua filter crashes the proxy when a rewritten response body exceeds the buffer limit

CVSS 7.5CVE-2025-62504Container, Kubernetes & orchestrationcurated

Impact

An unauthenticated request that drives a Lua response-phase script to rewrite a body larger than per_connection_buffer_limit_bytes (1MB by default) makes Envoy generate a local reply whose headers override the original response, leaving dangling references and crashing the process. On a GPU fleet Envoy is usually the ingress or service-mesh sidecar in front of inference endpoints, so a crash loop takes model serving offline for every tenant behind that proxy, and sidecar crashes can cycle pods on nodes you did not plan to disturb. Only deployments that actually configure a Lua filter that rewrites response bodies are exposed. Impact is availability; the advisory does not claim code execution.

Who can reach it

Anyone who can send requests through an Envoy listener whose Lua filter rewrites response bodies - no authentication needed if the route is public.

What to do

Upgrade to Envoy 1.36.2, 1.35.6, 1.34.10 or 1.33.12 and restart the proxies; for mesh sidecars that means a rolling restart of the workloads, which on GPU pods is a scheduled pod recycle rather than a node drain. Raising per_connection_buffer_limit_bytes (plus initial_stream_window_size for HTTP/2) or per_request_buffer_limit_bytes/request_body_buffer_limit makes the condition harder to hit but does not fix the memory-safety bug. Removing or narrowing the body-rewriting Lua script is the only true mitigation short of patching.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-62504 https://github.com/envoyproxy/envoy/security/advisories/GHSA-gcxr-6vrp-wff3

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.