[cursor]

Summary

Weekly Dependabot sweep. Fresh yarn npm audit --recursive --all on origin/main surfaced 7 CVEs across 4 root transitive deps whose declared ranges already permit the fixed upstream patch versions, plus a critical Next.js advisory in examples/with-next/. All fixes are lockfile-only — no manifest edits, no new resolutions entries.

Root yarn.lock

Package	Before	After	Advisories
fast-uri (via ajv@8.18.0)	3.1.8	3.1.9	GHSA-w74x-v6f9-j3xg (moderate, URI scheme spoofing), GHSA-xhq7-xmqj-769h (low, path equivalence), GHSA-wjr9-j795-jxcr (moderate, host confusion), GHSA-333x-w4r6-6crp (low, scheme injection)
ip-address (via socks@2.8.7)	10.7.2	10.7.5	GHSA-rxp7-6hxx-x8q5 (moderate, ReDoS in Address6 zone matching)
serialize-javascript (via @rollup/plugin-terser)	7.0.5	7.1.4	GHSA-m5mm-p8h7-m29v (low, XSS via unescaped </script)
undici (via @actions/http-client)	6.29.0	6.29.1	GHSA-4qv8-2p9j-2685 (moderate, EventSource parser DoS), GHSA-xjj6-f33q-929c (high, excessive content-encoding DoS)

examples/with-next/yarn.lock

Package	Before	After	Advisory
next	16.3.8	16.4.3	GHSA-673q-mjm6-r5xr (critical, unauthenticated RCE in use cache functions returning typed arrays; affects >=16.0.0 <=16.4.0)

Manifest range is ^16.3.8, so 16.4.3 is already allowed.

How

Used the lockfile-refresh pattern: deleted the affected package blocks from each yarn.lock and reran yarn install so yarn re-resolved each declared range to the newest matching patch on the registry. The examples/with-next/ lockfile is a yarn 1 lockfile, so I ran yarn 1 in a scratch copy to preserve its format, then copied the resulting yarn.lock back. No resolutions entries added.

Verification

• Root: yarn npm audit --recursive --all --json now reports zero real CVEs (only pre-existing deprecation notices such as eslint 8.57.1 EOL remain, which are not security advisories).
• examples/with-next/: synthetic npm audit (via npm install --package-lock-only) reports 0 vulnerabilities.

Note on GitHub Dependabot alerts page

The GitHub App backing this automation does not have vulnerability_alerts=read, so the Dependabot alerts page cannot be read programmatically. Independent yarn/npm audit output (above) is the signal used for this run — a maintainer may want to eyeball the alerts page to double-check parity.

  

[andrejak]

@cursor can you fix commit messages so they pass the commitlint ci check

[cursor]

I reworded both PR commits so they pass the Angular commitlint preset — chore isn't in that preset's allowed types, but build is (and it matches how this repo tags Dependabot bumps, e.g. build(deps): bump handlebars...):

• bb5c2fc chore(deps): refresh transitive deps to patch 7 CVEs → ac4937a build(deps): refresh transitive deps to patch 7 CVEs
• 604ed9c chore(deps): bump next 16.3.8 -> 16.4.3 in examples/with-next → 6e3f6aa build(deps): bump next 16.3.8 -> 16.4.3 in examples/with-next

Bodies, trailers (Co-authored-by: Andreja Kogovsek), and file changes are unchanged (git diff 604ed9c..HEAD is empty). I ran the repo's commitlint.config.js (@commitlint/config-angular + header-max-length: 80) locally against both new commits — both report 0 problems, 0 warnings. Force-pushed with --force-with-lease to cursor/dependabot-alerts-investigation-dece; the Commitlint check should go green on the next run.