# CWE and CVE: Categorizing PQC Implementation Bugs **Source**: https://quantumsequrity.com/blog/cwe-cve-pqc **Category**: Operations --- [← Back to Blog](../../blog.html) Operations # CWE and CVE: Categorizing PQC Implementation Bugs 11 min read CWE stands for Common Weakness Enumeration. It is a list of categories of software flaw, maintained by MITRE. There are over 900 CWE entries describing patterns like buffer overflows, cross-site scripting, race conditions, and a lot more. CWE is the taxonomy that lets a security researcher say "this bug is an example of CWE-79" and have everyone immediately understand the kind of issue at hand. CVE stands for Common Vulnerabilities and Exposures. A CVE is a specific instance of a flaw in a specific product, with a unique identifier like CVE-2024-12345. Every disclosed vulnerability gets a CVE, and CVEs are tagged with one or more CWEs to explain what kind of weakness produced them. Post-quantum cryptography brings new categories of bugs. Some are familiar: timing leaks, missing input validation, weak randomness. Some are new: failures specific to lattice arithmetic, hash tree state mismanagement, and signature malleability in PQC schemes. This piece walks through the most relevant CWEs for post-quantum implementations and explores what new patterns may need to be added. ## CWE-310: Cryptographic Issues CWE-310 is the parent category for cryptographic weaknesses. It is broad and used as the catch-all when a bug touches crypto but is hard to pin to a more specific subcategory. Most of the more specific CWEs we will discuss are children of CWE-310. For PQC, CWE-310 captures the broad space of "this implementation has a problem in its cryptographic logic". A specific implementation might have CWE-310 because it skips known-answer test vectors, or because it allows weak parameter choices, or because it doesn't fail closed when an algorithm operation fails. The remediation for CWE-310 is process: use approved libraries, run KAT vectors, follow specification carefully. For the broader PQC algorithm context, see [what-is-post-quantum-cryptography](what-is-post-quantum-cryptography.md). ## CWE-327: Use of Broken or Risky Cryptographic Algorithm CWE-327 is one of the most cited cryptographic CWEs and the most directly relevant to PQC migration. The weakness is using an algorithm that is broken or known to be risky. RSA-1024 is risky. SHA-1 is broken. RC4 is broken. In the PQC era, the application of CWE-327 shifts. RSA-2048 is not broken today, but it is increasingly considered risky for long-lived data because of harvest-now-decrypt-later. ECDSA is not broken today, but the same concern applies. NSA's CNSA 2.0 guidance places these algorithms on a deprecation timeline. By 2030, using ECDSA for long-lived signatures may itself be classifiable as CWE-327. The post-quantum migration is essentially the work of moving every CWE-327 candidate forward. Replace RSA with ML-KEM. Replace ECDSA with ML-DSA. The CWE category remains the same; what changes is which algorithms it applies to. For more on RSA's vulnerability, see [why-rsa-2048-will-break](why-rsa-2048-will-break.md). ## CWE-798: Use of Hard-coded Credentials CWE-798 captures the pattern of a private key, password, or other secret being hardcoded into source code. This is dangerous because anyone with access to the code has the secret. The pattern shows up surprisingly often in cryptographic implementations, especially in test code that accidentally ships to production. For PQC implementations, CWE-798 has the same severity. A hardcoded ML-DSA private key is exactly as bad as a hardcoded RSA key. Worse, ML-DSA keys are much larger than RSA keys, so a leaked ML-DSA key in source code is a more visible artifact. The remediation is the same: use proper key storage. HSMs for production keys, environment variables or secrets managers for development. Never check keys into source. ## CWE-200: Information Exposure CWE-200 is a family of weaknesses where information is exposed to unauthorized parties. Side-channel leaks fall under this category. Timing leaks, cache leaks, power analysis leaks, electromagnetic leaks. Each is an information exposure that should not have happened. PQC implementations have their own characteristic side-channel patterns. ML-KEM's matrix multiplication can leak through cache timing if not implemented as constant-time. ML-DSA's rejection sampling has variable latency in naive implementations because the algorithm rejects samples that are out of range. SLH-DSA's tree hashing can leak through memory access patterns. The remediation is to use constant-time implementations. The reference implementations from the NIST submissions are reasonably good but not all are perfectly constant-time. Optimized implementations from libraries like liboqs are typically validated against timing tools. ## CWE-338: Use of Cryptographically Weak PRNG CWE-338 captures use of a pseudorandom number generator that is not cryptographically secure. For PQC, the relevant case is generating private keys and seeds. ML-KEM and ML-DSA both depend on high-quality randomness for key generation. SLH-DSA depends on randomness in its signing process. A PRNG that is not cryptographically secure can produce predictable keys, which is a catastrophic failure. The remediation is to use proper sources: /dev/urandom on Linux, BCryptGenRandom on Windows, or a secure userspace CSPRNG fed from these sources. This CWE is not new to PQC, but PQC implementations need to be careful because the algorithms consume more randomness than RSA or ECDSA. A PRNG that was barely sufficient for ECDSA can be a bottleneck for ML-KEM key generation. ## CWE-208: Observable Timing Discrepancy CWE-208 is closely related to CWE-200 and specifically calls out timing leaks. For PQC, this is a critical category because lattice-based schemes have many places where naive implementations can leak. The classic example is rejection sampling in ML-DSA signing. The algorithm rejects sample candidates that fall outside a target distribution. If the rejection takes a different amount of time than acceptance, an attacker observing many signatures can infer information about the secret key. Constant-time implementations rewrite the rejection step so that the timing is fixed regardless of acceptance or rejection. This is well-understood and the reference implementations get it mostly right, but optimized implementations sometimes regress. For more on CI testing of cryptographic timing, see [pqc-ci-cd-pipelines](pqc-ci-cd-pipelines.md). ## CWE-352 and CWE-345: Authentication Bypass CWE-352 is about cross-site request forgery. CWE-345 is about insufficient verification of data authenticity. Together they describe a class of weakness where signatures are not properly checked or are checked against the wrong data. PQC implementations need to be especially careful about this because the verification logic is more complex. ML-DSA verification involves checking constraints on the unpacked signature, and a buggy unpacking can let invalid signatures through. SLH-DSA verification involves recomputing a Merkle tree path, and a buggy path computation can succeed with the wrong public key. The remediation is to use library verification functions, run KAT vectors that include negative tests (signatures that should fail verification), and treat verification errors as serious. ## New PQ-Specific Weakness Patterns Beyond the existing CWEs, several patterns specific to post-quantum implementations are emerging. These may eventually become their own CWE entries. State management for stateful signatures. LMS and HSS require maintaining state about which one-time keys have been used. If state is lost or rolled back, security is broken. There is no general CWE for this today. The closest existing entries are CWE-664 (improper control of a resource through its lifetime) and CWE-841 (improper enforcement of behavioral workflow). For more on LMS state management, see [lms-stateful-signatures](lms-stateful-signatures.md). Decapsulation failures. ML-KEM and HQC have a small probability of decapsulation failure even with correctly generated keys and ciphertexts. Implementations need to handle these cases without leaking information. A naive implementation that fails differently on decapsulation failure versus other errors leaks bits of the secret key. This is a specific instance of CWE-208 but with PQ-specific twist. For more on ML-KEM details, see [ml-kem-explained](ml-kem-explained.md). Hybrid key combiner errors. Hybrid encryption schemes derive a final key from both a classical and a post-quantum component. The combiner must be correctly implemented or one side can dominate the other. Recent academic work has identified specific combiner constructions that are vulnerable, even when both underlying primitives are secure. For more on hybrid encryption, see [hybrid-encryption](hybrid-encryption.md). Lattice rejection sampling oracles. As noted under CWE-208, naive rejection sampling leaks. There is also a class of attacks that exploits subtle errors in the rejection logic itself, where the implementation accepts samples it should reject. Hash tree path computation errors. SLH-DSA and LMS construct hash trees and verify Merkle paths. Off-by-one errors and incorrect index calculations can cause valid paths to fail and invalid paths to succeed. ## Real CVEs in PQC Implementations Several CVEs have been issued for PQC implementations to date. The pattern is illuminating. Most CVEs in PQC libraries fall into existing CWE categories: timing leaks (CWE-208), buffer overflows (CWE-119), incorrect verification (CWE-345). The PQC angle is the primitive, not the weakness type. This suggests that the existing CWE taxonomy is mostly sufficient to categorize PQ implementation bugs. New entries may emerge for the most distinctive patterns (state management, decapsulation failure handling), but the bulk of the work is applying familiar weakness types to a new family of algorithms. ## How to Use CWE in PQC Code Review For an organization reviewing PQC code, CWE provides the vocabulary for finding patterns: When reading the implementation, ask: which CWEs is this code path susceptible to? Walk through CWE-208 (timing), CWE-200 (information exposure), CWE-345 (insufficient verification), CWE-310 (cryptographic issues). For each one, identify the place where the weakness might appear and verify the code does not have it. When using a third-party library, check whether known CVEs have been issued against it. The NIST National Vulnerability Database is the authoritative source. Filter by CPE (the standardized identifier for software products) and look for any reported issues. When writing your own code (which most teams should not do for novel cryptography), follow the published implementation guides for each algorithm and run extensive KAT vectors. Mistakes in implementations are often caught by KAT vectors that include edge cases. ## CVE Tracking for PQC Libraries The major PQC libraries have CVE histories that organizations should monitor: OpenSSL has had several CVEs in its PQ extensions, mostly around buffer handling in early versions. Tracking OpenSSL CVEs is part of any production deployment. liboqs is the open quantum-safe library and has had CVEs for various algorithms. Some CVEs were in algorithms that did not advance to NIST standardization, so they are less relevant to ML-KEM and ML-DSA users today, but the library's track record is informative. PQClean is a curated repository of clean PQ implementations. It has had relatively few CVEs, partly because the implementations are conservative and partly because the library is consumed by a smaller user base. PQClean is often used as the reference for production PQ code. For broader migration discussion, see [hybrid-migration-strategy-step-by-step](hybrid-migration-strategy-step-by-step.md). ## Reading a CVE Entry for PQC A CVE entry contains structured information that is useful for evaluating PQC issues: The CVE identifier and description tell you what the issue is. PQC CVEs typically reference the algorithm and the specific weakness pattern. The CWE mappings indicate the underlying weakness type. A CVE for an ML-DSA timing leak would map to CWE-208 and CWE-310. The CVSS scores rate severity. PQC issues range from low (theoretical timing leaks in unfavorable conditions) to critical (key recovery from any signature). The CVSS score helps prioritize patching. The affected products list which versions are vulnerable. For PQC libraries, this is usually a range of versions before a specific fix. The references include patches, advisories, and academic papers. PQC CVEs often link to research papers that describe the underlying attack in detail. When triaging a PQC CVE, treat it like any other vulnerability triage but with attention to the threat model. A timing leak that requires millions of signatures to exploit is less urgent than a memory corruption that allows arbitrary code execution. The CVSS score captures this roughly but you should also evaluate against your specific deployment. ## Coordinated Disclosure and PQC PQC research is moving fast, and academic researchers regularly find issues in implementations. The disclosure process matters because publishing a vulnerability before a patch exists puts users at risk. The standard practice is coordinated disclosure: the researcher notifies the maintainer, an embargo period gives the maintainer time to fix, and disclosure happens once the fix is available. PQC research has mostly followed this pattern. For organizations using PQC libraries, the practical implication is to monitor security mailing lists for the libraries you depend on. OpenSSL has a well-established advisory process. liboqs has its own. PQClean is usually disclosed via individual algorithm maintainers. Subscribing to the relevant lists ensures you hear about issues at the moment they are publicly disclosed, not weeks later. ## Frequently Asked Questions **Are there CWEs specifically for PQC bugs?** Not yet. Most PQC bugs fit existing CWE categories. New entries may emerge for the most distinctive patterns over time. **How do I know if my PQC library has CVEs?** Check the National Vulnerability Database (NVD) for the library's CPE. Most major PQC libraries appear in the NVD when they have disclosed issues. **Do I need to scan my PQC code with the same tools as classical crypto code?** Yes. Static analysis, dynamic analysis, and KAT vectors all apply. The mechanics are the same, the algorithms are different. **What is the most common PQC implementation bug?** Timing leaks in rejection sampling (for ML-DSA) and side channels in matrix arithmetic (for ML-KEM) are the most commonly reported issues in pre-release PQ implementations. Validated implementations have largely closed these. **Should I write my own PQC implementation?** No, unless you are an experienced cryptographic implementation engineer working on a research-quality library. Use OpenSSL, liboqs, PQClean, or a similar audited library. ## Sources - [CWE List from MITRE](https://cwe.mitre.org/data/index.html) - [CVE Program Public Database](https://cve.mitre.org/) - [NIST FIPS 203: ML-KEM Standard](https://csrc.nist.gov/pubs/fips/203/final) - [NIST FIPS 204: ML-DSA Standard](https://csrc.nist.gov/pubs/fips/204/final) - [NIST FIPS 205: SLH-DSA Standard](https://csrc.nist.gov/pubs/fips/205/final) - [NIST National Vulnerability Database](https://nvd.nist.gov/) ## Related Articles - [Why RSA-2048 Will Break](why-rsa-2048-will-break.md) - [ML-KEM Explained](ml-kem-explained.md) - [LMS Stateful Signatures](lms-stateful-signatures.md) - [Hybrid Encryption Explained](hybrid-encryption.md) - [Hybrid Migration Strategy Step by Step](hybrid-migration-strategy-step-by-step.md) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)