Updated April 7, 2026 (originally published April 1, 2026)

We scanned 8 popular open-source projects for quantum-vulnerable cryptography

Using pqaudit with AST-based and regex detection, we scanned Express, Next.js, Fastify, Prisma, jsonwebtoken, Solana web3, Ethereum web3, and Signal Desktop for algorithms broken by Shor's algorithm. Google's March 2026 paper showed quantum factoring needs 20x fewer qubits than estimated. Here's what we found.

Summary

30,494 files scanned across 8 projects. 6 of 8 are NOT quantum-ready. AST scanning confirmed findings at 95-98% confidence.

Project	Files	Critical	High	Safe	Status
Express	142	0	0	0	PQC Ready
Fastify	295	1	0	0	Not Ready
Next.js	22,535	19	1	36	Not Ready
Prisma	3,297	0	0	9	PQC Ready
jsonwebtoken	65	24	0	0	Not Ready
Solana web3.js	104	17	0	8	Not Ready
Ethereum web3.js	1,194	54	3	62	Not Ready
Signal Desktop	2,862	12	0	52	Not Ready

Results by project

Express

PQC Ready

Minimal HTTP framework with no built-in cryptographic operations. Zero quantum-vulnerable findings.

Fastify

1 critical

295 files RSA Via: ast

RSA — RSA-2048 key generation in test helper (AST-confirmed, 96% confidence)
test/build-certificate.js:20
Fix: ML-KEM-768 (FIPS 203) / ML-DSA-65 (FIPS 204)

Next.js

19 critical, 1 high

22,535 files RSA, ECDSA, ECDH, Ed25519, DH, AES-128 36 AST-confirmed

All findings in compiled vendor bundles (packages/next/src/compiled/), not Next.js core source code. AST scanning confirmed 36 actual crypto API calls with high confidence.

RSA — crypto-browserify bundle with RSA polyfills, AST-confirmed function calls
packages/next/src/compiled/crypto-browserify/index.js
Fix: ML-KEM-768 (FIPS 203)
ECDSA — ECC polyfills and JWT signing patterns in vendor bundles
packages/next/src/compiled/@vercel/og/index.node.js
Fix: ML-DSA-65 (FIPS 204)
AES-128 — Grover's algorithm reduces to 64-bit effective security
packages/next/src/compiled/crypto-browserify/
Fix: AES-256 (trivial upgrade)

Prisma

PQC Ready

ORM/query engine that delegates cryptographic operations to the database and TLS runtime. Zero quantum-vulnerable findings. AST scanning confirmed 4 safe SHA-256 usages for inventory.

jsonwebtoken

24 critical

65 files RSA, ECDSA 9 AST-confirmed

The most finding-dense project. JWT is fundamentally built on RSA and ECDSA — every app using RS256/ES256 inherits this exposure. AST confirmed 9 actual crypto API calls including jwt.sign() with vulnerable algorithm options.

RSA — RS256, RS384, RS512, PS256, PS384, PS512 algorithm definitions. AST confirmed generateKeyPairSync("rsa") calls in tests.
sign.js, verify.js, lib/validateAsymmetricKey.js
Fix: ML-DSA-65 (FIPS 204) — awaiting IETF PQC JWT standards
ECDSA — ES256, ES384, ES512 algorithm definitions
lib/validateAsymmetricKey.js
Fix: ML-DSA-65 (FIPS 204)

Solana web3.js

17 critical

104 files Ed25519, ECDSA (secp256k1)

Ed25519 is Solana's foundation — transaction signing, account addressing, keypair generation all depend on it.

Ed25519 — account generation, transaction signing
src/account.ts, src/keypair.ts, src/transaction/
Fix: ML-DSA-65 — blocked by Solana protocol-level Ed25519 dependency
ECDSA — secp256k1 program (26 occurrences)
src/programs/secp256k1.ts
Fix: ML-DSA-65 — blocked by Ethereum compatibility layer

Ethereum web3.js

54 critical, 3 high

1,194 files ECDSA (secp256k1), AES-128 42 AST-confirmed

secp256k1 ECDSA is Ethereum's signature scheme. AST scanning surfaced 42 additional confirmed ECDSA usages across test suites — up from 12 critical in our initial regex-only scan.

ECDSA — secp256k1 signing in account, transaction, and contract modules. AST confirmed actual function calls at 96% confidence.
web3-eth-accounts/src/account.ts, web3-eth-contract/test/
Fix: ML-DSA-65 — blocked by Ethereum protocol
AES-128 — multiple packages use AES-128
web3-eth-accounts/, web3-utils/
Fix: AES-256 (trivial upgrade)

Signal Desktop

12 critical

2,862 files ECDH (X25519), ECDSA

Signal Protocol has deployed PQXDH (post-quantum extended Diffie-Hellman), but the desktop app still has classical crypto in sticker creation and provisioning.

ECDH — X25519 key exchange in sticker provisioning
sticker-creator/src/util/provisioning.ts
Fix: ML-KEM-768 or hybrid X25519+ML-KEM-768
ECDSA — classical signatures in crypto utilities
ts/AttachmentCrypto.node.ts
Fix: ML-DSA-65 (FIPS 204)

Key takeaways

Most popular JS projects are NOT quantum-ready. The majority rely on RSA or ECDSA for authentication, JWT signing, or key exchange — all broken by Shor's algorithm.
AST scanning reveals more confirmed vulnerabilities. Ethereum web3.js jumped from 12 to 54 critical findings when AST parsing confirmed actual ECDSA function calls across test suites — at 95%+ confidence.
Blockchain libraries are the most exposed. Solana (Ed25519) and Ethereum (secp256k1) are quantum-vulnerable by design. Migration is blocked by protocol-level changes.
JWT libraries are a systemic risk. jsonwebtoken defaults to RS256/ES256 — every app using JWTs likely has quantum-vulnerable signatures.
Symmetric cryptography is fine. AES-256, ChaCha20-Poly1305, and SHA-256 are quantum-resistant. No migration needed.
PQC adoption is near zero in the npm ecosystem. Almost no project uses ML-KEM, ML-DSA, or SLH-DSA yet.

Methodology

All scans used pqaudit with AST-based detection (tree-sitter for JS/TS) and regex pattern matching, dedupe on, min-confidence 50. Projects were cloned at their latest main branch commit on April 7, 2026. AST scanning parses actual code structure — imports, function calls, API usage — providing 95-98% confidence vs 70-85% for regex alone. Findings represent cryptographic usage patterns detected in source code — not confirmed exploitable vulnerabilities. Dependency scanning was enabled for npm projects.

Reproduce any scan yourself:

$ npx pqaudit ./any-project