CamoFox Browser Case Study

Verified baseline scan — CVE Lite CLI v1.19.1 · 2026-06-05

Summary

• Project: CamoFox Browser — stealth headless browser automation server and OpenClaw plugin for AI agents (anti-detection, Playwright-compatible runtime)
• Revision: ce3a3b085aacba73eb8de6c51733c19fb13bfae4
• Lockfile: package-lock.json (435 resolved packages, npm)
• Lead finding — dual qs remediation: two medium findings on the same advisory class (CVE-2026-8723) with different fix strategies — within-range lockfile refresh vs parent upgrade
• Within-range path: [email protected] via express → body-parser → npm update qs (body-parser already permits 6.15.2+)
• Parent-upgrade path: [email protected] via direct [email protected] → npm install [email protected]
• Baseline findings: 2 unique vulnerable packages (0 critical · 0 high · 2 medium · 0 low)
• OSV advisory matches: 2 CVE/advisory entries (both CVE-2026-8723 on distinct qs versions)
• Direct vs transitive: 0 direct / 2 transitive
• Validated fix command groups generated: 2
• First-pass coverage: 2 of 2 findings have confident copy-and-run commands
• npm audit (same lockfile): 2 moderate entries — totals align with CVE Lite’s deduplicated view
• Remediation applied in this study: none — baseline scan and generated fix plan only

---

What this case study demonstrates

CamoFox Browser sits in the AI agent infrastructure category — browser/runtime tooling rather than SDK-only monorepos (OpenAI Agents JS, Mastra, LangChain.js). At 435 resolved packages, it is one of the leanest graphs in the CVE Lite CLI portfolio: only two vulnerable package versions, both fixable on first pass.

That lean surface makes the remediation mechanics the teaching goal. Maintainer review on #539 specifically called out this snapshot as a showcase for the v1.19.1 within-range transitive fix (the same class corrected in examples/wrong-parent/).

Finding 1 — within-range lockfile refresh

[email protected] — medium, transitive via express → body-parser.

CVE Lite generates:

npm update qs

The output documents why a root npm install [email protected] is unnecessary: [email protected] already allows [email protected] within the declared range. The fix is a lockfile refresh, not a parent bump — the pattern v1.19.1 surfaces instead of suggesting a wrong parent upgrade.

Path: project → express → body-parser → qs

Finding 2 — parent upgrade required

[email protected] — medium, transitive via direct [email protected].

CVE Lite generates:

npm install [email protected]

Here the vulnerable qs is a direct child of express. The declared range on [email protected] does not permit 6.15.2+ without bumping the parent. CVE Lite validates [email protected] as the parent upgrade that drops [email protected] and allows 6.15.2+.

Path: project → express → qs

Why both commands matter

Running only npm update qs fixes the body-parser chain but leaves [email protected] under express. Running only npm install [email protected] fixes the express chain but may not refresh the body-parser nested version without the update command. CVE Lite generates both groups so maintainers see the full plan — not a single misleading one-liner.

---

Comparison Note: CVE Lite CLI vs npm audit

Both tools were run against the same package-lock.json on the same machine on 2026-06-05 (Node.js 22+, npm 10.x).

Metric	npm audit	CVE Lite CLI v1.19.1
Packages parsed / audited	435	435
Total reported findings	2	2
Critical	0	0
High	0	0
Moderate / Medium	2	2
Low	0	0
Direct vs transitive breakdown	✗	✓ (0 / 2)
Deduplicated package view	✓	✓
Within-range vs parent-upgrade distinction	✗	✓
Copy-and-run command groups	partial	✓ (2 groups)
Skipped findings with reason	✗	✓ (0 skipped)

Why the totals align: Both tools see the same two qs versions (6.15.1 and 6.14.2) on CVE-2026-8723. CVE Lite’s value is not inflating or deflating the count — it is separating remediation strategy:

• npm audit may suggest npm audit fix without explaining that one qs row needs a lockfile refresh while the other needs an express parent bump.
• CVE Lite generates npm update qs and npm install [email protected] with explicit reasons tied to each dependency path.

---

Before vs After

No remediation pass was performed for this study. This table records the verified baseline scan only.

