mirage-crypto-ec EUVD-2026-74619

Exploitation requires (1) the target application links against mirage-crypto-ec before version 2.2.0, and (2) an attacker can supply or influence the EC public key passed to pub_of_octets - for example, through externally-provided public key material in a TLS certificate, JWT header, cryptographic protocol message, or API input. Applications that use only hardcoded or pre-validated public keys from trusted internal sources are not exploitable in practice. The official CVSS assigns AV:L, but realistic exposure extends to network contexts whenever externally-supplied public keys are accepted. There is no authentication, interaction, or privilege requirement on the attacker's side once they control the public key input.

The official CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, score 6.2) assigns a local attack vector, which likely reflects a conservative, application-agnostic assessment. In practice, if mirage-crypto-ec is used in network-facing protocols that accept externally-supplied public keys - such as TLS certificate validation, JWT verification, or custom cryptographic handshakes common in the MirageOS ecosystem - the effective attack vector is network-reachable, making the 6.2 score a potential understatement of exposure. EPSS data was not provided in the input. No KEV listing and no confirmed public exploit exist at time of analysis, but the cryptographic attack is well-understood and requires no special tooling. Applications that use only internally-stored, pre-validated public keys from trusted sources are not practically exploitable. The primary risk is to authentication and non-repudiation guarantees in any system using this library for ECDSA verification.

An attacker targeting a MirageOS-based service that performs ECDSA signature verification sends the single byte 0x00 as the EC public key in a protocol handshake or authentication token. The library's pub_of_octets accepts this as a valid P256/P384/P521 key, and the attacker then constructs an ECDSA signature that passes verification against this degenerate key. The attacker successfully authenticates or forges a signed message without possessing any private key, bypassing all cryptographic guarantees the application relies on. No public exploit has been identified at time of analysis.