CVE-2025-8916

What it actually does

This is a denial-of-service weakness caused by unbounded or insufficiently throttled resource allocation in Bouncy Castle Java certificate path review code, specifically PKIXCertPathReviewer implementations in the bcpkix and bcprov API modules and BCPKIX FIPS. When a vulnerable application processes attacker-controlled X.509 certificate paths or related PKIX validation inputs through the affected APIs, specially crafted inputs can trigger excessive memory allocation or CPU/garbage-collection pressure. The expected impact is reduced availability of the affected application process, such as latency spikes, request failures, thread starvation, heap exhaustion, or process restart. The vulnerability is not expected to directly allow data theft, privilege escalation, or code execution.

Why it matters to the business

Applications that rely on affected Bouncy Castle Java versions for certificate validation, signed-object processing, S/MIME, mutual TLS, document signing, package verification, or other PKIX workflows may be made unstable or temporarily unavailable by maliciously crafted certificate-related input. The operational consequence is service degradation or outage rather than compromise of sensitive data. The CVSS signal indicates low availability impact, EPSS is currently low at 0.00461, it is not listed in CISA KEV, and no mature public exploitation is indicated, so remediation should be prioritized based on exposure of certificate-processing paths to untrusted network input. Because Bouncy Castle is commonly embedded as a transitive Java dependency, organizations should assess SBOMs and dependency trees rather than only checking directly declared packages.

How an attack unfolds

An attacker first identifies an application endpoint, protocol flow, or file-processing feature that causes the server to invoke Bouncy Castle PKIX certificate path review APIs on untrusted input. Examples include client-certificate authentication, certificate-chain upload or enrollment workflows, validation of signed documents or messages, or services that inspect externally supplied certificates. The attacker then supplies a malformed or unusually structured certificate path designed to cause the vulnerable PKIXCertPathReviewer logic to allocate excessive resources. If the application processes the input synchronously or without adequate request, memory, or concurrency limits, the crafted validation attempt can consume heap, increase garbage-collection time, or tie up worker threads. Repeating the request can amplify the effect into visible service degradation or process failure. Exploitation requires that the vulnerable code path be reachable with attacker-controlled certificate material; systems that include the library but do not process untrusted PKIX inputs through the affected APIs are less exposed.

How to fix it

Upgrade affected Bouncy Castle components to fixed releases from the vendor-maintained line. The vulnerability description identifies BC Java bcpkix and bcprov versions 1.44 through 1.78 as affected, and BCPKIX FIPS versions 1.0.0 through 1.0.7 and 2.0.0 through 2.0.7 as affected; use the first vendor-fixed version newer than those affected ranges, or the latest available compatible release. Check direct and transitive dependencies for Maven coordinates such as org.bouncycastle:bcpkix-jdk*, org.bouncycastle:bcprov-jdk*, and BCPKIX FIPS artifacts. If immediate upgrade is not possible, reduce exposure by rejecting oversized or deeply nested certificate chains before validation, enforcing request body size limits, limiting certificate count and extension size, applying per-request timeouts, constraining concurrent certificate-validation operations, and running services with memory limits and automatic restart policies. The supplied product metadata references gofiber/fiber fixed at commit e115c08b8f059a4a031b492aa9eef0712411853d, which does not align with the Bouncy Castle Java vulnerability description; verify the authoritative advisory and package coordinates before closing remediation evidence.

How to confirm the fix worked

Confirm remediation by generating an SBOM or dependency tree for each Java application and verifying that no affected Bouncy Castle bcpkix, bcprov, or BCPKIX FIPS versions remain in runtime artifacts, shaded JARs, application servers, container images, or bundled libraries. For Maven, review `mvn dependency:tree`; for Gradle, review `gradle dependencies`; for containers, scan expanded layers and application JAR/WAR/EAR files. Validate that runtime classpaths do not load affected Bouncy Castle JARs even if source manifests have been updated. Exercise certificate-processing workflows with normal and boundary-size certificate chains while monitoring heap, garbage collection, latency, and error rates. Confirm that request size limits, validation timeouts, concurrency limits, and restart policies are effective. Where the fixed-version source is unclear because of conflicting metadata, validate against the upstream Bouncy Castle advisory and the actual package versions present in deployed artifacts.

Typical attack path

1. Identify an internet-facing or network-reachable application that performs certificate path validation or PKIX review using Bouncy Castle Java APIs.
2. Determine a reachable feature that accepts attacker-controlled certificate material, signed content, or certificate chains without prior strict size and complexity limits.
3. Craft certificate path input intended to trigger excessive allocation in PKIXCertPathReviewer processing.
4. Submit the crafted input to the vulnerable service via the relevant protocol or application endpoint.
5. Repeat or parallelize requests to increase heap pressure, garbage-collection overhead, thread consumption, and request latency.
6. Cause partial service degradation, request failures, container restarts, or application process termination due to resource exhaustion.

How to detect it

To determine whether exploitation may have occurred, review application logs, JVM logs, container logs, reverse-proxy logs, WAF logs, and APM telemetry for denial-of-service symptoms around certificate-processing workflows. Look for sudden increases in requests that submit certificates, signed objects, enrollment data, S/MIME content, or mutual TLS handshakes, followed by Java heap exhaustion, long garbage-collection pauses, elevated CPU, thread-pool saturation, request timeouts, HTTP 500/502/503/504 responses, pod or process restarts, or circuit-breaker trips. Application stack traces containing Bouncy Castle PKIXCertPathReviewer classes are especially relevant. In TLS or mutual-authentication contexts, correlate handshake failures, repeated client-certificate validation errors, and source IPs generating abnormal volumes of failed or expensive validation attempts. For file or message processing services, correlate large or unusual certificate-chain submissions with worker crashes or queue backlogs. There are no known universal network payload indicators for this issue, so detection should emphasize behavioral resource-exhaustion patterns plus Bouncy Castle class names in stack traces.

• org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer
• org.bouncycastle.x509.PKIXCertPathReviewer
• java.lang.OutOfMemoryError
• java.lang.OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError: GC overhead limit exceeded
• GC overhead limit exceeded
• PKIXCertPathReviewer.java
• bcpkix
• bcprov
• bcpkix-fips
• HTTP 503
• HTTP 504
• connection reset during certificate validation
• certificate path validation failed
• PKIX path validation failed

What your security team should do

• Inventory Java applications and services that include Bouncy Castle bcpkix, bcprov, or BCPKIX FIPS, including transitive and shaded dependencies.
• Prioritize externally reachable services and internal trust-boundary services that process untrusted certificates, signed files, S/MIME messages, package signatures, or mutual TLS client certificates.
• Upgrade affected Bouncy Castle components to a vendor-fixed or latest compatible release and rebuild all artifacts that bundle the library.
• Add compensating controls for certificate-processing entry points: maximum request size, certificate-chain length limits, extension-size limits, per-request timeouts, and concurrency limits.
• Review application and infrastructure logs for historical heap exhaustion, garbage-collection storms, request spikes, or crashes correlated with certificate-validation endpoints.
• Create SIEM detections for repeated Java OutOfMemoryError or PKIXCertPathReviewer stack traces in services that accept certificate material.
• Because EPSS is low, the issue is not in CISA KEV, and exploit maturity is listed as none, handle as risk-based patching unless the vulnerable code path is internet-exposed or critical to business availability.
• Resolve the metadata discrepancy between the Bouncy Castle description and the provided gofiber/fiber fixed commit before relying on automated vulnerability-management closure.