fix: bump Envoy to v1.35.11 to patch HTTP/2 DoS (CVE-2026-47774)#3
Conversation
Envoy v1.30.1 is affected by GHSA-22m2-hvr2-xqc8 (CVE-2026-47774, CVSS 7.5): an unauthenticated HTTP/2 downstream memory-exhaustion DoS where cookie header bytes bypass `max_request_headers_kb` and HPACK decode amplification expands small encoded headers into large decoded ones. The 1.30 line is EOL with no backport. Of the advisory's listed fix versions (1.35.11 / 1.36.7 / 1.37.3 / 1.38.1), only v1.35.11 is published upstream so far, so we move to that line — also the smallest jump, lowest config-deprecation risk. The hot-restart wrapper, scripts, and entrypoint are unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe Dockerfile is updated to use a newer version of the Envoy proxy base image. The FROM directive is changed from ChangesEnvoy Version Update
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…-47774) The Platform Gateway runs dashpay/envoy:1.30.2-impr.1 (Envoy 1.30.x), affected by GHSA-22m2-hvr2-xqc8 / CVE-2026-47774 (CVSS 7.5): an unauthenticated HTTP/2 downstream memory-exhaustion DoS — cookie header bytes bypass max_request_headers_kb and HPACK decode amplification expands small encoded headers into large decoded ones. The 1.30 line is EOL; 1.35.11 is the patched line published upstream. - Bump the base config default gateway image to dashpay/envoy:1.35.11-impr.1 (built + published from dashpay/docker-envoy#3; multi-arch, verified to contain Envoy 1.35.11). - Add a 3.0.2 config migration that rewrites only the EOL 1.30.x Envoy image to the patched default, leaving deliberately customised images untouched. No migration above 3.0.0 touched the gateway image, so v3 configs (3.0.0..3.0.1-hotfix.*) would otherwise stay on the vulnerable image. - Update gateway/update docs. Config validated against Envoy 1.35.11 (envoy --mode validate, all conditional branches): loads clean, zero deprecation warnings. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Issue being fixed
The image is built
FROM envoyproxy/envoy:v1.30.1, which is affected by GHSA-22m2-hvr2-xqc8 (CVE-2026-47774, CVSS 7.5 High).It's an unauthenticated HTTP/2 downstream memory-exhaustion DoS:
max_request_headers_kb.The 1.30 line is EOL — no backport exists there.
What was done
Bumped the base image
FROM envoyproxy/envoy:v1.30.1→v1.35.11.Of the advisory's listed fix versions (
1.35.11/1.36.7/1.37.3/1.38.1), onlyv1.35.11is published upstream so far (released + pushed to Docker Hub 2026-06-03; the others have no GitHub release and aren't on Docker Hub yet —v1.38-lateststill points at the vulnerablev1.38.0). It's also the smallest jump from 1.30, so the lowest config-deprecation risk.v1.35.11is multi-arch (amd64 + arm64), matching the existing build platforms.The hot-restart wrapper (
hot-restarter.py/start_envoy.sh), thepython3install, and the entrypoint are unchanged — only the base tag moves.Merging this does not publish a new
dashpay/envoyimage — the release workflow only builds/pushes on a published GitHub release (orworkflow_dispatch), deriving the tag from the release tag. A maintainer needs to cut a release taggedv1.35.11-impr.1(or run the workflow manually with that tag) to producedashpay/envoy:1.35.11-impr.1.Once that image exists, the dashmate pin in
dashpay/platform(dashpay/envoy:1.30.2-impr.1→1.35.11-impr.1) is bumped in the companion PR.Summary by CodeRabbit
Release Notes