Sample Scanner Report
The synthetic lockfile lists React Native 0.64.0, a handful of packages from its toolchain at versions with published advisories, one clean development package, and one dependency installed from a private git repository. The report below is produced by the same parser, lookup code, and rendering the live scanner uses.
11 advisories matched 7 packages
We checked all 9 package versions against the npm registry advisory database.
1 package entry could not be checked: installed from git, local files, or workspaces instead of the npm registry, or not readable.
React Native 0.64.0 detected. Official support status: Unsupported (as of 2026-09-13). See the release and support status.
What severity means here
Severity is the advisory publisher's rating of the vulnerability in general, usually derived from a CVSS score. It does not tell you whether your app calls the affected code, whether the package ships in your app or only runs in build tooling, or whether anyone is exploiting it. Read each advisory before deciding what to fix first.
Matched advisories
- critical@babel/traverse 7.22.5
- criticalminimist 1.2.5
- critical
- criticalshell-quote 1.7.2
- high
- highreact-native 0.64.0
- high
- high
- high
- high
- medium
Next steps
- Open each advisory and check the patched version. Run
npm explain <package>to see which dependency pulls a package in. - Update to a patched version where one exists (
npm audit fix), then rebuild and test on iOS and Android. React Native packages often need coordinated upgrades. - Prioritize by whether the affected code runs in your shipped app and is reachable with untrusted input, not by severity alone.
- Run
npm auditin CI so new advisories are caught on every dependency change.
This checks published advisories for npm packages only. It does not check your source code, native iOS or Android dependencies, configuration, or whether your app actually uses the affected code. How the scanner works.
| Lockfile format | package-lock.json (lockfileVersion 3) |
|---|---|
| Package versions checked | 9 of 9 |
| Not from the npm registry | 1 |
| Advisory source | the npm registry advisory database |
How to read this sample
- The status comes first. This scan is complete: every registry package version was checked. A partial scan says how many were not, and a failed scan shows no results at all.
- A match means the installed version is inside an advisory's affected range. It does not show that your app uses the vulnerable code. Open each advisory to see what triggers it.
- Severity is not priority. For example, the critical
@babel/traverseadvisory concerns compiling specifically crafted malicious code, according to the advisory. That is build-time exposure, which is a different question from a library that processes untrusted input inside the shipped app. - Direct and transitive tags come from the lockfile. Direct packages are fixed in your package.json. Transitive ones usually move when the package that depends on them is upgraded, which for React Native often means a coordinated upgrade.
- Not checked is not clean. The git dependency is counted as not checked, because registry advisories cannot cover it.
The methodology explains the matching rules, scan states, and limits in full.