Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
7.5
Go JOSE Panics When Decrypting Certain JWE Objects
GHSA-78h2-9frx-2jm8
CVE-2026-34986
Summary
Go JOSE may crash when decrypting certain encrypted files, potentially causing a denial of service. This happens when it tries to decrypt a file with an empty encryption key. To avoid this, ensure that the list of allowed encryption algorithms does not include key wrapping algorithms, or check the encrypted key before decrypting the file.
What to do
- Update github.com go-jose to version 4.1.4.
- Update github.com go-jose to version 3.0.5.
Affected software
| Vendor | Product | Affected versions | Fix available |
|---|---|---|---|
| github.com | go-jose | <= 4.1.4 | 4.1.4 |
| github.com | go-jose | <= 3.0.5 | 3.0.5 |
| github.com | go-jose | <= 2.6.3 | – |
Original title
Go JOSE Panics in JWE decryption
Original description
### Impact
Decrypting a JSON Web Encryption (JWE) object will panic if the `alg` field indicates a key wrapping algorithm ([one ending in `KW`](https://pkg.go.dev/github.com/go-jose/go-jose/v4#pkg-constants), 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.
### Fixed In
4.1.4 and v3.0.5
### Workarounds
If the list of `keyAlgorithms` passed to `ParseEncrypted()` / `ParseEncryptedJSON()` / `ParseEncryptedCompact()` does not include key wrapping algorithms (those ending in `KW`), your application is unaffected.
If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the `encrypted_key` field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second `.`).
### Thanks
Go JOSE thanks Datadog's Security team for finding this issue.
Decrypting a JSON Web Encryption (JWE) object will panic if the `alg` field indicates a key wrapping algorithm ([one ending in `KW`](https://pkg.go.dev/github.com/go-jose/go-jose/v4#pkg-constants), 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.
### Fixed In
4.1.4 and v3.0.5
### Workarounds
If the list of `keyAlgorithms` passed to `ParseEncrypted()` / `ParseEncryptedJSON()` / `ParseEncryptedCompact()` does not include key wrapping algorithms (those ending in `KW`), your application is unaffected.
If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the `encrypted_key` field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second `.`).
### Thanks
Go JOSE thanks Datadog's Security team for finding this issue.
ghsa CVSS3.1
7.5
Vulnerability type
CWE-248
Published: 3 Apr 2026 · Updated: 3 Apr 2026 · First seen: 3 Apr 2026