Vulnerability feed
CVE and vendor PSIRT advisories from 13 sources, last 30 days. Updated hourly, last run
| Expand | Severity |
Score |
Advisory |
Title |
Source |
Flags |
Published |
|---|---|---|---|---|---|---|---|
| High | 8.8 | CVE-2026-89320 |
`HmacShaCryptor.Hash` never hashed its input
Eclipse Foundation, ThalesGroupEclipse Foundation Eclipse KeyPont - GOSE, Eclipse Foundation gose, ThalesGroup gose
|
NVD | |||
|
CVE-2026-89320`HmacShaCryptor.Hash` never hashed its input
Executive summaryA flaw in the gose Go library's HMAC routine means that AES-CBC-HMAC encrypted JWE messages lose their integrity protection, so an attacker who has seen one valid message can alter ciphertext and still pass verification. The advisory rates the issue High (CVSS 3.1 vector given as AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N, with a score of 8.2 shown). The fix requires consumers to move to a new module path, eclipse-keypont/gose at v1.0.0-rc1 or later, because the original module path has no patched release. Technical summaryThe weakness is CWE-354, improper validation of an integrity check value, in HmacShaCryptor.Hash, which calls hash.Sum(input) without first writing the input, so it always returns HMAC_K("") regardless of input. An attacker on the network who has observed one legitimate AES-CBC-HMAC JWE can reuse its tag on forged ciphertext, headers, and IVs, and the advisory describes CBC malleability and a panic on non-block-aligned ciphertext as consequences. Affected versions are github.com/ThalesGroup/gose >= v0.9.0 and <= v0.13.0-rc1, with no patched release under that path. The fixed version is github.com/eclipse-keypont/gose >= v1.0.0-rc1, reached by changing the module path, and the fix commit is 97f9348. Workarounds are not stated for the affected releases beyond avoiding the AES-CBC-HMAC path and using AEAD/GCM instead. Data protected by affected releases should be treated as unauthenticated and re-encrypted under a patched version. Detection guidance is not stated in the advisory. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from github.com/eclipse-keypont/gose/securit…/GHSA-h6w5-722x-2h3m Impact if exploitedConfidentialityLow IntegrityHigh AvailabilityNone
How it is exploited
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X AffectsEclipse FoundationThalesGroupEclipse Foundation Eclipse KeyPont - GOSEEclipse Foundation goseThalesGroup gose
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.3 | CVE-2026-89316 |
`LoadPublicKey` resolved an EC key's curve with an unchecked type assertion, `algToOptsMap[alg].(*ECDSAOptions)`
Eclipse Foundation, ThalesGroupEclipse Foundation Eclipse KeyPont - GOSE, Eclipse Foundation gose, ThalesGroup gose
|
NVD | |||
|
CVE-2026-89316`LoadPublicKey` resolved an EC key's curve with an unchecked type assertion, `algToOptsMap[alg].(*ECDSAOptions)`
Executive summaryThe advisory says that the gose Go library for JOSE and JWK handling can crash when LoadPublicKey receives an EC key whose declared algorithm is not an EC algorithm. The advisory rates this Low severity, a denial-of-service issue that depends on the calling application forwarding untrusted key documents to the function. The vendor recommends upgrading to github.com/eclipse-keypont/gose v1.0.0-rc4 or later, and it notes that consumers on the old ThalesGroup module path must change the module path, not just the version. Technical summaryThe flaw is an unchecked type assertion of algToOptsMap[alg] to *ECDSAOptions in LoadPublicKey, classified as CWE-248 (Uncaught Exception), which panics when a JWK with kty EC carries a non-EC alg such as RS256, PS256, or RSA-OAEP. The attack vector is network with high attack complexity, and the precondition is that the calling application passes an externally supplied JWK document directly to LoadPublicKey. Affected versions are github.com/ThalesGroup/gose >= 0.7.3, <= 0.13.0-rc1 (patched versions: None stated) and github.com/eclipse-keypont/gose < 1.0.0-rc4, fixed in >= 1.0.0-rc4. The advisory gives a CVSS v3.1 vector of AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L and says the availability impact is low. No workaround beyond not passing untrusted JWKs to LoadPublicKey or validating that kty and alg agree is stated as a mitigation, and no detection guidance is given. Whether exploitation has occurred in the wild is not stated. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from github.com/eclipse-keypont/gose/securit…/GHSA-fv39-8484-f4wr Impact if exploitedConfidentialityNone IntegrityNone AvailabilityLow
How it is exploited
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X AffectsEclipse FoundationThalesGroupEclipse Foundation Eclipse KeyPont - GOSEEclipse Foundation goseThalesGroup gose
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||