High severity · published Oct 23, 2026
CVE-2026-89320
HmacShaCryptor.Hash never hashes its input — returns constant HMAC_K("") for all inputs, voiding CBC-HMAC JWE integrity
New
8.8
CVSS
0.2%
EPSS
No
On KEV
Description
`HmacShaCryptor.Hash` never hashed its input. For any input it returned `HMAC_K("")` — the MAC of the empty message under the key. Every AES-CBC-HMAC JWE produced or verified by gose therefore carried an authentication tag that is constant per key and independent of the message, removing ciphertext integrity entirely.
Exploitation
Is it being used?
Exploit prediction (EPSS)0.2% · higher than 7% of CVEs
Exploited in the wildNo evidence yet
CISA KEVNot listed
Ransomware campaign useNot known
Affected products
Which versions
EK
Eclipse KeyPont - GOSE · Eclipse Foundation
0.9.0 through 0.13.0-rc1; before 1.0.0-rc1 · source: vendor
Affected product
EK
Eclipse KeyPont - GOSE
Eclipse Foundation
More from Eclipse KeyPont - GOSE
6.9
CVE-2026-89318
JweRsaKeyEncryptionDecryptorImpl.Decrypt panics on attacker-chosen IV length (stdlib GCM.Open reached without nonce-size check)
6.9
CVE-2026-89315
JwtClaims.MarshalJSON panics via reflect.StructOf when any untyped claim key is not a valid Go identifier suffix
6.9
CVE-2026-89314
Quadratic-time key_ops duplicate check lets a sub-1 MB JWKS body pin a CPU core for ~15 s
6.9
CVE-2026-89312
AesGcmCryptor.Open passes attacker-controlled nonce to cipher.AEAD.Open without length check, causing panic on wrong-size IV
6.3
CVE-2026-89319
JweDirectDecryptorBlock.Decrypt: unchecked _thales_aad length header reachable with forged tag → index-out-of-range / slice-bounds panic and unbounded allocation