SYN-646: Clear high-severity vuln findings via dependency upgrades - #313
Merged
Conversation
Resolves all 5 high, 3 moderate, and 1 low npm audit findings (9 total, 0 remaining). Most fixes are lockfile-only version bumps within already- declared caret ranges (axios, form-data, js-yaml, brace-expansion, browserslist, json-2-csv, @babel/core) — no package.json range changes needed, and each bump goes as high as the safe patched version allows. The one exception is uuid (transitive via nyc's istanbul-lib-processinfo, which pins ^8.3.2): fixing it requires a semver-major override to ^11.1.1. Verified via full test suite + coverage report that nyc's coverage output is unaffected before keeping this override. lob-node-admin has the same findings and needs an identical set of bumps in a follow-up PR on that repo.
The lockfile-only bump already resolved form-data to 4.0.6 for this repo's own installs, but package.json's dependency range was still ^4.0.5. Since the published lob package ships no lockfile, a fresh `npm install lob` would resolve form-data against that declared range and could still land on the vulnerable 4.0.5 (GHSA-hmw2-7cc7-3qxx, CRLF injection). axios's ^1.16.1 range already covers its fix; this closes the same gap for form-data so the fix reaches consumers of the published package, not just this repo's CI. Caught by adversarial review before merge.
The previous approach forced uuid to ^11.1.1 via an override on istanbul-lib-processinfo, a semver-major jump outside nyc's own declared range (^8.3.2). On closer look that override was fixing a non-issue: the flagged CVE (GHSA-w5hq-g745-h8pq) only affects uuid's v3/v5/v6 functions when a caller passes a custom `buf` argument, and istanbul-lib-processinfo only ever calls uuidv4() with no buf — the vulnerable code path was never reachable through this dependency. The actual fix: istanbul-lib-processinfo@3.0.1 (nyc already declares ^3.0.0, so this is in range) dropped the uuid dependency entirely. Bumping to it via `npm update istanbul-lib-processinfo` removes uuid from the tree altogether, no override needed, no semver violation.
KARSE22
marked this pull request as ready for review
September 1, 2026 21:15
samkitsheth95
approved these changes
Sep 2, 2026
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
2 participants
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.
What problem are you trying to solve?
How did you solve this problem?
npm update. The fixed versions were already inside package.json's existing semver ranges, so this is lockfile-only with no range edits.bufargument, and istanbul-lib-processinfo only callsuuidv4()with none. That code path was never reachable, so the override was pointless. The real fix: istanbul-lib-processinfo@3.0.1, already in nyc's declared range, dropped the uuid dependency entirely, so bumping to it clears the finding with no override.npm install lobwould still resolve the vulnerable floor otherwise. axios's range already covered its fix, form-data's didn't.Important notes
Test plan
npm audit: 0 findings.npm test: 97 unit tests pass, coverage unchanged from main.npm run test:integrationwith TEST_API_KEY and LIVE_API_KEY: 24 tests pass against the live API, covering addresses, postcards, verifications, autocompletions, campaigns, and zip lookups.npm run lint: the 4 errors in test/bankAccounts.js are pre-existing on main, unrelated to this change.