CVE-2024-30172

What it actually does

CVE-2024-30172 is a denial-of-service vulnerability in Bouncy Castle Java Cryptography APIs before version 1.78. The Ed25519 signature verification implementation can enter an infinite loop when processing a specially crafted combination of signature and public key. Any application or service that accepts attacker-controlled Ed25519 signatures for verification may have a processing thread or request handler hang indefinitely, consuming CPU/time resources and degrading availability. The flaw does not directly allow data theft, privilege escalation, or signature forgery; its primary impact is availability loss.

Why it matters to the business

Systems that rely on vulnerable Bouncy Castle versions for Ed25519 signature validation can be made slow or unavailable by unauthenticated remote input if signature verification is exposed through protocols, APIs, authentication flows, token validation, certificate processing, package validation, or secure messaging features. Business consequences may include service outages, failed logins or transactions, degraded API performance, increased infrastructure costs from stuck workers, and customer-facing disruption. The CVSS availability impact is high, but EPSS is currently low and there is no CISA KEV listing, so this should be prioritized based on exposure of Ed25519 verification paths and service criticality rather than evidence of widespread exploitation.

How an attack unfolds

An attacker first identifies an application endpoint, protocol handler, or workflow that verifies Ed25519 signatures using a vulnerable Bouncy Castle Java library. They then submit a crafted public key and signature pair that triggers the defective verification logic. When the application attempts to validate the signature, the verification routine can enter an infinite loop instead of returning success or failure. Repeating this request can tie up application worker threads, CPU capacity, connection pools, or asynchronous processing queues until the service becomes slow, unresponsive, or unavailable. No authentication is required if the affected verification operation is reachable before login or through a public API.

How to fix it

Upgrade Bouncy Castle Java Cryptography APIs to version 1.78 or later wherever used. This includes direct dependencies such as bcprov, bcpkix, bcmail, bcutil, and related Bouncy Castle artifacts, as well as transitive copies bundled inside vendor products, shaded JARs, application servers, containers, and fat JARs. If immediate upgrade is not possible, reduce exposure by disabling or avoiding Ed25519 verification on untrusted input, enforcing strict request timeouts, limiting request body sizes, applying rate limits, isolating signature-verification workers, and using circuit breakers so stuck verification operations cannot exhaust the whole service. Because the affected product list and exact package fixed versions were not provided in the input, use dependency inventory and software composition analysis to locate all Bouncy Castle versions earlier than 1.78 and replace them with a fixed release.

How to confirm the fix worked

Confirm that no deployed application artifact includes Bouncy Castle versions before 1.78. Validate through software composition analysis, dependency lockfiles, Maven/Gradle dependency trees, container image scans, and inspection of packaged JARs for Bouncy Castle implementation metadata. For Maven or Gradle projects, confirm resolved org.bouncycastle artifacts are 1.78 or later. Test externally exposed workflows that perform Ed25519 verification under malformed-input and concurrency conditions to ensure requests fail fast instead of hanging. Operationally, verify that application thread counts, request latency, CPU utilization, and queue depth remain stable when invalid Ed25519 signatures are submitted in a controlled test environment.

Typical attack path

1. Identify a Java application or service using Bouncy Castle Java Cryptography APIs before 1.78.
2. Find an externally reachable feature that performs Ed25519 signature verification on user-supplied data, signatures, keys, certificates, tokens, or messages.
3. Generate or obtain a crafted Ed25519 signature and public key combination that triggers the infinite-loop behavior.
4. Submit the crafted values to the vulnerable verification path.
5. Repeat requests or maintain concurrency to exhaust request handlers, CPU time, job workers, or queues.
6. Cause application latency, request failures, health-check failures, or service outage.

How to detect it

Detection should focus on evidence of attempted or successful denial of service against features that validate Ed25519 signatures. Review application logs, API gateway logs, reverse proxy logs, authentication service logs, token/certificate validation logs, and JVM telemetry for bursts of requests to endpoints that verify signatures followed by increased latency, timeouts, 5xx responses, thread exhaustion, or health-check failures. Look for repeated malformed or invalid Ed25519 public keys/signatures, unusual request rates from a small set of source IPs, and requests that remain active much longer than normal. JVM thread dumps taken during an incident may show threads stuck in Bouncy Castle Ed25519 verification code paths. Because public exploit maturity is listed as none and there is no KEV listing, there are no widely established network payload signatures; organizations should build detections around local application routes and telemetry associated with Ed25519 verification.

• org.bouncycastle.math.ec.rfc8032.Ed25519
• Ed25519.verify
• Ed25519ph.verify
• Ed25519ctx.verify
• bcprov-jdk15on-1.77.jar
• bcprov-jdk18on-1.77.jar
• bcprov-jdk15to18-1.77.jar
• bcprov-jdk14-1.77.jar
• bcprov-ext-jdk15on-1.77.jar
• bcprov-ext-jdk18on-1.77.jar
• bcpkix-jdk15on-1.77.jar
• bcpkix-jdk18on-1.77.jar
• bcmail-jdk15on-1.77.jar
• bcmail-jdk18on-1.77.jar
• bcutil-jdk15on-1.77.jar
• bcutil-jdk18on-1.77.jar
• java.lang.Thread.State: RUNNABLE

What your security team should do

• Inventory all Java applications, containers, vendor products, and build artifacts that include Bouncy Castle Java libraries, including shaded or bundled JARs.
• Prioritize remediation for internet-facing services, authentication systems, API gateways, token-verification components, secure messaging services, and any workflow that verifies Ed25519 signatures from untrusted sources.
• Upgrade all Bouncy Castle Java dependencies to version 1.78 or later and rebuild/redeploy affected applications.
• Where upgrades require longer lead time, add compensating controls such as rate limiting, request timeouts, worker isolation, and monitoring for stuck request threads.
• Review third-party/vendor software that embeds Bouncy Castle and obtain patched versions or vendor confirmation that Ed25519 verification is not exposed.
• Add SCA policy gates to prevent Bouncy Castle Java versions earlier than 1.78 from being introduced into new builds.
• Monitor for availability anomalies consistent with denial-of-service attempts, especially spikes in invalid signature verification errors, long-running request threads, and repeated requests to signature-validation endpoints.