fix(deps): CVE-2026-41907

[octavian-snyk]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages
  are release-note ready, emphasizing
  what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)
• Includes product update to be announced in the next stable release notes

What does this PR do?

Where should the reviewer start?

How should this be manually tested?

npm ci
make build succeed

What's the product update that needs to be communicated to CLI users?

Fix for CVE-2026-41907 (medium vulnerability)

What are the relevant tickets?

CLI-1504

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[octavian-snyk]

context: minimum requirement for the new @snyk/code-client@4.26.2

[robertolopezlopez]

"@snyk/error-catalog-nodejs-public": {
  "uuid@<11.1.1": "^11.1.1"
},
"snyk-nodejs-lockfile-parser": {
  "uuid@<11.1.1": "^11.1.1"
},
"jest-junit": {
  "uuid@<11.1.1": "^11.1.1"
},
"@tapjs/processinfo": {
  "uuid@<11.1.1": "^11.1.1"
}

[octavian-snyk]

Thank you! Nice catch!

[octavian-snyk]

context: devDep to be upgraded in a separate PR; same with tap; (lockfile changes would be big ([+2,415; -1,818 i)

[CatalinSnyk]

But isn't this a dev dependecy? 😅

[CatalinSnyk]

tapjs should also be a dev dependency.

[octavian-snyk]

They (tapjs, jest-junit) are. Sorry, what I mean is that in order to have them use a patched UUID, I have to upgrade these devDeps to a newer major version, which will in turn do big changes to the lockfile.
So what I did instead was to override their transitive UUID package version. 😅

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review High-risk Dependency Override 🟠 [major] Forcing uuid@^11.1.1 via overrides on snyk-nodejs-lockfile-parser and jest-junit is highly likely to cause runtime errors. uuid version 9 and above introduced significant breaking changes, including the removal of the default export and changes to the CLI path. If these packages depend on uuid v3, v7, or v8 (which their original lockfile entries suggest), they will likely fail with 'TypeError: uuid.v4 is not a function' or similar errors when trying to import the module. "@snyk/error-catalog-nodejs-public@4.0.4": { "uuid@<11.1.1": "^11.1.1" }, "snyk-nodejs-lockfile-parser": { "uuid@<11.1.1": "^11.1.1" }, "jest-junit": { "uuid@<11.1.1": "^11.1.1" }, "@tapjs/processinfo": { "uuid@<11.1.1": "^11.1.1" }

📚 Repository Context Analyzed This review considered 11 relevant code sections from 3 files (average relevance: 0.59) package-lock.json (9 segments, lines 3185-3415) package.json (lines 1-241) scripts/windows/install-node.ps1 (lines 1-78)

🤖 Repository instructions applied (from AGENTS.md)

[robertolopezlopez]

question: is this a direct or transitive dependency? asking because it is a quite big bump. I find the current approach in devDependencies more reasonable.

[octavian-snyk]

We also use uuid directly (example) (it can't be fixed by upgrading devDeps alone).