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

Using pqaudit, 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,423 files scanned across 8 projects. 6 of 8 are NOT quantum-ready.

ProjectFilesCriticalHighSafeStatus
Express142000PQC Ready
Fastify295100Not Ready
Next.js22,47817144Not Ready
Prisma3,291009PQC Ready
jsonwebtoken652100Not Ready
Solana web3.js1041708Not Ready
Ethereum web3.js1,19412362Not Ready
Signal Desktop2,85412050Not 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
  • RSA — RSA-2048 key generation in test helper
    test/build-certificate.js:20
    Fix: ML-KEM-768 (FIPS 203) / ML-DSA-65 (FIPS 204)

Next.js

17 critical, 1 high
22,478 files ECDSA, RSA, ECDH, Ed25519, DH, AES-128

All findings in compiled vendor bundles (packages/next/src/compiled/), not Next.js core source code.

  • ECDSA — crypto-browserify bundle with ECC polyfills
    packages/next/src/compiled/@vercel/og/index.node.js
    Fix: ML-DSA-65 (FIPS 204)
  • RSA — constants-browserify exposes RSA padding constants
    packages/next/src/compiled/constants-browserify/constants.json
    Fix: ML-KEM-768 (FIPS 203)
  • 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.

jsonwebtoken

21 critical
65 files RSA, ECDSA

The most finding-dense project. JWT is fundamentally built on RSA and ECDSA — every app using RS256/ES256 inherits this exposure.

  • RSA — RS256, RS384, RS512, PS256, PS384, PS512 algorithm definitions
    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

12 critical, 3 high
1,194 files ECDSA (secp256k1), AES-128

secp256k1 ECDSA is Ethereum's signature scheme. All account and transaction signing is quantum-vulnerable.

  • ECDSA — secp256k1 signing in account and transaction modules
    web3-eth-accounts/src/account.ts (6 occurrences)
    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,854 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.
  • 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 v0.2.0 with default settings (dedupe on, min-confidence 50). Projects were cloned at their latest main branch commit on April 1, 2026. Findings represent cryptographic usage patterns detected via regex matching — not confirmed exploitable vulnerabilities. Dependency scanning was enabled for npm projects.

Reproduce any scan yourself:

$ npx pqaudit ./any-project