CVE-2026-49440 Overview
CVE-2026-49440 affects the Deno JavaScript, TypeScript, and WebAssembly runtime prior to version 2.8.1. The node:crypto.checkPrime(candidate[, options][, callback]) and crypto.checkPrimeSync(candidate[, options]) functions performed zero Miller-Rabin rounds when callers left options.checks at its default value of 0. In that mode, candidates were validated only by trial division against primes up to 17,863. Any composite whose smallest prime factor exceeded 17,863, such as the product 17,881 × 17,891, was reported as true (probably prime). The same flaw extended to the lower-level op_node_check_prime and op_node_check_prime_bytes paths used by the polyfill. The issue is fixed in Deno 2.8.1.
Critical Impact
Applications relying on checkPrime for cryptographic parameter validation accept composite numbers as prime, undermining key generation, RSA parameter checks, and protocol-level prime validation.
Affected Products
- Deno runtime versions prior to 2.8.1
- Applications using node:crypto.checkPrime and crypto.checkPrimeSync under Deno
- Code paths invoking op_node_check_prime and op_node_check_prime_bytes
Discovery Timeline
- 2026-06-23 - CVE-2026-49440 published to NVD
- 2026-06-25 - Last updated in NVD database
Technical Details for CVE-2026-49440
Vulnerability Analysis
The vulnerability is a risky cryptographic algorithm implementation flaw [CWE-325] in Deno's Node.js crypto polyfill. The Node.js crypto.checkPrime API documents that when options.checks is set to 0, the runtime selects a number of Miller-Rabin rounds appropriate for the bit length of the candidate. Deno's implementation treated the default literally and ran zero probabilistic rounds. As a result, the primality test collapsed into a single trial-division sieve bounded by the small primes table up to 17,863.
Any composite whose smallest prime factor lies above that bound passes the check. The advisory cites 17,881 × 17,891 as a concrete witness, but the failure mode is general: semiprimes built from primes just above 17,863 are routinely accepted as prime. Downstream cryptographic logic that validates DH groups, RSA moduli, or protocol parameters via checkPrime therefore loses its primality guarantee.
Root Cause
The root cause is incorrect interpretation of the checks default. Node.js treats 0 as a sentinel directing the implementation to choose a safe round count, while Deno executed zero rounds. The same defect is present in the V8 ops op_node_check_prime and op_node_check_prime_bytes that the polyfill delegates to, so callers of either the high-level API or the lower-level binding are affected.
Attack Vector
Exploitation requires an attacker to supply a crafted composite to a Deno application that gates trust on checkPrime. Examples include validation routines that accept user-supplied primes for cryptographic group parameters, key import workflows, and protocol negotiation helpers. The attacker does not need authentication or local access, but must influence the candidate input.
No verified public exploit code is available. See the GitHub Security Advisory GHSA-9xg4-qhm4-g43w for full technical detail.
Detection Methods for CVE-2026-49440
Indicators of Compromise
- Deno runtime processes reporting a version below 2.8.1 via deno --version.
- Application logs showing crypto.checkPrime or crypto.checkPrimeSync invocations without an explicit checks value.
- Cryptographic parameters accepted by the application that fail external primality verification using OpenSSL or GMP.
Detection Strategies
- Inventory all Deno installations across build agents, container images, and developer workstations and compare against the 2.8.1 fixed version.
- Perform static analysis on TypeScript and JavaScript codebases for calls to checkPrime, checkPrimeSync, op_node_check_prime, and op_node_check_prime_bytes.
- Add regression tests that feed known composites with large smallest prime factors, such as 17,881 × 17,891, and assert the function returns false.
Monitoring Recommendations
- Monitor package manifests and lockfiles in CI for deno versions below 2.8.1 and fail builds that pin vulnerable releases.
- Track runtime telemetry for processes loading Deno binaries with outdated version strings.
- Alert when cryptographic validation services produce primality results that disagree with a secondary library such as OpenSSL.
How to Mitigate CVE-2026-49440
Immediate Actions Required
- Upgrade all Deno runtimes to version 2.8.1 or later using deno upgrade.
- Rebuild and redeploy container images that bundle Deno to ensure the patched binary is in production.
- Audit application code for checkPrime and checkPrimeSync callers and pass an explicit checks value sized to the candidate bit length.
Patch Information
The fix is delivered in Deno 2.8.1 through denoland/deno pull request #34391. The patch corrects the default checks handling so Miller-Rabin rounds are executed when callers do not specify a value, restoring parity with Node.js behavior. Coordination details are published in the GitHub Security Advisory GHSA-9xg4-qhm4-g43w.
Workarounds
- Pass an explicit checks parameter, for example crypto.checkPrime(candidate, { checks: 64 }), until the runtime upgrade is complete.
- Validate candidate primes with a secondary library such as Node.js native crypto, OpenSSL bn_is_prime_ex, or a GMP-backed routine before trusting the result.
- Reject untrusted prime candidates at the application boundary when downstream code paths depend on cryptographic primality.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
