chore(deps): bump lodash to 4.18.1 (CVE-2026-4800)#413
Conversation
|
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe minimum version constraint for the ChangesDependency Override Update
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 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 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 |
Patches GHSA-r5fr-rjxr-66jc / CVE-2026-4800 (high): lodash <= 4.17.23 allows code injection via _.template when an attacker controls the imports option keys. Lodash is a transitive runtime dep here (pulled in by json-schema-to-typescript@15.0.4, which declares lodash: ^4.17.21). The existing root override "lodash": ">=4.17.23" accepted the vulnerable 4.17.23; bumping to ">=4.18.0" pushes the resolved version into the patched line (4.18.0+). The pnpm-lock.yaml change is intentionally a surgical hand-edit of the three lodash references (resolution + integrity, parent's dep ref, snapshot key) rather than a full regen. A regen with the override change ended up bumping ~30 unrelated transitives (drizzle-orm, @types/node, drizzle-kit, etc.) because pnpm took the chance to walk the rest of the lockfile too. Surgical edit keeps the blast radius to just lodash, and `pnpm install --frozen-lockfile` validates cleanly.
coderdan
force-pushed
the
dan/bump-lodash-4.18.1
branch
from
b7ebcca to
39ddb06
Compare
2 participants
Summary
lodashfrom4.17.23→4.18.1to patch GHSA-r5fr-rjxr-66jc / CVE-2026-4800 (high): code injection via_.templatewhenimportskeys are attacker-controlled.Why this looked like the vite case at first — and why it isn't
Like the vite alert, lodash here is a transitive dep with
manifest_path: pnpm-lock.yaml. But unlike vite, lodash is a normal transitive (pulled in byjson-schema-to-typescript@15.0.4, which declareslodash: ^4.17.21), not an optional peer auto-install. pnpm'soverridesmechanism applies cleanly here.The existing override at
>=4.17.23already targeted lodash — it just hadn't been bumped past the patched cutoff. Raising it to>=4.18.0resolves to the patched line.Why a hand-edited lockfile (vs.
pnpm install)A full regen with the bumped override correctly picked
lodash@4.18.1, but it also walked the rest of the tree and pulled in ~30 unrelated transitive bumps (drizzle-orm 0.44.7 → 0.45.2,@types/node 22.19.3 → 22.19.17,drizzle-kit 0.30.6 → 0.31.10, etc.). That's well outside the scope of a CVE patch, so I did a surgical 3-spot edit of the lockfile instead:lodash@4.17.23:→lodash@4.18.1:with the new integrity hash (sourced fromnpm view lodash@4.18.1 dist.integrity).json-schema-to-typescript@15.0.4's snapshot dep reflodash: 4.17.23→lodash: 4.18.1.lodash@4.17.23: {}→lodash@4.18.1: {}.pnpm install --frozen-lockfileaccepts the lockfile and downloadslodash@4.18.1correctly.Note: 4.18.1 satisfies
json-schema-to-typescript's declaredlodash: ^4.17.21range, so no API compatibility risk.Summary by CodeRabbit