Express depends on escape-html. It hasn't been updated since 2015.

Run npx proof-of-commitment express. Express itself scores 89/100 — consistent releases, broad maintainer team, 12+ years of history. But Express's direct dependencies tell a different story.

Two of them score CRITICAL:

• escape-html — score 61, 1 maintainer, 77.9M downloads/week. Last published: September 1, 2015. Version 1.0.3 is the only version this package has ever had, pushed nearly 11 years ago.
• once — score 68, 1 maintainer (isaacs, former npm CEO), 114M downloads/week. Last published: September 2016. Nearly 10 years of no changes, still pulling 114 million weekly installs.

Neither has a CVE. npm audit shows zero issues. But each has an npm token that can publish a new version — and there's no mechanism preventing a compromised token from pushing 1.0.4 tomorrow.

What "no updates since 2015" actually means

The intuitive read: it's stable, nothing needs to change. That's often true. escape-html is a 20-line utility. Once you correctly escape <, >, and &, you're done.

But "hasn't changed" is not the same as "can't change."

The npm account that published escape-html v1.0.3 in 2015 can still publish v1.0.4 today. The only thing standing between that action and 77.9 million weekly installs picking up the new version is the security of that npm token — a credential that may not have been rotated since the Obama administration.

This is the attack vector. Not a code vulnerability. Not a dependency chain. A credential that hasn't been revoked because there was no reason to revoke it.

The axios parallel

On March 30, 2026, axios was compromised. One maintainer, 99M weekly downloads, stolen npm token. Malicious versions published. The attack lasted hours before detection.

Our tool flagged axios as CRITICAL before the attack. escape-html scores 61 — CRITICAL. Not because it has bad code, but because it has the same structural fragility: one person holds the publish key for a package that installs on tens of millions of machines weekly.

The broader picture

Express isn't uniquely problematic. The pattern shows up everywhere:

• supports-color — 422M downloads/week, 1 maintainer (sindresorhus), last release 233 days ago. Pulled by virtually every CLI tool and test runner.
• rimraf — 138M downloads/week, 1 maintainer, CRITICAL. The rm -rf utility of Node.js.
• @types/node — 315M downloads/week, 1 maintainer, CRITICAL. In every TypeScript project.
• chokidar — 167M downloads/week, 1 maintainer, CRITICAL. Watches your files in Vite, webpack, and nodemon.

None have CVEs. All have a sole npm token that, if compromised, would reach hundreds of millions of weekly installs within 24 hours.

What you can do

Understanding the structural risk in your dependency tree is step one. You can't patch this like a CVE — there's no fix to apply. What you can do:

1. Know which packages in your tree are structurally fragile
2. Monitor for unexpected new versions from sole-maintainer packages
3. Use package version pinning in lock files (which you're probably already doing)
4. Check npm provenance when available: npm audit signatures

Audit your dependencies — zero install:

npx proof-of-commitment express    # scores express + direct deps
npx proof-of-commitment --file package-lock.json  # scores full tree

Or use the browser demo at getcommit.dev/audit — paste your own packages or drop a lock file.

---

This scoring is behavioral, not code-scanning. It identifies structural conditions that correlate with successful supply chain attacks — it doesn't predict which packages will be attacked or when. The score is a risk signal, not a verdict.

Tool: proof-of-commitment — open source MCP server, CLI, GitHub Action.