Cloudanix VulnDB

CVE-2026-18036

None

CVSS

—

EPSS

0.3%

Published

Oct 2, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A cryptography library flaw lets attackers steal secret keys by measuring how long certain math operations take, which could expose encrypted data.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
High
Impact
Data Exposure
Component
Library
Class
Cryptographic Weakness
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Timing side-channel leakage during NTRU polynomial modular reductions (modQ and mod3) due to secret-dependent integer division latency in Polynomial and NTRUSampling helpers, exposing private key material on decapsulation and key generation paths.

Why it matters to the business

Risk of NTRU private key recovery in post-quantum cryptography deployments, potentially compromising encrypted communications, key exchanges, and any systems relying on the library for confidentiality.

How an attack unfolds

An attacker capable of measuring operation latency targets the variable-latency divisions in modQ during decapsulation (where the dividend derives from the private key) and in mod3 during key generation, encapsulation, and decapsulation; repeated timing observations on chosen inputs allow statistical recovery of secret polynomial coefficients.

How to fix it

Upgrade Bouncy Castle for Java to version 1.86 or later; the library now replaces variable-latency divisions with masking for modQ (leveraging q as a power of two) and the reference division-free fold-and-select method for mod3.

How to confirm the fix worked

Confirm Bouncy Castle version >= 1.86 in all deployments; perform timing tests on reduction operations to verify absence of operand-dependent latency variations; review release notes for the NTRU helper changes.

Typical attack path

  1. Locate services or applications using vulnerable Bouncy Castle NTRU implementation
  2. Send crafted inputs triggering repeated modQ or mod3 operations on secret values
  3. Measure and collect high-resolution timing data across many executions
  4. Perform statistical analysis on timing distributions to extract private key bits
  5. Reconstruct sufficient key material to break NTRU security

How to detect it

Exploitation leaves no direct artifacts; monitor for anomalous volumes of NTRU decapsulation or key-generation requests that could support timing side-channel collection, and review application or library logs for repeated cryptographic operations involving the same private key material.

What your security team should do

  • Immediately inventory all uses of Bouncy Castle NTRU and schedule upgrades to 1.86+
  • Replace NTRU usage with constant-time post-quantum alternatives where feasible
  • Apply runtime protections or network segmentation for high-value NTRU endpoints pending patching
  • Update dependency scanners and build pipelines to enforce the fixed version

The record

In Bouncy Castle for Java before 1.86, NTRU reduced secret values with the % operator in three helpers whose reference implementations are deliberately division-free, so each reduction was carried out by an integer division whose latency depends on the secret operand. Polynomial.modQ divided by a variable divisor, which a compiler cannot strength-reduce to a multiply the way it can a constant one, so it emitted a division on every call including on the decapsulation path where the dividend derives from the private key; Polynomial.mod3 and NTRUSampling.mod3 divided the secret key polynomials f and g during key generation, the message polynomials r and m during encapsulation, and coefficients recovered during decapsulation. An attacker able to measure that timing can recover information about the NTRU private key. modQ now masks, which is exact because q is always a power of two, and mod3 uses the reference implementation's division-free fold and select; the results are unchanged.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities