CVE-2026-116587 in go-jose
Summary
by MITRE • 10/27/2026
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.6, go-jose parses attacker-controlled RSA modulus and prime values from JWKs without enforcing size and consistency bounds before passing them to crypto/rsa.PrivateKey.Validate. On Go 1.24 and later, crafted large or degenerate RSA parameters can make that validation consume cubic CPU time, allowing remote denial of service in applications that parse JWKs from untrusted sources. This issue is fixed in version 4.1.6.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in the go-jose library prior to version 4.1.6 represents a critical implementation flaw within the handling of JSON Web Key (JWK) structures, specifically affecting RSA key parsing operations. The go-jose package serves as a foundational cryptographic utility for Go-based applications implementing standards such as JSON Web Encryption and JSON Web Signature. When an application utilizes this library to parse JWKs from untrusted or external sources, it extracts the underlying mathematical parameters of the RSA public or private keys, including the modulus and prime values. In versions preceding 4.1.6, the parser fails to enforce strict size constraints or consistency bounds on these extracted values before they are passed to the standard Go crypto/rsa package for validation. This lack of pre-validation allows an attacker to supply malformed JWKs containing excessively large or degenerate RSA parameters that would normally be rejected by security-conscious implementations but are accepted due to this oversight in go-jose.
The operational impact of this flaw is most severe on systems running Go version 1.24 and later, where the underlying crypto/rsa implementation exhibits a cubic time complexity during key validation for certain malformed inputs. By crafting RSA parameters that trigger this specific algorithmic behavior, an attacker can induce a remote denial of service condition. The vulnerability allows for significant CPU consumption without requiring authentication or complex interaction beyond sending a single malicious request containing the crafted JWK. This resource exhaustion can lead to application unresponsiveness, increased latency for legitimate users, and potential infrastructure instability if multiple such requests are processed concurrently. The issue is classified under CWE-20 as Improper Input Validation because the system fails to adequately sanitize or validate user-supplied data before processing it with cryptographic functions that have known performance sensitivities to input size and structure.
From a threat intelligence perspective, this vulnerability aligns with ATT&CK technique T1496, Resource Hijacking, specifically through CPU exhaustion. Attackers can leverage this flaw as part of a broader campaign to disrupt service availability or to mask other malicious activities by overwhelming system resources. The root cause lies in the assumption that downstream cryptographic libraries will handle all edge cases robustly without upstream validation. While the Go standard library's crypto/rsa package is generally secure, its performance characteristics under specific degenerate conditions were not anticipated as a vector for denial of service when combined with permissive input parsing from higher-level abstractions like go-jose. This highlights the importance of defense-in-depth strategies where cryptographic inputs are validated at multiple layers rather than relying solely on the final validation step within low-level libraries.
Mitigation requires immediate upgrading to version 4.1.6 or later of the go-jose library, which implements strict bounds checking for RSA modulus and prime values before they reach the crypto/rsa package. For applications that cannot immediately upgrade, developers should implement custom input validation logic to reject JWKs with key sizes exceeding acceptable thresholds defined by their security policies, typically limiting RSA keys to 2048 or 4096 bits depending on compliance requirements. Additionally, integrating rate-limiting mechanisms and request timeouts can help mitigate the impact of denial-of-service attempts while patching is underway. Security teams should also audit other areas of their codebase where JWKs are parsed from untrusted sources to ensure no similar bypasses exist in related cryptographic handling routines. Regular dependency audits using tools that check for known vulnerabilities in Go modules are essential to maintain a secure posture against such implementation flaws.