CVE-2024-14041: ML-KEM (Kyber) decapsulation leaks private key information through non-constant-time division in message decoding and ciphertext compression (KyberSlash)
In Bouncy Castle for Java from 1.73 to before 1.78, three ML-KEM (CRYSTALS-Kyber) routines divided secret-derived polynomial coefficients by the modulus q: Poly.toMsg, which decodes the decrypted message, and the ciphertext compression routines Poly.compressPoly and PolyVec.compressPolyVec. An attacker able to measure the timing of a large number of decapsulations performed with the same long-term private key can recover that key. These are the KyberSlash1 (Poly.toMsg) and KyberSlash2 (ciphertext compression) divisions. Compression performed during encapsulation operates on values that become the public ciphertext and is not affected.
Security readout for executives and security teams
Plain-English summary
This flaw affects Bouncy Castle Java’s Kyber/ML-KEM implementation. If an attacker can observe timing across many decapsulation operations using the same long-term private key, they may recover that key. It is serious for systems using affected post-quantum cryptography, but exploitation requires precise timing conditions and repeated access.
Executive priority
Treat as high priority where Bouncy Castle Java powers post-quantum key exchange or cryptographic services. For organizations not using ML-KEM/Kyber, urgency is lower. The main business risk is compromise of cryptographic private keys under specialized but credible timing conditions.
Technical view
BC-JAVA versions 1.73 to before 1.78 used non-constant-time division on secret-derived Kyber polynomial coefficients in Poly.toMsg, Poly.compressPoly, and PolyVec.compressPolyVec. The issue maps to KyberSlash1 and KyberSlash2. Encapsulation-side compression on public ciphertext values is stated as not affected.
Likely exposure
Exposure is limited to applications using affected Bouncy Castle Java versions for ML-KEM/CRYSTALS-Kyber decapsulation with reusable long-term private keys. Organizations not using Bouncy Castle Java or not using these Kyber routines are unlikely to be affected.
Exploitation context
No KEV listing or provided source indicates active exploitation. Practical attack conditions require measuring timing over many decapsulations against the same private key, making this higher effort but potentially high impact for exposed cryptographic services.
Researcher notes
Focus analysis on reachable decapsulation paths and key reuse. The source states Poly.toMsg and ciphertext compression divisions are affected; encapsulation compression is not. Evidence provided does not establish public exploitation, exploit maturity, or impact beyond affected Bouncy Castle Java implementations.
Mitigation direction
Upgrade Bouncy Castle Java to version 1.78 or later, per the affected range.
Identify applications bundling or depending on bcprov 1.73 through pre-1.78 versions.
Prioritize services performing ML-KEM/Kyber decapsulation with long-lived private keys.
Review vendor advisory and patch commits for implementation-specific guidance.
Consider key rotation after upgrade if exposed long-term keys handled repeated decapsulation requests.
Validation and detection
Inventory Java dependencies for Bouncy Castle bcprov versions.
Confirm whether applications use ML-KEM or CRYSTALS-Kyber functionality.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-208: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-208 · source CWE mapping
Observable Timing Discrepancy
Observable Timing Discrepancy represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.