CVE-2026-46344
Out-of-Bounds Read in liboqs XMSS Signature Verification
Publication date: 2026-05-29
Last updated on: 2026-05-29
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| liboqs | liboqs | to 0.16.0 (exc) |
| open-quantum-safe | liboqs | to 0.16.0 (exc) |
| open-quantum-safe | liboqs | 0.16.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-125 | The product reads data past the end, or before the beginning, of the intended buffer. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is an out-of-bounds read in the XMSS and XMSS^MT signature verification code of the liboqs cryptographic library. It occurs when the verification function is given a correctly-sized signature buffer but a public key whose OID bytes reference a different XMSS parameter set with a larger signature size. The function then misinterprets the signature length and reads beyond the end of the signature buffer.
The out-of-bounds bytes are only used internally for hash computation and are not returned to the caller, so no direct data leak occurs. However, this can cause the verifying process to crash if the read crosses into unmapped memory, resulting in a denial of service.
The issue is fixed in liboqs version 0.16.0 by adding an OID consistency check to ensure the public key's OID matches the expected algorithm before processing the signature buffer.
How can this vulnerability impact me? :
The primary impact of this vulnerability is a potential denial of service caused by a crash in the signature verification process. If the out-of-bounds read accesses unmapped memory, the process verifying signatures may terminate unexpectedly.
There is no known risk of data leakage or acceptance of invalid signatures due to this vulnerability.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in liboqs involves an out-of-bounds read that can cause a denial of service (crash) but does not lead to data exfiltration or invalid signature acceptance.
Since the vulnerability does not result in leakage of sensitive data or compromise of data integrity, it is unlikely to directly impact compliance with data protection regulations such as GDPR or HIPAA.
However, the potential for denial of service could affect system availability, which is a consideration under some compliance frameworks.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability manifests as a possible crash (denial of service) in the verifying process when the verification function reads out-of-bounds memory due to a mismatch between the public key's OID and the declared algorithm's signature size.
Detection involves monitoring for crashes or abnormal termination of processes using liboqs versions prior to 0.16.0 during XMSS or XMSS^MT signature verification.
Since the issue arises from malformed or mismatched public keys, you can detect attempts by checking logs or running tests that verify the consistency of OIDs in public keys against the expected algorithm.
No specific commands are provided in the available resources, but general approaches include:
- Use debugging or monitoring tools (e.g., gdb, strace) to trace crashes in applications using liboqs.
- Run test scripts that call the verification functions with various public keys and signatures to detect out-of-bounds reads or crashes.
- Check application logs for segmentation faults or abnormal exits related to signature verification.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade liboqs to version 0.16.0 or later, where the vulnerability is fixed by adding an OID consistency check to prevent out-of-bounds reads.
If upgrading immediately is not possible, ensure that public keys passed to the verification functions are validated to have matching OIDs consistent with the declared algorithm to avoid triggering the vulnerability.
Additionally, monitor your systems for crashes or denial of service symptoms related to signature verification and restrict untrusted input sources where possible.