CVE-2026-34986
Go-Jose Project Go-Jose 3.0.0 – 3.0.5
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HSummary
CVE-2026-34986 is a high-severity Uncaught Exception (CWE-248) vulnerability in Go-Jose Project Go-Jose. Its CVSS base score is 7.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 48th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-8 (Security and Privacy Engineering Principles) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-34986 is a denial-of-service vulnerability in the Go JOSE library, which implements JavaScript Object Signing and Encryption (JOSE) standards including JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) in Go. In versions prior to 4.1.4 and 3.0.5, decrypting a JWE object triggers a panic if the 'alg' field specifies a key wrapping algorithm (those ending in 'KW', excluding A128GCMKW, A192GCMKW, and A256GCMKW) and the 'encrypted_key' field is empty. The panic occurs in key_wrap.go during cipher.KeyUnwrap() when attempting to allocate a slice with zero or negative length based on the empty encrypted_key. This issue is reachable via ParseEncrypted(), ParseEncryptedJSON(), or ParseEncryptedCompact() followed by Decrypt() on the parsed object, provided the accepted key algorithms include the vulnerable ones.
A remote, unauthenticated attacker can exploit this vulnerability over the network with low complexity by crafting and sending a malicious JWE object that meets the conditions, causing the application to panic and crash. The attack requires the target application to parse and decrypt JWE inputs while accepting the specified key wrapping algorithms; if no such algorithms are accepted, parsing fails safely. Exploitation directly via cipher.KeyUnwrap() with ciphertext under 16 bytes is possible but less common. Successful exploitation results in denial of service due to the panic, with a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and is associated with CWE-248.
The Go JOSE GitHub security advisory (GHSA-78h2-9frx-2jm8) confirms the issue and states it is fixed in versions 4.1.4 and 3.0.5. Security practitioners should upgrade to these patched versions and review applications using Go JOSE for JWE decryption to ensure accepted key algorithms are appropriately restricted, mitigating exposure to crafted inputs.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-19363
Vulnerability Data
Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.4 and 3.0.5, decrypting…
more
a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key. This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected. This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common. Panics can lead to denial of service. This vulnerability is fixed in 4.1.4 and 3.0.5.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer security testing and code review can discover incorrect buffer-size computations before deployment.
Security engineering principles include robust exception management to keep the system in a defined state.
Fail-in-known-state reduces the impact when an uncaught exception occurs by preserving a safe condition.
Input validation can enforce that supplied lengths or counts used in size calculations are within safe bounds.
Error handling requirements force structured catching and response to exceptions instead of allowing them to propagate uncaught.
Memory-protection mechanisms limit the exploitability of an overflow that results from an incorrect size calculation.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices explicitly require structured exception handling to prevent uncaught exceptions from reaching production.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Secure coding standards directly require correct buffer-size calculations.
Security testing can detect uncaught exceptions before production deployment.
Secure development lifecycle includes exception-handling standards that reduce uncaught exceptions.
Application security requirements typically mandate robust error and exception handling.
Secure architecture principles call for centralized, comprehensive exception management.