[SECURITY] Patch npm dependency vulnerabilities in FRONTEND-nuxt

[CjuanRcris7]

Dependency Auditing Workshop

Project: InSoLiTo
Owner: JCP
Hosting: GitHub
Stack: npm + Node 22 (Nuxt 4 SPA)
Date: 07/09/2026

---

0. Own research (≈ 15 min)

Complete before sections A–E. See guidance above.

• Looked up best practices for my stack (2–3 prompts)

  • npm dependency audit best practices 2026 lockfile Dependabot.
  • Nuxt Vue project dependency security best practices npm audit.

• Noted 3–5 bullets — at least one to share in the workshop

  • Don't run npm audit fix blindly — check whether the flagged package is in dependencies vs devDependencies and whether the vulnerable code path is actually reachable before deciding to fix it.
  • A Dependabot PR deserves the same review as a code PR: what changed, who published it, and whether new transitive dependencies were pulled in.
  • Nuxt has a dedicated security module (nuxt-security).
  • Lockfile strategy tension: gitignoring the lockfile lets CI resolve fresh (less Dependabot noise) vs. pinning + reviewing every bump deliberately — for an app still under active migration, pinning is safer.

One thing worth discussing with the team:
InSoLiTo has 3 separate package-lock.json files in the same repo: one for the active app (FRONTEND-nuxt/), one for an old version that's being phased out (FRONTEND/, no fixed date yet), and one trivial one at the repo root. If we turn on Dependabot for the whole repo, it'll also open PRs for the old, no-longer-maintained code — noise nobody will act on.

Source(s):

• https://nesbitt.io/2026/01/10/16-best-practices-for-reducing-dependabot-noise.html
• https://claude.ai/new

Applies to my project because:
Most Dependabot advice assumes one active codebase. InSoLiTo has one active and one being retired, in the same repo, at the same time — so we should explicitly decide to scope Dependabot to just FRONTEND-nuxt/ instead of scanning everything by default.

---

A. Inventory (≈ 15 min)

Keep this light — enough context to run the audit.

• Lockfile exists and is committed

  (package-lock.json / pnpm-lock.yaml / yarn.lock / poetry.lock / uv.lock / equivalent)

  • Yes — action: none

• Stack noted — package manager + runtime (e.g. npm + Node 20, Poetry + Python 3.11)

  • Stack: npm + Node 22 + Nuxt 4

• One obvious gap spotted (optional): missing lockfile, very old runtime, or a dependency file out of sync

  • Notes: No engines field in FRONTEND-nuxt/package.json — the project doesn't declare which Node version it needs (developed against Node 22).

---

B. Audit & triage (≈ 45 min)

• Security audit run (npm audit / pnpm audit / pip-audit / poetry / equivalent)
  • Command used: npm audit
  • Critical: 1
  • High: 7
  • Moderate: 1
  • Low: 0
• Each critical and high finding triaged

Package	Advisory / CVE	Reachable?	Fix available?	Breaking?	Decision (fix now / Schedule / Accept / Need help)
@nuxt/devtools <3.3.1	GHSA-279x-mwfv-vcqv (unauthenticated RPC RCE)	Dev-only, own machine — not shipped to prod	Yes	No	Fix now
nuxt 4.0.0–4.5.0	7 advisories — Server Island RCE, SSR payload leak, route rule bypass, DoS	Mostly SSR/Server Island features — app runs ssr:false (SPA), so most of this surface likely doesn't apply in prod (not fully confirmed)	Yes	No	Fix now
brace-expansion 2.0.0-2.1.3 || 4.0.0-5.0.8	GHSA-3jxr-9vmj-r5cp + 2 more (DoS)	Transitive build tooling (glob/minimatch) — no user input at runtime	Yes	No	Fix now
browserslist <=4.28.6	GHSA-c83g-rgw3-j3cx, GHSA-73wf-gq98-2v4g (OOM/crash)	Build-time only (Autoprefixer/PostCSS config)	Yes	No	Fix now
nanoid <=3.3.17	GHSA-28wg-ghj8-5hjv, GHSA-2v37-7h3g-55p8 (infinite loop on bad size)	Not confirmed whether own code calls nanoid directly, or purely transitive	Yes	No	Fix now
postcss <=8.5.22	GHSA-fxqj-rqcc-2cmp, GHSA-r28c-9q8g-f849 (path traversal via sourceMappingURL)	Only processes our own CSS at build time, no external input	Yes	No	Fix now
svgo 4.0.0–4.0.1	GHSA-2p49-hgcm-8545 (removeScripts incomplete)	Only processes our own SVGs (logos/icons), not user-uploaded	Yes	No	Fix now
tar <=7.5.20	GHSA-r292-9mhp-454m (recursion DoS)	Transitive npm tooling, not used to extract user-supplied archives	Yes	No	Fix now

• Accepted risks have a short written reason

  • Notes: None accepted this round — all 8 critical/high findings have a non-breaking fix available via npm audit fix, so there's no finding where accepting the risk instead of fixing made sense.

• Moderate/low noise reviewed lightly (do not chase everything)

  • Notes: 1 moderate finding reported in the audit summary, but its detail didn't show up in the terminal output we reviewed — not individually triaged. Per "don't chase everything," not worth digging further by hand; it should get picked up automatically by the same npm audit fix run in Section D, and re-checked with a fresh npm audit afterward.

---

C. Platform automation check (≈ 10 min)

