CVE-2026-39829

What it actually does

This vulnerability is a denial-of-service flaw in Go's cryptography implementation for RSA and DSA public key parsing and verification. The affected parsers failed to enforce reasonable size limits on RSA modulus values and DSA parameters. When a crafted oversized public key is used during signature verification, the verifier can spend excessive CPU time performing expensive big-integer operations. Because the issue can be triggered over the network without authentication in protocols that accept client-supplied public keys, such as public key authentication workflows, an attacker can degrade or exhaust service capacity without needing valid credentials. The impact is availability loss only; the flaw does not directly expose data or allow code execution.

Why it matters to the business

Services built with affected Go cryptography components may be vulnerable to CPU-exhaustion attacks that can make authentication endpoints, APIs, SSH-like services, or other public-key-verifying systems slow or unavailable. A successful attack could interrupt customer access, increase infrastructure costs through CPU saturation or autoscaling, and reduce reliability of security-sensitive services. The CVSS score indicates high availability impact, but the currently low EPSS score, flat EPSS trend, lack of known exploited-in-the-wild status, and no reported exploit maturity suggest broad opportunistic exploitation is not currently expected. Organizations with internet-facing services that accept unauthenticated public keys should still prioritize remediation because exploitation is low-complexity once a vulnerable code path is reachable.

How an attack unfolds

An attacker identifies a network-accessible service built with the affected Go cryptography library that performs RSA or DSA public key signature verification before authentication or trust establishment. The attacker crafts a public key containing an excessively large RSA modulus or invalid/oversized DSA parameters. They then submit the key through a protocol path that causes the service to parse the key and attempt signature verification. Because the vulnerable parser does not enforce parameter size limits, the service performs expensive cryptographic big-number operations for an extended period, potentially consuming CPU for minutes per request. By repeating these requests or running them in parallel, the attacker can saturate CPU resources, slow legitimate authentication attempts, exhaust worker pools, and cause partial or complete service unavailability.

How to fix it

Upgrade all applications, services, containers, and vendored dependencies that use the affected golang crypto components to a version containing the fix once available through the relevant Go module, distribution, or vendor channel. The corrected behavior limits RSA moduli to 8192 bits and validates DSA parameters according to FIPS 186-2. If an exact fixed version is not available from the package metadata, monitor upstream Go security advisories and downstream vendor advisories, then rebuild and redeploy affected binaries after dependency updates because Go applications commonly statically link dependencies. As interim mitigations, reject RSA public keys larger than 8192 bits before invoking signature verification, reject non-compliant DSA parameters, disable DSA where possible, enforce request rate limits on unauthenticated public key authentication paths, cap authentication worker concurrency, apply connection throttling, and place CPU-intensive authentication endpoints behind protective controls such as load balancers, WAF/rate-limiting layers, or protocol-aware gateways.

How to confirm the fix worked

Confirm exposure by inventorying Go applications and dependencies that import or vendor golang.org/x/crypto or related cryptographic parsing and public key authentication functionality. Use software composition analysis, SBOMs, go version -m on compiled binaries where applicable, go list -m all for source trees, and container image scanning to identify vulnerable dependency versions. Validate remediation by confirming rebuilt binaries include the fixed dependency version or vendor patch and by testing that oversized RSA keys above 8192 bits and malformed DSA parameter sets are rejected quickly without sustained CPU consumption. In staging, simulate unauthenticated public key authentication attempts with oversized test keys and monitor CPU, request latency, worker saturation, and authentication error handling. Production validation should include confirming rate limits, authentication timeouts, and resource caps are active and that no externally reachable endpoint still accepts oversized public key material.

Typical attack path

1. Identify an internet-accessible service or endpoint that accepts client-supplied RSA or DSA public keys.
2. Determine whether the service is implemented with an affected version of Go's cryptography components or a product embedding them.
3. Generate a malformed or excessively large RSA public key modulus or DSA parameter set.
4. Submit the crafted public key to an unauthenticated public key authentication or signature verification path.
5. Force the target service to spend excessive CPU time parsing and verifying the crafted key.
6. Repeat or parallelize requests to consume available CPU, degrade service performance, or cause denial of service.

How to detect it

Look for evidence of CPU-exhaustion attempts against services that perform public key authentication or signature verification. Relevant log sources include authentication logs, application logs, reverse proxy and load balancer logs, SSH or SSH-like service logs, API gateway logs, EDR telemetry, process accounting, and infrastructure metrics. Investigate time windows with high CPU utilization by Go-based services, long authentication request durations, elevated failed public key authentication counts, connection bursts from a small number of IPs, or errors related to malformed RSA/DSA keys. Where request bodies or protocol metadata are logged, look for abnormally large public key blobs, RSA keys with modulus sizes greater than 8192 bits, DSA parameter validation failures, or repeated pre-authentication disconnects. In host telemetry, correlate sustained CPU consumption in affected service processes with incoming unauthenticated connections. No named threat actors or in-the-wild campaigns are currently associated with this issue, so detection should focus on behavioral indicators rather than actor-specific infrastructure.

• rsa modulus too large
• RSA modulus too large
• DSA parameter validation failed
• invalid DSA parameters
• public key authentication failed
• failed publickey
• Failed publickey
• unsupported key size
• key size exceeds 8192
• modulus exceeds 8192
• ssh-rsa
• ssh-dss
• golang.org/x/crypto
• high CPU during public key authentication
• preauth

What your security team should do

• Prioritize internet-facing services that accept unauthenticated client-supplied RSA or DSA public keys, especially authentication gateways, SSH-like services, API gateways, and custom mutual-authentication protocols.
• Inventory Go-based services and statically linked binaries for use of affected golang crypto functionality; include containers, appliances, vendored modules, and internally built tools.
• Patch or rebuild affected applications as soon as a fixed upstream or vendor-provided version is available; do not assume OS package updates alone remediate statically linked Go binaries.
• Implement compensating controls immediately for exposed services: reject RSA keys over 8192 bits, disable DSA where feasible, enforce authentication timeouts, and rate-limit unauthenticated public key submissions.
• Add monitoring for spikes in failed public key authentication attempts, unusually large public key payloads, high CPU time per authentication request, and repeated connections from the same source ranges.
• Tune autoscaling and load-shedding policies carefully so an attack does not create uncontrolled infrastructure cost while still preserving service availability.
• Because there is no current KEV listing, ransomware association, or mature public exploit signal, handle as high-priority for exposed systems rather than emergency enterprise-wide disruption.