CVE-2026-116587: 
Terraform Community vulnerability analysis and mitigation

CVE-2026-116587 is a denial-of-service vulnerability in go-jose, a Go implementation of the Javascript Object Signing and Encryption (JOSE) standards including JWE, JWS, and JWT. Prior to version 4.1.6, go-jose parses attacker-controlled RSA modulus and prime values from JSON Web Keys (JWKs) without enforcing size or consistency bounds before passing them to crypto/rsa.PrivateKey.Validate(). On Go 1.24 and later, crafted large or degenerate RSA parameters cause this validation to consume cubic CPU time, enabling remote denial of service. Affected versions include go-jose/v4 ≤ 4.1.5 and go-jose/v3 ≤ 3.0.5 (no patch available for v3). It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Feedly).

The root cause is classified as CWE-407 (Inefficient Algorithmic Complexity) and CWE-770 (Allocation of Resources Without Limits or Throttling). In the vulnerable rsaPrivateKey() function in jwk.go, RSA parameters (N, P, Q) are converted directly to big.Int values and passed to crypto/rsa.PrivateKey.Validate() without any bounds checking. On Go 1.24+, this validation performs operations with cubic time complexity relative to the size of the RSA modulus and primes, meaning an attacker can supply a crafted JWK with an oversized prime (e.g., 16384-bit) embedded in a JWS or JWE header to cause extreme CPU consumption. No special configuration is required — any code path that parses JWKs from untrusted input is vulnerable. A public proof-of-concept is included in the GitHub security advisory, demonstrating the attack using a crafted JWS with a degenerate RSA key (GitHub Advisory, Patch Commit).

Successful exploitation causes excessive CPU consumption on the affected server, leading to service degradation or complete denial of service for applications that parse JWKs from untrusted sources. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue. Any Go application using go-jose v3 ≤ 3.0.5 or v4 ≤ 4.1.5 on Go 1.24+ that accepts JWKs from external or user-controlled input is at risk of being rendered unresponsive (GitHub Advisory).

A public proof-of-concept is included in the official GitHub security advisory, demonstrating exploitation with a crafted JWS containing a degenerate RSA key with a 16384-bit prime. The vulnerability requires no authentication, no privileges, and no user interaction, making it trivially exploitable over the network. As of the time of disclosure, there is no evidence of in-the-wild exploitation, no known threat actor attribution, and the EPSS score is 0.0. The vulnerability is not listed in the CISA KEV catalog (GitHub Advisory, Feedly).

1. Identify target: Find a network-accessible application using go-jose v3 ≤ 3.0.5 or v4 ≤ 4.1.5 on Go 1.24+ that accepts and parses JWKs from user-supplied input (e.g., a JWKS endpoint consumer, a JWT verification service accepting embedded keys).
2. Craft degenerate RSA parameters: Generate a large, degenerate RSA prime (e.g., a 16384-bit odd integer) and arbitrary values for n, e, d, and q. These do not need to form a valid RSA key — only the size matters for triggering the CPU cost.
3. Embed JWK in a JWS or JWE header: Construct a JWS or JWE message with the crafted RSA JWK embedded in the jwk or epk protected header field, as shown in the public PoC.
4. Send the crafted payload: Submit the malicious JWS/JWE to the target application's parsing endpoint (e.g., via HTTP POST).
5. Trigger cubic CPU consumption: The application calls rsaPrivateKey() → crypto/rsa.PrivateKey.Validate(), which performs cubic-time operations on the oversized prime, consuming all available CPU and causing denial of service (GitHub Advisory).

• Network: Unusual or repeated HTTP requests containing large base64-encoded JWK fields (particularly p, q, or n values significantly larger than typical RSA key sizes) in JWS/JWE protected headers.
• Process/System: Sudden spike in CPU utilization on Go application servers, particularly sustained 100% CPU usage on one or more cores without a corresponding increase in legitimate traffic.
• Logs: Application logs showing errors such as go-jose/go-jose: invalid RSA key, modulus too large or p * q != n (on patched versions rejecting malformed input); on unpatched versions, requests may hang or time out without error.
• Application Behavior: Increased response latency or timeouts on endpoints that process JWTs or JWKs, potentially accompanied by OOM-killer events or watchdog restarts of the Go service.

The primary remediation is to upgrade go-jose/v4 to version 4.1.6, which enforces a default maximum RSA modulus size of 4096 bits and validates that p * q == n before calling Validate(). Applications requiring RSA keys larger than 4096 bits can set the MaxRSAModulusBits package variable before any JWK parsing occurs. Note that go-jose/v3 (≤ 3.0.5) has no patch available; users of v3 should migrate to v4.1.6. As a workaround prior to patching, applications should avoid parsing JWKs from untrusted or user-controlled sources, or implement input size validation at the application layer (GitHub Advisory, v4.1.6 Release).

The vulnerability was reported by Yuval Saggie and Mor Weinberger, credited as powered by Echo Frontier, and was published as a GitHub Security Advisory (GHSA-mgcc-cww5-fp2q) by maintainer inahga. The advisory notes that the fix is "not ideal" and that a larger-scale improvement separating RSA computation from JSON parsing is planned for v5. No significant broader media coverage or notable social media reactions have been identified at this time (GitHub Advisory).