CVE-2026-89318 in gose
Summary
by MITRE • 10/23/2026
`JweRsaKeyEncryptionDecryptorImpl.Decrypt` passed the JWE's initialization vector to `cipher.AEAD.Open` without checking its length. The Go standard library **panics** rather than returning an error when a GCM nonce is not exactly `NonceSize()` bytes, so a JWE carrying a wrong-sized IV crashes the decrypting goroutine.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in the JweRsaKeyEncryptionDecryptorImpl.Decrypt function stems from a critical lack of input validation regarding the initialization vector used for Galois/Counter Mode encryption. In cryptographic implementations utilizing AES-GCM, the nonce or initialization vector must adhere to strict length requirements defined by the underlying cipher specification. Specifically, the Go standard library's implementation of GCM requires that the provided nonce be exactly NonceSize() bytes long. When this constraint is violated, rather than returning a recoverable error code to allow for graceful handling, the runtime triggers a panic. This behavior transforms what should be a simple validation failure into an unhandled exception that terminates the executing goroutine immediately.
From a technical perspective, this flaw represents a classic case of insufficient input validation leading to denial of service conditions. The attacker can craft a malicious JSON Web Encryption payload containing an initialization vector with an incorrect byte length. Upon processing this malformed data, the decryption routine attempts to pass the invalid nonce directly to cipher.AEAD.Open without performing any preliminary checks on its size. Because the Go runtime does not distinguish between logical errors and memory safety violations in this context for GCM nonces, it aborts execution rather than propagating an error state up the call stack. This design choice effectively bypasses standard error handling mechanisms that might otherwise allow the application to log the issue or return a specific authentication failure message to the client.
The operational impact of this vulnerability is severe in terms of availability and service stability. Since each decryption operation typically occurs within its own goroutine, crashing one such routine can lead to resource leaks if not properly managed by higher-level concurrency controls. In high-throughput environments where many concurrent requests are processed simultaneously, an attacker could exploit this flaw to trigger multiple panics, thereby exhausting system resources or causing cascading failures across dependent services. This constitutes a significant denial of service risk, as the application may become unresponsive or require manual restarts to recover from repeated exploitation attempts targeting different decryption endpoints.
This issue aligns with CWE-20 Improper Input Validation and CWE-754: Improper Check for Unusual or Exceptional Conditions. Furthermore, it maps directly to MITRE ATT&CK technique T1499 Endpoint Denial of Service, specifically under the sub-category of resource exhaustion through application crashes. The lack of defensive programming practices in handling cryptographic parameters highlights a gap in secure coding standards where assumptions about input integrity are not explicitly enforced before critical operations are executed.
To mitigate this vulnerability, developers must implement explicit length checks for all initialization vectors and nonces prior to passing them to cryptographic primitives. By validating that the nonce size matches NonceSize() exactly, the application can return a standardized error response instead of allowing a panic condition to occur. Additionally, integrating panics into controlled recovery mechanisms using defer statements with recover functions can provide an additional layer of resilience against unexpected runtime failures. Regular security audits focusing on cryptographic implementation details and adherence to OWASP guidelines for secure cryptography will help prevent similar issues in future development cycles.