CVE-2024-29857

What it actually does

This vulnerability is a denial-of-service flaw in Bouncy Castle elliptic-curve certificate parsing. When an application imports or validates an X.509 certificate containing specially crafted binary-field elliptic curve parameters, the affected ECCurve implementations can spend excessive CPU evaluating those parameters. The flaw is remotely triggerable wherever untrusted certificates are accepted, parsed, or validated, such as TLS client certificate authentication, SAML/OIDC certificate handling, signed-token validation, certificate upload workflows, mTLS gateways, or identity integrations that process attacker-supplied certificates. It does not provide code execution or data disclosure, but it can exhaust CPU and degrade or stop certificate-processing services.

Why it matters to the business

Successful exploitation can make authentication, identity federation, TLS/mTLS, API gateways, or certificate-processing workflows slow or unavailable. Because the vulnerable code is in a widely used cryptographic library and can be reached through common certificate-handling paths, downstream applications may inherit the risk even if they do not directly expose Bouncy Castle functionality. The CVSS score indicates high availability impact, although EPSS is currently low and the issue is not in CISA KEV, so prioritization should focus on internet-facing or authentication-critical systems that parse untrusted certificates.

How an attack unfolds

An attacker identifies an application path that accepts or processes certificates using an affected Bouncy Castle version. The attacker then supplies a malicious EC certificate containing crafted F2m curve parameters. During certificate import, parsing, or validation, the vulnerable ECCurve logic performs expensive parameter evaluation and consumes excessive CPU. Repeated submissions or concurrent connections can tie up application worker threads, saturate CPU, increase request latency, and potentially cause service timeouts, health-check failures, or application restarts. The attack requires no authentication or user interaction if the certificate-processing endpoint is publicly reachable.

How to fix it

Upgrade affected Bouncy Castle components to fixed versions: BC Java 1.78 or later, BC Java LTS 2.73.6 or later, BC-FJA 1.0.2.5 or later, and BC C#/.NET 2.3.1 or later. For the listed downstream package, update umbraco/umbracoidentityextensions to a revision containing commit e792429f9d1fa25c1ba4f7a61d23ee02fedd6dc9 or a later maintained release that includes the fix. Review transitive dependencies because applications may include Bouncy Castle through identity, cryptography, SAML, OAuth/OIDC, PDF signing, CMS, or certificate-management libraries. If immediate upgrade is not possible, restrict certificate-upload and certificate-import endpoints, require authentication where feasible, rate-limit certificate-processing requests, cap request body sizes and TLS handshakes per source, isolate certificate parsing in resource-limited worker pools, and reject unsupported or unnecessary EC binary-field curves if application requirements allow it.

How to confirm the fix worked

Confirm dependency resolution shows fixed Bouncy Castle versions in all build artifacts, containers, application packages, and runtime classpaths. For Java, inspect dependency trees, shaded JARs, and deployed libraries for bcprov, bcpkix, bc-fips, or related Bouncy Castle artifacts older than the fixed versions. For .NET, inspect NuGet package versions and deployed assemblies for BouncyCastle.Cryptography or legacy BouncyCastle packages older than 2.3.1. For umbraco/umbracoidentityextensions, verify the deployed code includes commit e792429f9d1fa25c1ba4f7a61d23ee02fedd6dc9 or a later fixed revision. Exercise representative certificate-processing workflows with valid certificates and ensure normal behavior. Where safe and authorized, use a controlled regression test for malformed EC F2m certificates to confirm parsing fails quickly and does not cause sustained CPU spikes.

Typical attack path

1. Find an exposed workflow that accepts, imports, validates, or negotiates attacker-controlled certificates.
2. Confirm the target application or dependency chain uses an affected Bouncy Castle Java, Bouncy Castle LTS, BC-FJA, or Bouncy Castle C#/.NET version.
3. Craft an EC certificate with malicious F2m curve parameters designed to trigger excessive CPU use during curve evaluation.
4. Submit the certificate through TLS/mTLS negotiation, certificate upload, SAML/OIDC metadata handling, signed-message validation, or another certificate-processing path.
5. Repeat requests or open concurrent sessions to amplify CPU exhaustion and degrade application availability.
6. Maintain pressure until authentication, API, identity, or certificate-processing services become slow, unavailable, or unstable.

How to detect it

Investigate whether systems experienced unexplained CPU saturation correlated with certificate parsing, TLS/mTLS negotiation, certificate uploads, SAML/OIDC metadata ingestion, or identity-provider certificate refresh activity. Review application logs for certificate validation exceptions, EC curve parsing errors, ASN.1 parsing failures, repeated failed TLS handshakes, request timeouts, and high-latency requests involving certificate import or authentication endpoints. Review web, API gateway, reverse proxy, load balancer, and TLS termination logs for repeated connections or POSTs from the same sources to certificate-processing routes. Correlate with host telemetry showing sustained high CPU in Java or .NET application processes without proportional request volume. In Java environments, thread dumps during suspected activity may show worker threads in Bouncy Castle elliptic-curve or ASN.1 certificate parsing code. In .NET environments, traces may show high CPU in BouncyCastle cryptography or certificate parsing routines. Because exploitation primarily causes resource exhaustion, durable file, registry, or network IOCs are unlikely unless application logs capture the offending certificate payload or exception details.

• org.bouncycastle.math.ec.ECCurve
• org.bouncycastle.math.ec.ECCurve$F2m
• BouncyCastle.Math.EC.ECCurve
• BouncyCastle.Math.EC.F2mCurve
• F2m
• characteristic-two field
• binary field
• X.509 certificate parsing failed
• certificate validation failed
• invalid EC parameters
• error parsing certificate
• ASN1
• ASN.1
• bcprov
• bcpkix
• BouncyCastle.Cryptography
• high CPU during certificate import
• TLS handshake failed
• client certificate validation failed

What your security team should do

• Inventory all applications and services that process untrusted certificates and identify Bouncy Castle Java, LTS, FIPS/FJA, and .NET usage, including transitive and shaded dependencies.
• Prioritize patching internet-facing, authentication-critical, SSO, mTLS, API gateway, and certificate-upload services first.
• Upgrade to fixed Bouncy Castle versions or downstream releases that include the fix, including umbraco/umbracoidentityextensions commit e792429f9d1fa25c1ba4f7a61d23ee02fedd6dc9 or later where applicable.
• Apply compensating controls until patched: rate limiting, request-size limits, handshake limits, certificate-type restrictions, and resource isolation for certificate parsing.
• Monitor for repeated certificate parsing failures, TLS handshake failures, abnormal CPU saturation, and request bursts targeting certificate-processing endpoints.
• Add dependency scanning rules to flag vulnerable Bouncy Castle versions across source repositories, CI pipelines, container images, and deployed artifacts.