If GitHub (public repo) → fill the GitHub table below. Record current status only — what is on, off, or needs setup. We decide what to enable in the workshop (see cheat sheet for what each feature gives you).

Do not turn on new GitHub/GitLab features during pre-work unless the team already agreed — bring status and preferences to Day 1.

For each row, pick one:

• Yes — already enabled / working
• Off — available but not enabled (candidate for workshop discussion)
• Need permission — greyed out / org policy; note who to ask
• N/A on Free — not available on your tier (GitLab mainly)

GitHub — Settings → Security and quality (public repo)

GitHub feature	Yes	Off	Need permission	N/A	If enabled, you get…
Security advisories	☑	☐	☐	☐	Publish advisories about vulns in your project; private draft + coordinated disclosure
Dependabot alerts	☐	☑	☐	☐	Security tab alerts when your dependencies have known CVEs
Code scanning alerts	☐	☑	☐	☐	CodeQL findings on push/PR; vulns in your code in Security tab + PR checks
Code quality findings	☐	☑	☐	☐	Quality issues on main branch under Code quality (CodeQL; optional AI findings)

Also check on GitHub:

Feature	Yes	Off	Need permission	N/A	If enabled, you get…
Dependabot security updates	☐	☑	☐	☐	Auto-PRs to patched versions when a dependency alert has a fix
Dependabot version updates (dependabot.yml)	☐	☑	☐	☐	Scheduled PRs to keep deps current
Dependency graph	☐	☑	☐	☐	Dependency tree in Insights; Dependabot uses it to scan your deps

Who to ask if blocked:
Every row has a enable button. Full admin access confirmed. Check decisions with JM.

Features we’d propose enabling (for workshop discussion):

• Dependabot alerts + Dependabot security updates — low effort, directly covers what Section B's manual npm audit already found.
• Secret scanning alerts — currently Disabled, and InSoLiTo has a hardcoded Neo4j credentials in config.json, shipped in the JS bundle.
• dependabot.yml scoped to FRONTEND-nuxt/ only, not the whole repo — per the Section 0 discussion point (avoid noise from the legacy FRONTEND/ frontend mid-retirement).
• Code scanning (CodeQL) — bigger commitment (needs setup + someone reviewing findings), propose as a separate discussion rather than bundling with the quick wins above.

If mostly N/A on Free — what you did instead (local audit, manual PR, etc.):
N/A in this repository

---

D. Safe fixes before Day 1 (≈ 30 min)

Ship what is low-risk. Prefer green tests and small PRs. If time is tight, one small win is enough.

• Patch / minor dependency updates applied where safe
• Unused packages removed (if clear)
• One obviously risky / abandoned dependency replaced or pinned only if easy
• PR opened (link below)

PR link(s):

• [SECURITY] Patch npm dependency vulnerabilities in FRONTEND-nuxt #214

What was fixed:

• All 9 vulnerabilities (1 critical, 7 high, 1 moderate) resolved.

What was deferred:

• The EBADENGINE warning surfaced during the fix — the patched nuxt version now requires Node ^22.19.0, while the local version is 22.18.0, one patch version short. It didn't block the install or development, so this was left for later: either bump the local Node version or add the engines field to package.json (the same gap flagged in Section A).

---

E. Follow-up backlog (≈ 15 min)

List harder work. Estimate size: S (< half day), M (1–2 days), L (multi-day / breaking).

#	Item	Why it matters	Size	Needs help?
1	Add engines field to package.json (Node version pin)	Concrete gap found twice this session — Section A (no version declared) and again when the patched nuxt version started requiring Node ≥22.19.0 with only a silent warning	S	N
2	Enable Dependabot alerts + security updates, scoped to FRONTEND-nuxt/ only via directory: in dependabot.yml	Automates what this session did by hand; scoping avoids noise from the legacy FRONTEND/ frontend mid-retirement (Section 0/C discussion)	S	N
3	Enable Secret scanning alerts and address the known hardcoded Neo4j credentials exposed in the JS bundle (CLAUDE.md, "Known security debt")	Currently Disabled; the credential exposure itself needs the already-planned InSoLiToAPI intermediary layer, not just a config toggle — real architectural work, not a quick fix	L	Y

---

Day 1 summary (fill before the session)

Audit snapshot:

• npm audit on FRONTEND-nuxt found 9 vulnerabilities: 1 critical (@nuxt/devtools, unauthenticated RCE via RPC, dev-only), 7 high (led by nuxt itself, plus brace-expansion, browserslist, nanoid, postcss, svgo, and tar — all in build/dev tooling), and 1 moderate (not individually identified).

Already fixed:

• All 9 — npm audit fix alone crashed (internal npm/Arborist bug tied to a
  broken peer-dependency graph on a newer nuxt version); fixed via a clean
  reinstall with --legacy-peer-deps. 0 vulnerabilities remaining,
  package.json unchanged (all fixes within already-declared ranges), app
  verified working. PR opened, closes [SECURITY] Patch npm dependency vulnerabilities in FRONTEND-nuxt #213.

Still open (critical/high):

• None

Top 3 asks for the team:

1. Add an engines field to package.json pinning the Node version?
2. Enable Dependabot alerts + security updates, scoped only to FRONTEND-nuxt/?
3. Decide on Secret scanning + a real fix for the hardcoded Neo4j credentials?

---

Notes / blockers

Write anything that blocked progress, permission issues, unclear findings, or pairing needs.