What our npm audits taught us

In March 2026, we used AI-assisted source review to investigate popular npm packages. We looked at code that handled untrusted input, configuration, certificates, and templates, then tried to turn suspicious paths into reproducible cases.

The work produced public advisories and fixes. It also taught us that a package name and a severity label leave out the most useful part of a finding: the conditions under which it works.

Start with the input that changes authority

For each target, we identified an input and followed it toward an operation with security consequences. Could a certificate gain authority it shouldn’t have? Could a connection string replace a trusted option? Could template resolution read outside the intended location?

The agent helped inspect those paths and develop tests. Reviewing the result meant checking callers, defaults, configuration, and existing mitigations. A suspicious function wasn’t enough to establish a vulnerability in a real application.

Certificate validation needed both missing extensions

In node-forge, a certificate-chain verification bypass depended on an intermediate certificate lacking both basicConstraints and keyUsage. Describing it as a bypass with any certificate would be incorrect.

The maintainer advisory records the affected conditions and the fix in version 1.4.0. That detail matters to anyone assessing exposure or building a regression test: supplying a certificate with different extensions tests a different case.

Keep related template issues separate

The Uptime Kuma advisory for CVE-2026-33130 describes authenticated arbitrary file read through notification templates, fixed in 2.2.1.

The related LiquidJS issue has its own identifier, CVE-2026-30952, and its own affected component and fix. Combining them into one broad template-injection claim obscures both the prerequisites and the remediation.

When a report crosses a dependency boundary, name each component’s role. The application may expose the feature while the library supplies the unsafe resolution behavior. Updating one component and restricting the application’s feature are different actions.

Credit the contribution accurately

Research can contribute an original report, a duplicate discovery, a reproducer, or review of a proposed fix. These are all useful, but they aren’t the same credit.

For the jsPDF work, another researcher reported the issues first. Our contribution was remediation review and defense-in-depth feedback. The detailed writeup explains that work; it shouldn’t be counted as an original 0sec discovery.

Count outcomes, not just candidates

The original campaign note recorded 73 findings. That is a campaign-output count, not 73 independently confirmed, newly disclosed vulnerabilities. Download totals also measure package activity, not affected installations.

For a research record, the useful unit is the individual case: conditions, reproduction evidence, disclosure status, public advisory when available, and fix. That structure lets another engineer check what happened without relying on an aggregate headline.