CVE-2024-34447

What it actually does

This vulnerability affects Bouncy Castle’s Java TLS/JSSE implementation. In vulnerable versions, when endpoint identification is enabled but an SSL socket is created without an explicit hostname, hostname verification may be performed against a DNS-resolved IP address instead of the intended DNS name. If an attacker can poison, spoof, or otherwise influence DNS resolution, they may be able to cause the client to validate the wrong endpoint identity and establish a TLS connection to an attacker-controlled service. The main technical impact is loss of TLS server authentication, which can enable interception of confidential traffic.

Why it matters to the business

Applications that rely on affected Bouncy Castle TLS components may believe they are securely connecting to a trusted service while actually connecting to an attacker-controlled endpoint. This can expose sensitive data in transit, including credentials, tokens, API payloads, and business data exchanged over HTTPS or TLS-backed integrations. The issue is not listed in CISA KEV and has a low EPSS score, so broad active exploitation is not currently indicated, but the impact can be serious for systems operating in hostile networks or relying on DNS paths that can be manipulated.

How an attack unfolds

An attacker first needs a position where they can influence DNS responses or network routing for a Java application using the vulnerable Bouncy Castle JSSE/TLS implementation. The target application must create TLS sockets without passing an explicit hostname, such as through patterns involving HttpsURLConnection, while endpoint identification is enabled. The attacker poisons or spoofs DNS so the intended service name resolves to an attacker-controlled IP address. Because of the flaw, hostname verification may be performed against the resolved IP address rather than the intended hostname, allowing the TLS connection to proceed under conditions where it should fail. Once the connection is established, the attacker can observe or capture confidential data sent by the client, and may potentially relay or manipulate higher-level application traffic depending on the protocol and application behavior.

How to fix it

Upgrade affected Bouncy Castle TLS components to fixed versions. Use BC TLS Java 1.0.19 or later, which is included with BC Java 1.78 and BC Java LTS 2.73.6, or use BC FIPS TLS Java 1.0.19 or later for FIPS deployments. Review dependency trees because Bouncy Castle may be included transitively by frameworks, application servers, security libraries, SDKs, or vendor products. Where immediate upgrade is not possible, mitigate by ensuring TLS connections are created with an explicit expected hostname, avoiding ambiguous socket construction patterns, hardening DNS resolution, and restricting outbound connections to known trusted destinations. Do not rely on DNS controls alone as a permanent fix.

How to confirm the fix worked

Confirm that deployed applications no longer include vulnerable Bouncy Castle TLS artifacts. Validate runtime and build-time dependency versions for bcprov, bctls, bcpkix, bc-fips, and related Bouncy Castle packages, and ensure the TLS component is at BC TLS Java 1.0.19 or later, BC Java 1.78 or later, BC Java LTS 2.73.6 or later, or BC FIPS TLS Java 1.0.19 or later as applicable. Test representative TLS client paths to confirm the intended hostname is explicitly supplied and hostname verification fails when connecting to a certificate or endpoint that does not match the requested DNS name. Software composition analysis, Maven or Gradle dependency reports, container image scans, and runtime classpath inspection should all agree that no vulnerable versions remain.

Typical attack path

1. Identify a Java application using a vulnerable Bouncy Castle BCJSSE or BC FIPS TLS version.
2. Gain the ability to influence DNS resolution or network name resolution for the application.
3. Cause the target service hostname to resolve to an attacker-controlled IP address.
4. Present a TLS endpoint that satisfies the flawed verification path used by the vulnerable library.
5. Allow the client application to establish what it believes is a trusted TLS connection.
6. Capture, relay, or abuse sensitive data transmitted by the client over the misdirected TLS session.

How to detect it

There are no universal exploit artifacts for this issue because exploitation depends on DNS manipulation and application-specific TLS client behavior. To investigate possible prior exploitation, review DNS resolver logs, endpoint DNS cache artifacts, proxy logs, firewall logs, VPC flow logs, NetFlow, and application outbound connection logs for cases where trusted service hostnames resolved to unusual or unauthorized IP addresses. Compare historical DNS answers for sensitive external service names against expected provider IP ranges. Look for TLS connections from Java applications to destinations that do not match normal service ownership, geography, ASN, or certificate patterns. If full packet capture or TLS metadata is available, review SNI, certificate subject alternative names, destination IPs, and timing around suspicious DNS responses. Application logs may show connection attempts, certificate validation anomalies, retries, or unexpected remote addresses, but successful exploitation may leave little evidence if the application did not log resolved addresses or TLS peer details.

What your security team should do

• Inventory Java applications and services that use Bouncy Castle JSSE/TLS, including transitive dependencies and embedded JAR files.
• Prioritize upgrades for applications that transmit credentials, tokens, regulated data, payment data, or sensitive business information over outbound TLS connections.
• Upgrade to BC TLS Java 1.0.19 or later, BC Java 1.78 or later, BC Java LTS 2.73.6 or later, or BC FIPS TLS Java 1.0.19 or later as appropriate.
• Review application code for TLS socket creation without an explicit hostname, especially use of HttpsURLConnection and custom SSLSocketFactory integrations.
• Harden DNS and egress controls for affected applications until upgrades are complete.
• Monitor for unusual DNS answers, unexpected destination IPs for trusted service names, and TLS connections to infrastructure not normally associated with expected endpoints.
• Add dependency checks to CI/CD pipelines so vulnerable Bouncy Castle versions are blocked from reintroduction.