[Snyk] Security upgrade dompurify from 3.3.3 to 3.4.0 #6048
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟡 This PR bumps dompurify to 3.4.0 (published 2026-04-14), but the repo's
frontend/.npmrcenforcesmin-release-age=7, meaning the package won't satisfy the constraint until 2026-04-21. Any developer who deletespackage-lock.jsonand runsnpm installbetween now and April 21 will get a resolution failure. Consider delaying merge until April 21 or pinning an older version that already satisfies the 7-day window.Extended reasoning...
What the bug is and how it manifests
The repository explicitly enforces a supply-chain security policy via
frontend/.npmrc:min-release-age=7. This setting, documented in rootCLAUDE.md("Both backend/ and frontend/ enforce a minimum release age of 7 days for npm packages... This means npm install will only resolve package versions published at least 7 days ago"), prevents npm from resolving packages published less than 7 days ago during dependency resolution.dompurify 3.4.0 was published on 2026-04-14T07:51:39Z. This PR was opened 2026-04-16 — exactly 2 days later. The 7-day minimum-age window does not expire until 2026-04-21.
The specific code path that triggers it
Snyk runs in its own environment (likely without the local
.npmrcpolicy), so it successfully resolves and pins dompurify 3.4.0 inpackage-lock.json. In the repo, any developer who regenerates the lockfile (deletespackage-lock.jsonand runsnpm install) before April 21 will trigger npm's dependency resolution phase, during which npm will seedompurify@^3.4.0inpackage.json, attempt to resolve it, and themin-release-age=7check will block 3.4.0 as it's only 2 days old.Why existing code doesn't prevent it
The
.npmrcpolicy is intentionally designed to protect against supply-chain attacks on newly published packages. However, Snyk's automated PR generation bypasses this check because Snyk runs in a sandboxed environment without the project's local.npmrc. The policy is enforced locally and in CI only whennpm install(with resolution) is invoked — not whennpm ciis used (which reads the lockfile directly, bypassing resolution entirely).What the impact would be
The refutation correctly notes that
npm installwith an existing, compatible lockfile does not re-resolve dependencies, so ordinary developernpm installruns are unaffected. Similarly,npm ci(used in CI/CD pipelines) is unaffected. The failure scenario is narrowed to: a developer deletespackage-lock.json(e.g., to resolve a merge conflict, add a new dependency from scratch, or troubleshoot) and runsnpm installbefore April 21. During that ~5-day window, the install would fail with an error citing the min-release-age constraint. This is a real — if limited — developer friction point that directly contradicts the project's documented security policy.How to fix it
The simplest fix is to delay merging this PR until 2026-04-21, when dompurify 3.4.0 will satisfy the 7-day constraint. Alternatively, if the security vulnerability is urgent enough to merge immediately, team members should be warned not to regenerate the lockfile until April 21.
Step-by-step proof
frontend/.npmrccontainsmin-release-age=7"time": {"3.4.0": "2026-04-14T07:51:39.768Z"})rm frontend/package-lock.json && npm install(in frontend/)dompurify@^3.4.0→ finds 3.4.0 as latest matching versionmin-release-age=7→ 3.4.0 is 2 days old → resolution blockednpm ERR! No matching version found for dompurify@^3.4.0(or equivalent min-release-age error)