NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
☕
☕ Maven
Not in CISA KEV
HIGH severity

CVE-2018-8039 — cxf-rt-transports-http

HIGHFix: apache/cxf@fae6fab

CVE-2018-8039 is a high-severity (CVSS 8.1) CWE-755 vulnerability in org.apache.cxf:cxf-rt-transports-http. A fix is available for org.apache.cxf:cxf-rt-transports-http — see the affected versions and patch details below.

Apache CXF TLS hostname verification does not work correctly with com.sun.net.ssl.*

Also known asGHSA-jc7r-v6fg-2gpf
Published
Updated
Affected
4 pkgs
Patched
4 / 4
Exploits
None indexed
Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
8.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs95th percentile — riskier than 95% of all scored CVEsHighest risk
0.65%4.65%8.65%12.6%2.9%8.5%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

4 pkgs affected
☕org.apache.cxf:cxf-rt-transports-http☕org.apache.cxf:cxf-rt-transports-http☕org.apache.cxf:apache-cxf☕org.apache.cxf:apache-cxf

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

It is possible to configure Apache CXF to use the com.sun.net.ssl implementation via 'System.setProperty("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol");'. When this system property is set, CXF uses some reflection to try to make the HostnameVerifier work with the old com.sun.net.ssl.HostnameVerifier interface. However, the default HostnameVerifier implementation in CXF does not implement the method in this interface, and an exception is thrown. However, in Apache CXF prior to 3.2.5 and 3.1.16 the exception is caught in the reflection code and not properly propagated. What this means is that if you are using the com.sun.net.ssl stack with CXF, an error with TLS hostname verification will not be thrown, leaving a CXF client subject to man-in-the-middle attacks.

Affected Packages

4 total 4 fixed
EcosystemPackageVulnerable rangeFix
☕Mavenorg.apache.cxf:cxf-rt-transports-http≥ 3.2.0&&< 3.2.53.2.5org.apache.cxf:cxf-rt-transports-http:3.2.5
☕Mavenorg.apache.cxf:cxf-rt-transports-httpall versions3.1.16org.apache.cxf:cxf-rt-transports-http:3.1.16
☕Mavenorg.apache.cxf:apache-cxf≥ 3.2.0&&< 3.2.53.2.5org.apache.cxf:apache-cxf:3.2.5
☕Mavenorg.apache.cxf:apache-cxfall versions3.1.16org.apache.cxf:apache-cxf:3.1.16

Affected Products

2 products · 3 configurations
Application
cxfapache
≥ 3.2.0 && < 3.2.5
range
Application
jboss enterprise application platformredhat
1 version
7.1.0

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.apache.cxf:cxf-rt-transports-http, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update org.apache.cxf:cxf-rt-transports-http to 3.2.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2018-8039 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

In OpenShift Logging the openshift-logging/elasticsearch6-rhel8 container bundles the vulnerable version of apache-cxf, but the vulnerable class is not shipped, hence this component is not affected by this vulnerability.

ProductFixed inAdvisory
Red Hat Fuse 7.2cxf-coreRHSA-2018:3768
Red Hat JBoss A-MQ 6.3cxf-coreRHSA-2018:3817
Red Hat JBoss EAP 7.1see advisoryRHSA-2018:2277
Red Hat JBoss EAP 7.1cxf-coreRHSA-2018:2425
Red Hat JBoss Enterprise Application Platform 7.1 for RHEL 6eap7-apache-cxf-0:3.1.16-1.redhat_1.1.ep7.el6RHSA-2018:2276
Red Hat JBoss Enterprise Application Platform 7.1 for RHEL 6eap7-activemq-artemis-0:1.5.5.013-1.redhat_1.1.ep7.el6RHSA-2018:2423
Red Hat JBoss Enterprise Application Platform 7.1 for RHEL 7eap7-activemq-artemis-0:1.5.5.013-1.redhat_1.1.ep7.el7RHSA-2018:2424
Red Hat Single Sign-On 7.2cxf-coreRHSA-2018:2279

Frequently Asked Questions

It is possible to configure Apache CXF to use the com.sun.net.ssl implementation via 'System.setProperty("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol");'. When this system property is set, CXF uses some reflection to try to make the HostnameVerifier work with the old com.sun.net.ssl.HostnameVerifier interface. However, the default HostnameVerifier implementation in CXF does not implement the method in this interface, and an exception is thrown. However, in Apache CXF prior to 3.2.5 and 3.1.16 the exception is caught in the reflection code and not properly propagated. Wh
O3 Security · Impact-Aware SCA

Is CVE-2018-8039 in your dependencies?

Find it across Maven, including transitive dependencies.

Scan my dependencies How O3 SCA works
CVE-2018-8039: cxf-rt-transports-http — Fixed in 3.2.5