Skip to content

camofox-browser.md

Latest commit

 

History

History
216 lines (141 loc) · 9.52 KB

camofox-browser.md

File metadata and controls

216 lines (141 loc) · 9.52 KB
Raw

CamoFox Browser Case Study

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

CamoFox Browser logo

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: qs@6.15.1 via express → body-parser → npm update qs (body-parser already permits 6.15.2+)
  • Parent-upgrade path: qs@6.14.2 via direct express@4.22.1 → npm install express@4.22.2
  • 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

qs@6.15.1 — medium, transitive via express → body-parser.

CVE Lite generates:

npm update qs

The output documents why a root npm install qs@6.15.2 is unnecessary: body-parser@1.20.5 already allows qs@6.15.2 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

qs@6.14.2 — medium, transitive via direct express@4.22.1.

CVE Lite generates:

npm install express@4.22.2

Here the vulnerable qs is a direct child of express. The declared range on express@4.22.1 does not permit 6.15.2+ without bumping the parent. CVE Lite validates express@4.22.2 as the parent upgrade that drops qs@6.14.2 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 qs@6.14.2 under express. Running only npm install express@4.22.2 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 express@4.22.2 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 express@4.22.2 to resolve the direct express → qs chain.
  3. Rescan with cve-lite . --verbose --all and confirm zero findings.

What not to do:

  • npm install qs@6.15.2 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 express@4.22.2)

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: qs@6.15.1 (within-range refresh via npm update qs) and qs@6.14.2 (parent upgrade via npm install express@4.22.2)

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 express@4.22.2) 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.