Eclipse KeyPont Gose CVE-2026-89319

Exploitation requires the application to use the AES-CBC-HMAC direct decryption path specifically - NewJweDirectDecryptorBlock / JweDirectDecryptorBlock.Decrypt; the AEAD/GCM path (NewJweDirectDecryptorAeadImpl) carries no _thales_aad length header and is not affected. The attacker must supply a crafted JWE whose forged _thales_aad length field survives the HMAC integrity check. In isolation that check requires the MAC key (hence the scored AC:H), but on every affected release (v0.9.0 through v0.13.0-rc1) the chained GHSA-h6w5-722x-2h3m makes the HMAC tag constant and message-independent, so observing one valid JWE and reusing its tag is sufficient. Limiting factors: only the CBC-HMAC path is exposed; impact is restricted to availability (panic/OOM), no data is disclosed or altered; there is no in-release patch, so remediation requires migrating the module path to github.com/eclipse-keypont/gose v1.0.0-rc1+ (rc4 recommended). Interim workaround per the advisory: avoid NewJweDirectDecryptorBlock in favour of the AEAD/GCM path, and recover panics at the request boundary (this limits panic blast radius but does not address the unbounded allocation).

This is a medium-severity, availability-only defect (input CVSS 4.0 base 6.3: AV:N/AC:H/AT:N/PR:N/UI:N with VC:N/VI:N/VA:L), not a confidentiality or integrity issue - the advisory explicitly states confidentiality and integrity are unaffected because the failure occurs after decryption but before any plaintext is returned. The vuln.today decision label is 'this_month' rather than act_now/emergency, consistent with a denial-of-service-only impact. No EPSS score and no CISA KEV entry are present in the input, so there is no signal of widespread or confirmed active exploitation; the only exploitation evidence is a reproducer the Eclipse/GHSA advisory reports as executed against an affected build. The AC:H rating reflects the in-isolation precondition of possessing the HMAC MAC key, but the advisory is explicit that this precondition collapses in every affected release: the chained GHSA-h6w5-722x-2h3m makes the HMAC tag constant per key and message-independent, so an attacker who has observed one valid JWE can forge the _thales_aad header and reuse the tag without knowing the key. Net: a genuine, confirmed DoS on the AES-CBC-HMAC direct-decryption path whose real-world attack complexity is lower than the scored AC:H suggests, but whose overall priority is tempered by availability-only impact and a niche affected library.

An attacker who has observed a single valid JWE forges the _thales_aad protected-header length field and - because the chained GHSA-h6w5-722x-2h3m makes the HMAC tag constant and message-independent - reuses the tag so the integrity check passes. The decryptor then reads an unvalidated 64-bit length and either panics (truncated field or length exceeding the decrypted block) or attempts an allocation up to 2^64-1 bytes, crashing or exhausting the service. The advisory documents an executed reproducer that forges the tag and triggers both the truncated-field and oversized-length failures.