Homepage

Uncaught Exception Affecting eap7-ironjacamar-validator package, versions <0:1.4.10-1.Final_redhat_1.1.ep7.el7

Severity

 Recommended
high

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
1.1% (85th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about Uncaught Exception vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-RHEL7-EAP7IRONJACAMARVALIDATOR-5300165
  • published26 Mar 2023
  • disclosed29 Jun 2018
Report a new vulnerability Found a mistake?

Introduced: 29 Jun 2018

CVE-2018-8039  (opens in a new tab)
CWE-248  (opens in a new tab)

How to fix?

Upgrade RHEL:7 eap7-ironjacamar-validator to version 0:1.4.10-1.Final_redhat_1.1.ep7.el7 or higher.
This issue was patched in RHSA-2018:2424.

NVD Description

Note: Versions mentioned in the description apply only to the upstream eap7-ironjacamar-validator package and not the eap7-ironjacamar-validator package as distributed by RHEL. See How to fix? for RHEL:7 relevant fixed versions and status.

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");&#39;. 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.

References