Skip to content

Fuzz the lockfile parsers; fix crashes on hostile lockfiles - #2

Merged
adamtty merged 1 commit into
mainfrom
fuzz-lockfiles
Oct 20, 2026
Merged

adamtty merged 1 commit into
mainfrom
fuzz-lockfiles

Conversation

@adamtty

@adamtty adamtty commented Oct 20, 2026

Copy link
Copy Markdown
Owner

Found while adding fuzzing: a malformed package-lock.json (top-level array, non-object entries, numeric versions, or deep nesting) crashed lock_deps, and since projects() had no guard, one bad lockfile stopped the scan and audit for every project. Fixed (type checks, iterative walk, RecursionError handled, per-file skip), with regression tests, plus Atheris fuzz targets and a Fuzz CI job (Linux).

A package-lock.json that's a JSON array, has non-object entries, numeric
versions, or is nested a few thousand levels deep made lock_deps raise
(AttributeError / RecursionError, the latter even inside json.loads), and
projects() had no guard, so one bad lockfile anywhere in the projects
folder stopped malware and CVE checks for every project.

- Type-check everything read from package-lock.json; walk v1 dependencies
  iteratively; loads() treats RecursionError as unreadable
- projects() skips (and logs) a lockfile it can't parse
- Atheris fuzz targets for the six lockfile parsers (seeded corpus) and
  the projects-folder check; a Fuzz CI job runs them on Linux with a
  per-input timeout and keeps crashing inputs as artifacts
- Regression tests for the crash cases and the seed lockfiles
@adamtty
adamtty merged commit 0cd9d5d into main Oct 20, 2026
9 checks passed
@adamtty
adamtty deleted the fuzz-lockfiles branch October 20, 2026 13:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant