fix: [handlebars] Upgrade handlebars from 4.0.14 to 4.7.9 to resolve SNYK-JS-HANDLEBARS-534988 (Prototype Pollution) - #224
Conversation
Co-Authored-By: Hannah Huh <hannah.huh@cognition.ai>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| "overrides": { | ||
| "handlebars": "4.7.9" | ||
| } |
There was a problem hiding this comment.
🟡 Lockfile missing overrides breaks npm ci
package.json adds an overrides block, but the lockfile root packages[""] records no matching overrides field, so the two are out of sync. npm ci compares the overrides and aborts with an EUSAGE error, breaking clean and CI installs.
Prompt for agents
The package.json now declares an overrides block for handlebars, but package-lock.json was not truly regenerated by npm: the lockfile root object packages[""] has no overrides field. When npm regenerates a lockfile (lockfileVersion 2/3) with overrides present, it writes the overrides into packages[""]. Its absence means npm ci will detect package.json and package-lock.json as out of sync and fail. Regenerate the lockfile with a real npm install (npm install --package-lock-only) using an npm version that supports overrides (>=8.3), and commit the result so packages[""] includes the overrides entry.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Verified locally — npm ci is not broken by this.
I regenerated the lockfile with npm install --package-lock-only on npm 10.8.2. This repo's lockfile is lockfileVersion: 2 (hybrid v1/v2), and npm did not write an overrides key into packages[""] — but it did resolve the overridden version in the tree, and npm only enforces the overrides-sync check when the lockfile records one.
Evidence, from a clean checkout of just package.json + package-lock.json on this branch:
$ npm ci --ignore-scripts
added 947 packages in 5s
$ node -e "console.log(require('handlebars/package.json').version)"
4.7.9
No EUSAGE error. Leaving the lockfile as npm generated it.
| "overrides": { | ||
| "handlebars": "4.7.9" | ||
| } |
There was a problem hiding this comment.
🔍 hbs forced from exact handlebars 4.0.14 to 4.7.9
hbs@4.0.4 pins an exact handlebars@4.0.14; the override forces 4.7.9. Handlebars 4.x is broadly compatible, but hbs was never tested against 4.7.9, so a runtime smoke test of view rendering is warranted.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Smoke-tested hbs against the forced handlebars@4.7.9 from this branch's lockfile:
handlebars 4.7.9
compile('Hello {{name}}!')({name:'world'}) -> "Hello world!"
views/account.hbs -> rendered, 890 chars
views/layout.hbs -> rendered, 482 chars
No API breakage from hbs's pinned 4.0.14 to 4.7.9.
1 participant
Summary
Fixes the highest-CVSS finding of the scheduled Snyk MCP scan: Prototype Pollution in
handlebars.SNYK-JS-HANDLEBARS-534988(no CVE assigned)handlebars@4.0.14, pulled in transitively viahbs>=4.5.3; pinned to4.7.9, the current 4.x releaseObject.prototype, leading to property injection and, in Handlebars' case, remote code execution during template compilation.handlebarsis not a direct dependency, so the fix is an npmoverridesentry rather than adependenciesbump:package-lock.jsonregenerated withnpm install --package-lock-only; resolvednode_modules/handlebarsis now4.7.9.Snyk scan reference:
snyk test --all-projects --dev/snyk_sca_scan(unmanaged: true), Snyk org9e26acce-22c7-4efc-b470-21d9587f49fe.Devin-Org: engineering
Link to Devin session: https://app.devin.ai/sessions/fc1965e7d98f4966bea1c7aa64a929b0
Requested by: @hannahhuh-cog
Devin Review