I scanned 8 popular npm projects for quantum-vulnerable cryptography. Here's what I found.

This week Google published a paper that changed the post-quantum timeline. Breaking ECDSA-256 — the signature scheme protecting Bitcoin, Ethereum, and most of the web — now requires roughly 1,200 logical qubits and under 500,000 physical qubits. That's a 20x reduction from previous estimates.

I wanted to answer a simple question: how exposed are the projects we all depend on?

So I built pqaudit, an open-source CLI that scans source code and npm dependencies for quantum-vulnerable cryptography — algorithms broken by Shor's algorithm (RSA, ECDSA, Ed25519, ECDH, Diffie-Hellman) and weakened by Grover's algorithm (AES-128) — and flags the NIST-approved replacement for each one.

Then I pointed it at 8 popular projects.

The results

Project	Files	Critical	High	PQC Ready
Express	142	0	0	Yes
Fastify	295	1	0	No
Next.js	22,478	17	1	No
Prisma	3,291	0	0	Yes
jsonwebtoken	65	21	0	No
Solana web3.js	104	17	0	No
Ethereum web3.js	1,194	12	3	No
Signal Desktop	2,854	12	0	No

30,423 files scanned. 6 of 8 are not quantum-ready.

Let me walk through the interesting ones.

jsonwebtoken: 21 critical findings in 65 files

This one hit hardest. node-jsonwebtoken is the most popular JWT library on npm — and it's fundamentally built on quantum-vulnerable algorithms.

[!!] RSA — RS256, RS384, RS512, PS256, PS384, PS512
     sign.js, verify.js, lib/validateAsymmetricKey.js
     Fix: ML-DSA-65 (FIPS 204)

[!!] ECDSA — ES256, ES384, ES512
     lib/validateAsymmetricKey.js
     Fix: ML-DSA-65 (FIPS 204)

Every signing algorithm the library supports — RS256, ES256, and their variants — is broken by Shor's algorithm. If your app uses JWTs for authentication (and most Node.js apps do), your auth tokens are signed with quantum-vulnerable cryptography.

There's no PQC JWT standard yet. The IETF is working on it, but it doesn't exist today. This is a systemic gap in the entire web ecosystem.

Solana web3.js: Ed25519 everywhere

Solana's entire identity and transaction model is built on Ed25519:

[!!] Ed25519 — src/account.ts, src/keypair.ts, src/transaction/legacy.ts
     Fix: ML-DSA-65 (FIPS 204) — blocked by Solana protocol

17 critical findings across 104 files. Every account, every keypair, every transaction signature depends on an algorithm that Shor's breaks. The secp256k1 program (for Ethereum compatibility) adds more.

The migration path exists — ML-DSA-65 is the NIST replacement — but it requires a protocol-level upgrade across the entire Solana network. This isn't something you can fix in your app.

Next.js: 17 critical findings (but it's not what you think)

Next.js has 17 critical findings across 22,478 files. Sounds bad, but the nuance matters — every single finding is in vendored bundles, not in Next.js source code:

• crypto-browserify bundled in packages/next/src/compiled/ contains RSA, ECDSA, Ed25519, ECDH, and Diffie-Hellman polyfills
• jsonwebtoken compiled into the same directory
• constants-browserify exposes RSA padding and ECDSA engine constants

Next.js doesn't use quantum-vulnerable crypto itself. But it ships it to every application that depends on it, through vendored dependencies. This is a supply-chain problem.

Signal Desktop: the only one migrating

Signal Desktop had 12 critical findings (X25519 key exchange, ECDSA), but it's also the only project in this scan that has active PQC adoption. pqaudit detected ML-KEM (Kyber) usage through @signalapp/libsignal-client — Signal's implementation of the PQXDH protocol.

Signal is ahead. Everyone else is at zero.

Express and Prisma: PQC ready

Express and Prisma both passed with zero critical findings. The pattern is clear — frameworks that delegate cryptography to the runtime or database layer don't have this problem. The vulnerability lives in libraries that implement or wrap cryptographic primitives directly.

What breaks and what doesn't

Not all cryptography is quantum-vulnerable. Here's the split:

Broken by Shor's algorithm (must migrate):

• RSA (any key size) — key exchange and signatures
• ECDSA, Ed25519, EdDSA — signatures
• ECDH, X25519, Diffie-Hellman — key exchange
• DSA — signatures

Weakened by Grover's algorithm:

• AES-128 — reduced to 64-bit effective security. Fix: use AES-256.

Already quantum-safe (no action needed):

• AES-256, ChaCha20-Poly1305 — symmetric encryption
• SHA-256, SHA-3 — hashing
• ML-KEM (Kyber), ML-DSA (Dilithium), SLH-DSA (SPHINCS+) — the NIST PQC standards

Why this matters now

You might think quantum computers are far away. Google's paper says otherwise. And even before a quantum computer exists, "harvest now, decrypt later" attacks mean adversaries are collecting your encrypted traffic today for future decryption.

The NSA's CNSA 2.0 mandates PQC for new national security systems by January 2027. Google has set a 2029 deadline for its own products. NIST finalized the standards (FIPS 203, 204, 205) in August 2024.

The migration window is open. The first step is visibility — knowing where quantum-vulnerable cryptography lives in your stack.

Try it

npx pqaudit .

One command, no signup, no config. It scans your source code and npm dependencies, classifies findings by severity, and tells you the NIST-approved replacement for each one.

Outputs: human-readable text, JSON, CycloneDX CBOM, or SARIF for GitHub Code Scanning.

For CI/CD:

npx pqaudit . --ci --format sarif --output pqaudit.sarif

It's MIT licensed and on GitHub. Issues and contributions welcome — especially detection rules for languages beyond JavaScript/TypeScript.

Full results

The detailed scan data for all 8 projects is published at pqcworld.com/scan-results.html.