fix(dashmate): bump Envoy gateway to 1.35.11 for HTTP/2 DoS (CVE-2026-47774)#3790
fix(dashmate): bump Envoy gateway to 1.35.11 for HTTP/2 DoS (CVE-2026-47774)#3790shumkov wants to merge 2 commits into
Conversation
…-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. Of the advisory's fix versions (1.35.11/1.36.7/1.37.3/1.38.1) only 1.35.11 is published upstream so far, so the patched image is dashpay/envoy:1.35.11-impr.1. - Bump the base config default gateway image. - Add a 4.0.0-beta.3 config migration that resets the gateway image to the patched default for existing configs. The pre-existing reset at migration 1.0.0-dev.12 only runs for fromVersion < 3.0.0, so configs created on 3.0.0..4.0.0-beta.2 would otherwise stay on the vulnerable 1.30 image. - Update the gateway/update docs. Regression test pins the migration for the 3.0.0..4.0.0-beta.2 cohort. Test would have caught this in CI (migrateConfigFileFactory.spec.js): ✖ before migration: expected 'dashpay/envoy:1.30.2-impr.1' to equal 'dashpay/envoy:1.35.11-impr.1' ✔ after migration Requires dashpay/docker-envoy to publish dashpay/envoy:1.35.11-impr.1 (base-image bump: shumkov/docker-envoy@fix/bump-envoy-1.35.11-cve-2026-47774). 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 ignored due to path filters (1)
📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThis PR upgrades the Envoy Docker image version used by dashmate from 1.30.2-impr.1 to 1.35.11-impr.1. It updates the default configuration, adds a migration handler for configs from 4.0.0-beta.2 to 4.0.0-beta.3, includes test coverage, and updates all related documentation. ChangesEnvoy Docker Image Upgrade to 1.35.11-impr.1
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested reviewers
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 docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. 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 |
|
✅ Review complete (commit a723981) |
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
Targeted security fix bumping the default Envoy gateway image and adding a 4.0.0-beta.3 config migration that resets existing configs missed by the prior 1.0.0-dev.12 cohort (3.0.0..4.0.0-beta.2). Implementation is correct, scoped, well-tested, and follows the codebase's established unconditional-reset convention for migration-driven image bumps (see line 660). Both Codex findings fail validation — one misreads the intentional 'migration activates on current binary' mechanism, the other contradicts the established codebase pattern.
…teway Verified the gateway Envoy config against Envoy 1.35.11 (`envoy --mode validate` across all conditional branches: self-signed TLS, rate limiter, metrics/admin, JSON/file access logs, overload manager): loads clean with zero deprecation warnings. Two cleanups surfaced by that review: - Remove `protocol_selection: USE_CONFIGURED_PROTOCOL` from the ratelimit_service cluster. It's deprecated and redundant — the cluster already pins HTTP/2 via typed_extension_protocol_options / explicit_http_config, which takes precedence. Re-validated after removal: still "configuration OK", behavior unchanged. - Bump the injected_resource doc-link comment v1.30.1 -> v1.35.11 to match the image bump. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
Targeted CVE fix that bumps the Dashmate Platform Gateway from the vulnerable Envoy 1.30.2-impr.1 to 1.35.11-impr.1 for CVE-2026-47774 / GHSA-22m2-hvr2-xqc8, with a 4.0.0-beta.3 migration covering the 3.0.0..4.0.0-beta.2 cohort missed by the earlier 1.0.0-dev.12 reset. The latest-push delta drops the deprecated protocol_selection: USE_CONFIGURED_PROTOCOL from the ratelimit_service cluster, which is correctly redundant because the same cluster already declares HTTP/2 via typed_extension_protocol_options.explicit_http_config.http2_protocol_options. All agent findings reduce to either documented design intent (the broad migration sweep) or pre-existing concerns unrelated to this PR's scope (plain-text doc table uses old naming across all services; rate-limiter cluster rendering was never test-covered prior to this PR). No in-scope blocking or actionable issues; the only external dependency is the documented Docker Hub publication of dashpay/envoy:1.35.11-impr.1, which the PR description already gates merge on.
Issue being fixed or feature implemented
The Platform Gateway pins
dashpay/envoy:1.30.2-impr.1(Envoy 1.30.x), affected by GHSA-22m2-hvr2-xqc8 (CVE-2026-47774, CVSS 7.5 High) — an unauthenticated HTTP/2 downstream memory-exhaustion DoS: cookie header bytes bypassmax_request_headers_kb, and HPACK decode amplification expands small encoded headers into large decoded ones. The 1.30 line is EOL (no backport).What was done?
Moved the gateway to the patched
dashpay/envoy:1.35.11-impr.1. Of the advisory's fix versions (1.35.11 / 1.36.7 / 1.37.3 / 1.38.1), only 1.35.11 is published upstream so far, and it's the smallest jump from 1.30 (lowest config-deprecation risk).4.0.0-beta.3config migration resetting the gateway image to the patched default for existing nodes. The pre-existing reset (migration1.0.0-dev.12) only runs forfromVersion < 3.0.0, so configs created on 3.0.0 .. 4.0.0-beta.2 would otherwise stay on the vulnerable 1.30 image.docs/config/gateway.mdanddocs/update.md.This pin won't pull until
dashpay/docker-envoypublishesdashpay/envoy:1.35.11-impr.1:v1.35.11-impr.1(or run the workflow_dispatch) to actually build & push the image.Do not merge this before
dashpay/envoy:1.35.11-impr.1exists on Docker Hub.How Has This Been Tested?
Added a regression test in
migrateConfigFileFactory.spec.jspinning the migration for the 3.0.0..4.0.0-beta.2 cohort. Verified red→green (base bump in place, migration toggled):Full
migrateConfigFileFactorysuite passes (existing full-migration test still green), eslint clean.Breaking Changes
None.
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit
Release Notes