fix(deps): resolve all open Dependabot alerts across next, sharp, js-yaml, nodemailer and csv-parse - #7659
Merged
Merged
Conversation
Resolves Dependabot alerts #223, #224, #226, #228, #235, #236, #238, #239. - GHSA-p293-qw3h-jr36: unauthenticated RCE on Windows-hosted servers - GHSA-2xp9-vwfh-vxw4: unauthenticated RCE in the Image Optimization API when AVIF files are used Both are fixed in 16.3.3. This takes 16.3.4 instead because 16.3.3 disabled AVIF image optimization outright and 16.3.4 re-enables it; apps/sim/next.config.ts requests 'image/avif', so 16.3.3 alone would silently drop AVIF output. 16.3.4 otherwise carries only backported bug fixes, so there is no breaking change between 16.3.1 and 16.3.4. Verified: type-check, lint, all 46 audits, full test suite, and production builds of both apps/sim and apps/docs.
Resolves Dependabot alerts #230 and #234 (GHSA-rgj7-g3m4-5g8c), which cover two critical libheif vulnerabilities reachable when processing untrusted image input. Fixed upstream in sharp 0.35.4, which ships libvips 8.18.6. 0.35.4 is a patch release with no API changes. No source file imports sharp directly; it backs the Next.js image optimizer, which is the same code path as the AVIF advisory addressed in the previous commit. This also collapses a duplicate install: Next 16.3.4 depends on sharp ^0.35.3, so with the root pinned at 0.35.3 bun kept a second nested copy at 0.35.4, loading two libvips builds into one process and warning about duplicate GNotificationCenterDelegate classes. Both now resolve to a single 0.35.4. Verified: sharp loads its native binary and round-trips an AVIF encode and decode on libvips 8.18.6, plus all 46 audits, the full app test suite, and a production build.
Resolves Dependabot alerts #229 and #237 (GHSA-2883-xcg3-v3hh). maxTotalMergeKeys did not count empty mappings, so a small document could merge a large sequence of them repeatedly and burn CPU without ever reaching the configured limit. The path is reachable: both YAML entry points, lib/file-parsers and lib/chunkers, call yaml.load with the default schema, which enables merge keys, and both run on user-supplied files. Confirmed against the advisory proof of concept, which took 13s on 4.3.1 and is now refused in 6ms. Not a breaking change for real documents. The fix charges one extra budget unit per merge source against a default maxTotalMergeKeys of 10000, so only pathological documents newly fail; a 200-merge document over a 20-key anchor spends 4200 units and still loads. Ordinary merge and anchor resolution is unchanged.
Resolves Dependabot alerts #227, #231, #232 and #233. - GHSA-8m3c-c648-2xjj: quadratic addressparser complexity, remote DoS via a crafted address list - GHSA-cc9r-2j5m-2m83: IDN/Punycode domain allow-list bypass - GHSA-2x7j-588g-ccc2: RFC 5322 comment mis-parsing, both leading to delivery to an attacker-controlled domain - GHSA-wmmp-3585-3rmp: resolveContent bypassed disableFileAccess and disableUrlAccess on the legacy signature 9.0.1 to 9.1.1 stays inside v9. Checked the two changes that could have altered behavior: - The new maxRecipients cap defaults to 100000 and is documented as a backstop, not a delivery policy, so no real send reaches it. - The tightened resolveContent access sandbox only governs attachments given as a file path or URL. Sim passes attachment content as buffers in lib/messaging/email/providers, so the sandbox never applies. Address parsing is unchanged for plain, display-name, quoted-comma, multi-recipient, plus-tagged and unicode forms. Verified: type-check, lint, all 46 audits, and the 130 tests covering lib/messaging/email and lib/internal/smtp.
Resolves Dependabot alert #225 (GHSA-8cw4-87c7-c6xx). With columns and group_columns_by_name enabled, a duplicated __proto__ header made the duplicate-column branch assign through the __proto__ setter and replace the parsed record's prototype with attacker-controlled data. 7.0.2 fixes it with an Object.hasOwn duplicate check and Object.defineProperty. Despite crossing a major, this is not a breaking upgrade: the maintainers state that 7.0.0 "was published by mistake, there is no breaking changes." One real behavior change does land in the 6.1.0 to 7.0.2 range: trim now aligns with ECMAScript whitespace, so a value padded with non-ASCII whitespace such as U+00A0 is trimmed where it previously was not. Diffed both versions over plain, padded, CRLF, quoted-comma, embedded-tab, unicode-whitespace, ragged, BOM, blank-line and embedded-newline inputs under the exact options Sim passes: the unicode-whitespace case is the only difference, and it moves toward JavaScript trim semantics. Record structure, headers and field splitting are byte-identical. Sim never sets group_columns_by_name, so the vulnerable branch was not reachable, but every CSV entry point does pass columns and trim on user-supplied files. Verified: type-check, lint, all 46 audits, and the 1946 tests across lib/file-parsers, lib/table and lib/copilot/request/tools.
Pinning the two direct dependents to 4.3.2 left nine transitive consumers pinned to their own nested 4.3.1, because bun does not re-resolve a lockfile entry that still satisfies its range. The tree therefore kept a vulnerable copy of the package the previous commit was meant to remove. Every one of those consumers asks for ^4.1.x, which 4.3.2 satisfies, so the nesting was lockfile inertia rather than a real constraint. Dropping the stale entries and reinstalling lets them all resolve to the single hoisted 4.3.2. The two js-yaml 3.x consumers, artillery and gray-matter, keep their own copy untouched. Done this way rather than by deleting the lockfile, which re-resolves every floating range and churned 1130 unrelated lines, or by a global override, which would force v4 onto those two v3 consumers. This diff removes nine lines and changes nothing else. Verified: js-yaml 4.3.1 no longer resolves anywhere in the tree, the docs site still builds its 700+ pages through fumadocs, and the desktop suite covering electron-updater passes its 1600 tests.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
 The dependency updates appear safe to merge, with manifests, native packages, and lockfile resolutions remaining coherent.
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
next16.3.1 → 16.3.4 — two critical unauthenticated RCEs (GHSA-p293-qw3h-jr36 on Windows-hosted servers, GHSA-2xp9-vwfh-vxw4 in the Image Optimization API via AVIF). Both are fixed in 16.3.3, but 16.3.3 disables AVIF optimization outright and we requestimage/avifinnext.config.ts; 16.3.4 re-enables it and otherwise carries only backported bug fixessharp0.35.3 → 0.35.4 — libheif RCE (GHSA-rgj7-g3m4-5g8c) via libvips 8.18.6. Also collapses a duplicate install: Next depends on sharp^0.35.3, so the old root pin left a second nested copy loading two libvips builds into one processjs-yaml4.3.1 → 4.3.2 —maxTotalMergeKeysdid not count empty mappings, so a small document could burn CPU without hitting the limit. Both YAML entry points parse user-supplied files with merge keys enabled. The advisory PoC took 13s before and is now refused in 6msnodemailer9.0.1 → 9.1.1 — quadratic addressparser DoS plus three address/content handling bypassescsv-parse6.1.0 → 7.0.2 — prototype replacement reachable via a duplicated__proto__headerjs-yamlso no vulnerable 4.3.1 copy remains anywhere in the treeType of Change
Notes on compatibility
Deliberately one package per commit so each can be reverted independently.
csv-parsecrosses a major, but upstream states 7.0.0 "was published by mistake, there is no breaking changes." Diffed 6.1.0 against 7.0.2 over plain, padded, CRLF, quoted-comma, embedded-tab, unicode-whitespace, ragged, BOM, blank-line and embedded-newline inputs under the exact options we pass. Only difference:trimnow strips non-ASCII whitespace such as U+00A0, matching JStrim(). Record structure and field splitting are byte-identicalnodemailer's newmaxRecipientsdefaults to 100000 (a backstop, not a delivery policy), and the tightenedresolveContentsandbox only governs attachments passed as a file path or URL — we pass content buffersjs-yamldedupe removes nine stale lockfile entries. Every one of those consumers asks for^4.1.x, which 4.3.2 satisfies. Done this way rather than deleting the lockfile (which re-resolved 1130 unrelated lines) or a global override (which would force v4 onto the two v3 consumers)@types/nodemailer8.0.1 is already the latest publishedTesting
Tested manually. Locally verified per package:
bun run lint,bun run check:audits(46/46),bun run type-checkacross all workspaces, production builds ofapps/simandapps/docs, and the full Vitest suite. Also confirmed sharp loads its native binary and round-trips an AVIF encode/decode on libvips 8.18.6, that ordinary YAML merge documents still parse, and thatbun install --frozen-lockfilesucceeds.One pre-existing flake is unrelated to this PR:
lib/copilot/chat/process-contents.test.tstimes out at its 10s limit under shard contention. Reproduced identically on a pristineorigin/stagingcheckout with the original dependency versions.Checklist