mirage-crypto CVE-2026-87732

The vulnerability affects any OCaml application using mirage-crypto before 2.2.0 that calls AES.GCM.authenticate_decrypt_into or Chacha20.authenticate_decrypt_into and either (a) reads from the output buffer without first checking the boolean return value for authentication success, or (b) is subject to compiler or runtime optimizations that expose the buffer contents before the return value is evaluated. The attacker must be able to supply forged ciphertext to the decryption function - typical in network services accepting encrypted tokens, messages, or protocol frames. Exploitation is limited by correct caller discipline: an application that always checks the return value and immediately zeroes the buffer on failure is not vulnerable at the application level, though the library-level flaw persists. There is no authentication requirement imposed by the vulnerability itself; the attack surface depends entirely on whether the vulnerable decryption endpoint accepts unauthenticated input.

The provided CVSS vector (AV:L/AC:L/PR:N/UI:N/I:H) rates this at 6.2, but the local attack vector assignment is questionable - in the dominant real-world use pattern, forged ciphertext arrives over the network (JWE/JWT tokens, protocol messages), making AV:N more accurate. The I:H component is sound: a successful exploitation path allows an attacker to inject forged plaintext into the application's processing pipeline without cryptographic authentication. The 'Jwt Attack' tag corroborates that the intended exploitation scenario involves JOSE/JWT workflows where mirage-crypto handles authenticated decryption of token payloads. Even a mid-sized municipal IT team in mielec running OCaml services with JWT-based authentication should treat this as urgent if their stack depends on mirage-crypto for decryption, since a caller that consumes the output buffer regardless of the boolean return - a common programming oversight - becomes fully vulnerable. EPSS data is absent from the provided intelligence. No KEV listing and no public exploit code have been identified at time of analysis, which limits expected real-world exploitation volume in the short term, but the vulnerability's clean conceptual model means exploit construction is trivial once an attacker identifies a caller that mishandles the return value.

An attacker targeting an OCaml web service that uses mirage-crypto to decrypt JWE tokens submits a crafted token containing arbitrary plaintext with a forged authentication tag. The AES.GCM.authenticate_decrypt_into call writes the attacker-controlled plaintext to the application's claims buffer; if the application's JWT handler extracts and trusts the buffer's contents before checking the boolean return value, the attacker's forged claims are processed as authenticated, enabling privilege escalation or identity spoofing. No public exploit code has been identified, but the attack model requires only the ability to submit forged ciphertext to the target endpoint.