CROSS post-quantum signature buffer overflow
Integer underflow of mlen in crypto_sign_open() in the CROSS reference implementation leads to a heap buffer overflow during signature verification.
// Security advisory · Published advisory · CVE-2026-104255 reserved
LMS verification did not bind the signature and public key to the parameter set of the object in use. Reported publicly in issue #2568 and credited as an independent report in the joint advisory; CVE-2026-104255 assigned.
liboqs assigned one generic verify routine to every LMS parameter set. Verification checked neither the declared signature length nor the parameter identifiers in the public key against the OQS_SIG_STFL object in use, so an object created for one LMS parameter set accepted a signature and public key belonging to another.
This is not signature forgery: the signature remains valid under the public key presented with it. Its effect is that liboqs did not enforce the parameter set the caller requested, so an application that takes the expected parameter set from a policy or protocol negotiation and the public key from elsewhere loses that check. Reachable from any caller of OQS_SIG_STFL_verify in a build with OQS_ENABLE_SIG_STFL_LMS=ON, which is not enabled by default.
The same advisory covers fail-open lock handling in LMS signing, which allows LM-OTS key reuse and forgery. That issue, and the fix, are Trail of Bits’ work; the advisory rating (Moderate, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) is for the advisory as a whole.
Identified by Trail of Bits during a security review of liboqs. The parameter-set confusion on verification was independently and publicly reported by 0xiviel (Eva Crystal, XSource Security).
Integer underflow of mlen in crypto_sign_open() in the CROSS reference implementation leads to a heap buffer overflow during signature verification.
Insufficient protection of serialized SSL session/context data can lead to memory-safety issues when restoring tampered or corrupted state. Credited jointly with Haruto Kimura (Stella).
FFDH key exchange lacks contributory-behaviour / peer-key validation, enabling protocol-level abuse. Found independently by Eva Crystal (0xiviel).
Out-of-bounds read in mbedtls_ccm_finish(): an oversized tag_len in the multipart CCM API exposes adjacent CCM context data. Discovered through the Intigriti Trusted Firmware program.