Stage	Findings	Critical	High	Medium	Low	Direct	Transitive	Command groups
Baseline (verified)	2	0	0	2	0	0	2	2

Two command groups covering two findings is the ideal outcome for a lean agent-runtime graph — the case study documents how CVE Lite chooses between within-range refresh and parent upgrade on the same CVE.

---

Fix Journey

No commands were run for this study.

What a maintainer should do:

1. Run npm update qs to refresh the body-parser chain toward 6.15.2+.
2. Run npm install [email protected] to resolve the direct express → qs chain.
3. Rescan with cve-lite . --verbose --all and confirm zero findings.

What not to do:

• npm install [email protected] at the root without understanding which chain each version belongs to — may not update both lockfile paths correctly.
• npm audit fix --force without reviewing whether express major-range constraints apply.

---

Why this matters

AI agent projects increasingly ship browser automation sidecars (Playwright, Puppeteer, stealth Firefox wrappers) alongside LLM SDKs. Those services are small npm graphs with real HTTP stack dependencies (express, body-parser, qs) — not abstract devDependency noise.

CamoFox demonstrates that even a 2-finding scan can require two distinct remediation strategies for the same CVE family. Tools that collapse that into one audit fix line hide the difference between:

1. Range already covers the fix → lockfile refresh (npm update qs)
2. Parent must move → validated parent upgrade (npm install [email protected])

That distinction is exactly what v1.19.1’s within-range transitive detection was built for.

---

Scan command

Run from the CamoFox Browser repository root or from the examples/camofox-browser directory in this repository:

cve-lite . --verbose --all

The example lockfile reflects CamoFox Browser at revision ce3a3b085aacba73eb8de6c51733c19fb13bfae4. OSV advisory data changes over time — re-scanning may show different counts on the same revision.

---

Scan verification

Every number in this case study comes from a live scan of the committed fixture at examples/camofox-browser/ in the CVE Lite CLI repository.

Field	Value
Scan date	2026-06-05
CLI version	v1.19.1
CVE Lite command	node dist/index.js examples/camofox-browser --verbose --all --json
npm audit command	npm audit / npm audit --json (Node.js 22+)
Advisory source	OSV (https://api.osv.dev) — online mode
Lockfile source	examples/camofox-browser/package-lock.json from jo-inc/camofox-browser@ce3a3b0
Packages parsed (CVE Lite)	435
Unique vulnerable packages (CVE Lite)	2
Vulnerability entries (npm audit metadata)	2
Fix command groups (CVE Lite)	2
First-pass covered findings (CVE Lite)	2
Skipped findings with reason (CVE Lite)	0

Reproduce CVE Lite locally from the repository root:

npm install
npm run build
node dist/index.js examples/camofox-browser --verbose --all

Reproduce npm audit from the example directory (Node.js 22+ recommended):

cd examples/camofox-browser
npm audit
npm audit --json

Both tools were run against the same package-lock.json on the same machine on 2026-06-05.

---

Remaining risk

All 2 baseline findings remain open at the time of this study. No remediation was applied.

• 2 medium: [email protected] (within-range refresh via npm update qs) and [email protected] (parent upgrade via npm install [email protected])

Both findings share CVE-2026-8723 (remotely triggerable DoS in qs.stringify with comma-format arrays). Both have first-pass commands.

---

Baseline findings

Full vulnerable package list from the verified scan on 2026-06-05 (revision ce3a3b0):

Package	Version	Severity	Relationship	Fix hint	Advisory IDs
qs	6.15.1	medium	transitive	6.15.2 (within-range refresh)	CVE-2026-8723
qs	6.14.2	medium	transitive	6.15.2 (via [email protected])	CVE-2026-8723

---

Want your project reviewed?

If you maintain an interesting JavaScript or TypeScript project and want CVE Lite CLI considered for a public case study, open an issue in the CVE Lite CLI repository.

Please include:

• the repository link
• why the project would make a useful case study
• whether the dependency graph is publicly reproducible

Not every project will be selected. Preference will go to projects that are publicly useful, technically interesting, and strong examples of realistic dependency remediation workflows.