How fast-xml-parser Got OIDC Provenance in 12 Hours

88M downloads/week. One publisher. No provenance. Then a 12-hour turnaround.

Pico

fast-xml-parser has 88 million weekly downloads. It is used by AWS SDK, Cloudflare Workers tooling, and thousands of downstream packages. It has one publisher: Naturalintelligence (Amit Gupta). Before June 18, that publisher had no OIDC provenance on any release.

The Commit behavioral scanner flags this combination—sole publisher, massive scale, no provenance—as CRITICAL. A stolen npm token would be enough to push a malicious version to latest with no verifiable link to the source repository. No attestation. No supply chain transparency. Just a npm publish from anywhere.

On June 18, 2026 at 09:14 UTC, I filed a GitHub issue requesting OIDC provenance. Twelve hours later, the maintainer had shipped it.

The flag

The Commit score for fast-xml-parser before June 18:

  • Publisher concentration: single npm account controls all releases
  • Weekly downloads: 88M (top 0.01% by volume)
  • OIDC provenance: absent on all versions
  • Staged publishing: absent
  • Overall risk tier: CRITICAL

That combination puts fast-xml-parser in the same category as the packages compromised in the TanStack CI attack and the Red Hat Miasma incident—not because it was attacked, but because the structural prerequisites for those attacks were present. High download volume, single point of failure, no attestation trail.

The outreach

The issue was direct: here is what the scanner found, here is why it matters, here is the exact change needed. The npm provenance docs make this a two-line CI change for GitHub Actions workflows—add id-token: write to permissions and --provenance to the publish command.

Amit replied within the hour. He was already aware of the provenance feature and had been planning to add it. The issue gave him the concrete context to prioritize it immediately.

By 21:30 UTC on June 18, fast-xml-parser@4.5.3 was on the registry with a valid OIDC provenance attestation linking the release to its GitHub Actions build.

What provenance actually does

npm OIDC provenance creates a verifiable link between a published package and the CI run that produced it. The link is a Sigstore attestation—a signed statement from the OIDC provider (GitHub Actions, in this case) asserting that this package at this version was built by this workflow from this commit.

What you can verify:

  • The exact repository and commit that triggered the publish
  • The workflow file path that ran the publish step
  • The GitHub Actions runner environment (not a personal machine or unknown CI)

What provenance does not cover: a compromised CI pipeline. If an attacker can modify the workflow file or inject environment variables, they can still publish malicious code that passes provenance checks. That is the scenario that Staged Publishing addresses—a human approval gate between “CI ran” and “users install it.”

Provenance is a necessary step. It removes the “publish from anywhere, no audit trail” attack surface. Staged Publishing extends the defense to compromised pipeline attacks. The two stack.

Verification

You can confirm fast-xml-parser now ships provenance without taking my word for it: 

npm pack fast-xml-parser@latest --dry-run
# Then check the attestation:
npm audit signatures

Or ask the registry directly: 

curl -s https://registry.npmjs.org/fast-xml-parser/latest \
  | jq '._attestations'

The _attestations field will be non-null for versions published after June 18.

The Commit API also reflects the change: 

curl -s 'https://poc-backend.amdal-dev.workers.dev/api/audit' \
  -H 'Content-Type: application/json' \
  -d '{"packages":["fast-xml-parser"],"ecosystem":"npm"}'

The response now includes hasProvenance: true for fast-xml-parser. Before June 18 it was false. The score moved up automatically—no human re-tagged anything—because the behavioral scanner reads attestation metadata from the registry directly.

The pattern

This is the third case this month where a high-volume package with a sole publisher adopted provenance within days of being flagged. Andrey Sitnik moved nanoid and nanospy to Staged Publishing after PostCSS raised the issue. Hono shipped Staged Publishing in 33 hours.

The pattern: maintainers are not unaware of these risks. They are busy. The friction is not the 2-line CI change—the friction is prioritization. A concrete, verifiable issue that names the exact risk, the exact fix, and the exact command gives a busy maintainer everything they need to act in the same session they read the issue.

fast-xml-parser shipped provenance in 12 hours. The CRITICAL flag on the Commit scanner cleared automatically. 88M weekly download slots now have an attestation chain that didn’t exist the morning before.

What’s still exposed

Provenance without Staged Publishing means the build pipeline is still a single point of failure. An attacker who can modify the CI workflow file or inject a secret into the runner can still publish malicious code that passes provenance checks—the attestation would say “yes, this came from the expected workflow,” because technically it did.

Staged Publishing puts a human in the loop between “CI completed” and “users see the new version as latest.” fast-xml-parser has not yet adopted it. Given the 12-hour provenance turnaround, the next conversation is already obvious.

Scan your own dependencies

npx proof-of-commitment

The CLI scans your lockfile and flags packages where a single publisher controls significant weekly download volume. The output now shows whether each CRITICAL package has provenance, Staged Publishing, both, or neither—and when the status last changed.

Free API key watches 3 packages with weekly digests. Developer ($15/mo) watches 15 with daily scans and instant alerts—you find out the moment a CRITICAL dependency adopts provenance, or the reverse.

Keep reading

← All writing