Skip to content

← Public intelligence

Maven package

org.apache.cxf:cxf-rt-transports-http

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 6.3MavenPublished

    Apache CXF allows unrestricted memory consumption in CXF HTTP clients

    CVE-2024-41172 · GHSA-4mgg-fqfq-64hg

    Affected
    • Maven org.apache.cxf:cxf-rt-transports-http >= 4.0.0, < 4.0.5; >= 3.6.0, < 3.6.4
    Fixed in
    3.6.44.0.5· Vendor fix available
    Issue
    In versions of Apache CXF before 3.6.4 and 4.0.5 (3.5.x and lower versions are not impacted), a CXF HTTP client conduit may prevent HTTPClient instances from being garbage collected and it is possible that memory consumption will continue to increase, eventually causing the application to run out of memory

    Recommended action: Upgrade to 4.0.5 or 3.6.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  2. UnratedMavenPublished

    Inadequate Encryption Strength in Apache CXF

    CVE-2012-5575 · GHSA-7v5v-9v8r-w864

    Affected
    • Maven org.apache.cxf:cxf-rt-transports-http >= 2.5.0, < 2.5.10; >= 2.6.0, < 2.6.7; >= 2.7.0, < 2.7.4
    Fixed in
    2.6.72.7.42.5.10· Vendor fix available
    Issue
    Apache CXF 2.5.x before 2.5.10, 2.6.x before CXF 2.6.7, and 2.7.x before CXF 2.7.4 does not verify that a specified cryptographic algorithm is allowed by the WS-SecurityPolicy AlgorithmSuite definition before decrypting, which allows remote attackers to force CXF to use weaker cryptographic algorithms than intended and makes it easier to decrypt communications, aka "XML Encryption backwards compatibility attack."

    Recommended action: Upgrade to 2.7.4, 2.6.7 or 2.5.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  3. High, CVSS 8.1MavenPublished

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

    CVE-2018-8039 · GHSA-jc7r-v6fg-2gpf

    Affected
    • Maven org.apache.cxf:cxf-rt-transports-http >= 3.2.0, < 3.2.5; < 3.1.16
    Fixed in
    3.1.163.2.5· Vendor fix available
    Issue
    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.

    Recommended action: Upgrade to 3.2.5 or 3.1.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →