Eclipse KeyPont gose EUVD-2026-108654

Exploitation is limited to JWEs using the AES-CBC-with-HMAC direct path - JweDirectEncryptorBlock / JweDirectDecryptorBlock routed through JweHmacVerifierImpl and HmacShaCryptor; AEAD/GCM modes (NewJweDirectEncryptorAead / NewJweDirectDecryptorAeadImpl) do NOT use this cryptor and are unaffected. The affected software is github.com/ThalesGroup/gose versions >=v0.9.0 through v0.13.0-rc1 (the vulnerable code was never published under github.com/eclipse-keypont/gose). The practical precondition is that the attacker must have observed at least one legitimately produced JWE under the target key to obtain the constant HMAC_K("") tag; no key knowledge, authentication, or user interaction is required (PR:N/UI:N). The chief limiting factor is deployment mode: environments using only the GCM/AEAD path are not exploitable, and the only complete fix requires changing the module import path (go get -u will not remediate), with avoidance of the CBC-HMAC path as the sole in-release workaround.

The signals point to a genuinely serious integrity flaw that nonetheless has a bounded real-world footprint. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) and score of 8.8 describe a network-reachable, unauthenticated issue - consistent with the description, since VerifyCompact processes attacker-supplied compact JWEs with no key or credential knowledge required (PR:N). The impact profile VC:L/VI:H matches the mechanism: integrity is fully broken (the HMAC tag is the constant HMAC_K("") for every message under a key) while confidentiality is only partially affected via downstream padding-oracle/bit-flipping manipulation rather than a direct disclosure. The vuln.today Decision label is this_week, indicating prompt remediation rather than drop-everything emergency. KEV is NOT listed, so there is no confirmed active exploitation; no EPSS score is provided, so exploitation probability cannot be quantified from the input. A reproducer is present in the GHSA advisory (a unit test proving Hash(A)Hash(B)Hash(nil)), demonstrating the flaw, but it is not packaged as a working end-to-end network exploit. One material caveat to the AC:L rating: practical forgery requires the attacker to have first observed at least one legitimately produced JWE under the target key to learn the constant tag - a low but non-zero precondition. The net picture is a high-severity, low-prevalence issue: a real and urgent priority for the specific projects that use gose's AES-CBC-HMAC JWE path, but not a widespread internet-scale emergency given the library's niche adoption and the GCM path being unaffected.

An attacker who has observed a single valid AES-CBC-HMAC JWE issued under a given key learns that its authentication tag is the message-independent constant HMAC_K(""). They then craft an arbitrary ciphertext, IV, and protected header, attach that same tag, and submit it; JweHmacVerifierImpl.VerifyCompact accepts it because both sides reduce to HMAC_K(""), allowing chosen-ciphertext tampering (bit-flipping) and padding-oracle-style manipulation of the recovered plaintext. A public PoC reference exists in the GHSA advisory as a reproducer test; it is not verified as working end-to-end exploit code.