fix(dashmate): bump Envoy gateway to 1.35.11 for HTTP/2 DoS (CVE-2026-47774)

[shumkov]

Issue being fixed or feature implemented

v3 hotfix. 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 bypass max_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 — the only patched Envoy line published upstream so far, and the smallest jump from 1.30.

• Bumped the base config default gateway image.
• Added a 3.0.2 config migration resetting the gateway image to the patched default for existing nodes. No migration above 3.0.0 touched the gateway image, so v3 configs (3.0.0 .. 3.0.1-hotfix.4) would otherwise stay on the vulnerable 1.30 image.
• Updated docs/config/gateway.md and docs/update.md.

The image is already built, published, and verified (multi-arch amd64/arm64, contains Envoy 1.35.11): built from dashpay/docker-envoy#3 via release v1.35.11-impr.1. So this PR is not blocked on image availability.

Migration key note: keyed 3.0.2 (the next v3 release, per the release_3.0.2 branch). Semver-safe: it runs for every config on < 3.0.2, i.e. 3.0.0, 3.0.1, and all 3.0.1-hotfix.* prereleases. If the hotfix ships under a different version, retarget the key to match.

How Has This Been Tested?

Added a regression test in migrateConfigFileFactory.spec.js for the v3 cohort. Red→green verified via the real migrateConfigFile dispatch + real base config:

RED  (no migration):    dashpay/envoy:1.30.2-impr.1   (still vulnerable)
GREEN (with migration): dashpay/envoy:1.35.11-impr.1

Separately, the rendered gateway config was validated against Envoy 1.35.11 (envoy --mode validate, all conditional branches) — loads clean, zero deprecation warnings.

Breaking Changes

None.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 589768e4-c0c7-444c-8fdc-b5b5564ac656

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/dashmate-envoy-cve-2026-47774-v3

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[thepastaclaw]

✅ Review complete (commit c2c3347)

[thepastaclaw]

Code Review

Targeted CVE-2026-47774 hotfix bumping the default Envoy gateway image and adding a 3.0.2 migration that resets all existing configs. Migration dispatch and test coverage are sound. Two reviewers independently flagged a brittle regex in the new regression test that duplicates a stronger assertion already present in the same test.

🟡 1 suggestion(s) | 💬 1 nitpick(s)

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/dashmate/test/unit/config/configFile/migrateConfigFileFactory.spec.js`:
- [SUGGESTION] packages/dashmate/test/unit/config/configFile/migrateConfigFileFactory.spec.js:59-61: Brittle regex on base image will break on future valid Envoy bumps
  The regex `/^dashpay\/envoy:1\.(3[5-9]|[4-9]\d)\./` pins the base default to the Envoy 1.35..1.99 range. A legitimate future bump to a 2.x line (or to 1.100+) will fail this test without indicating any security regression. The security intent is already captured by line 82 (`expect(migratedImage).to.not.equal('dashpay/envoy:1.30.2-impr.1')`), which transitively guards the base default since `migratedImage === patchedImage` after the migration runs. Replacing the regex with an explicit assertion that the base default is not the known-vulnerable tag expresses the same invariant without coupling to a specific upstream version range.

[thepastaclaw]

🟡 Suggestion: Brittle regex on base image will break on future valid Envoy bumps

The regex /^dashpay\/envoy:1\.(3[5-9]|[4-9]\d)\./ pins the base default to the Envoy 1.35..1.99 range. A legitimate future bump to a 2.x line (or to 1.100+) will fail this test without indicating any security regression. The security intent is already captured by line 82 (expect(migratedImage).to.not.equal('dashpay/envoy:1.30.2-impr.1')), which transitively guards the base default since migratedImage === patchedImage after the migration runs. Replacing the regex with an explicit assertion that the base default is not the known-vulnerable tag expresses the same invariant without coupling to a specific upstream version range.

Suggested change

	// The base default itself must be on a patched line (>= 1.35), never the
	// vulnerable 1.30.x line — pins the security intent of the fix.
	expect(patchedImage).to.match(/^dashpay\/envoy:1\.(3[5-9]|[4-9]\d)\./);
	// The base default must not stay on the known-vulnerable 1.30.x line.
	expect(patchedImage).to.not.equal('dashpay/envoy:1.30.2-impr.1');

_{source: ['claude', 'codex']}

[thepastaclaw]

Resolved in this update — Brittle regex on base image will break on future valid Envoy bumps no longer present.

_{Auto-resolved by the review system based on the latest commit diff. If you believe this was closed in error, reopen the thread.}

[thepastaclaw]

Code Review

Cumulative incremental review for PR #3794 (CVE-2026-47774 Envoy bump). Prior findings reconciliation: (1) 'Brittle regex on base image' — FIXED (the regex assertion was removed entirely from the test file in commit c2c3347); (2) 'Migration unconditionally overwrites custom gateway images' — FIXED (getConfigFileMigrationsFactory.js:1411-1414 now gates the rewrite on /^dashpay/envoy:1.30./, preserving custom images). New latest-delta finding: the removal also dropped the only regression test that directly exercised the new 3.0.2 conditional — the remaining v0.25.0->latest migration test does not cover it because the fixture image is 1.22.11 and an earlier migration rewrites the gateway image well before the 3.0.2 step runs.

🟡 1 suggestion(s)

1 additional finding(s) omitted (not in diff).

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/dashmate/test/unit/config/configFile/migrateConfigFileFactory.spec.js`:
- [SUGGESTION] packages/dashmate/test/unit/config/configFile/migrateConfigFileFactory.spec.js:25-48: New finding (latest delta): 3.0.2 Envoy CVE migration is no longer covered by a regression test
  The latest delta (c2c33473) removed the dedicated regression test for the new 3.0.2 migration branch. The remaining `should migrate v0.25.0 config file to the latest one` test does walk through every migration step, but it does not exercise the new conditional at getConfigFileMigrationsFactory.js:1411-1414: the v0.25.0 fixture pins `dashpay/envoy:1.22.11` (src/test/fixtures/getConfigFileDataV0250.js:79), and an earlier migration step rewrites `platform.gateway.docker.image` to the base default well before the 3.0.2 step runs. By the time the 3.0.2 step executes in that test, the `/^dashpay\/envoy:1\.30\./` regex matches nothing, so the new security-relevant branch has zero coverage. Because this PR is a CVE hotfix for already-deployed v3 configs, the rewrite path from a vulnerable 1.30.x image to the patched base default should be pinned by a dedicated test. A version-agnostic test that feeds a config at `configFormatVersion: '3.0.1-hotfix.4'` with `dashpay/envoy:1.30.2-impr.1` and asserts the migrated image equals `base.get('platform.gateway.docker.image')` would pin the behaviour without re-introducing the brittle version-range regex flagged in the previous review.

[vivekgsharma]

LGTM