https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 01:10:05 +0000 https://cve.radiocsirt.org/vuln/bdu:2020-00626 bdu:2020-00626 https://cve.radiocsirt.org/vuln/bdu:2020-00626 https://cve.radiocsirt.org/vuln/certfr-2018-avi-589 certfr-2018-avi-589 https://cve.radiocsirt.org/vuln/certfr-2018-avi-589 https://cve.radiocsirt.org/vuln/cnvd-2018-12672 cnvd-2018-12672 https://cve.radiocsirt.org/vuln/cnvd-2018-12672 https://cve.radiocsirt.org/vuln/euvd-2026-185081 EUVD-2026-185081 https://cve.radiocsirt.org/vuln/euvd-2026-185081 https://cve.radiocsirt.org/vuln/fkie_cve-2018-8039 <p>It is possible to configure Apache CXF to use the com.sun.net.ssl implementation via &#39;System.setProperty(&#34;java.protocol.handler.pkgs&#34;, &#34;com.sun.net.ssl.internal.www.protocol&#34;);&#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.</p> <p>It is possible to configure Apache CXF to use the com.sun.net.ssl implementation via &#39;System.setProperty(&#34;java.protocol.handler.pkgs&#34;, &#34;com.sun.net.ssl.internal.www.protocol&#34;);&#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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2018-8039 https://cve.radiocsirt.org/vuln/ghsa-jc7r-v6fg-2gpf <p><strong>Affected:</strong> Maven: org.apache.cxf:cxf-rt-transports-http, Maven: org.apache.cxf:apache-cxf</p> <p>It is possible to configure Apache CXF to use the com.sun.net.ssl implementation via &#39;System.setProperty(&#34;java.protocol.handler.pkgs&#34;, &#34;com.sun.net.ssl.internal.www.protocol&#34;);&#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.</p> <p><strong>Affected:</strong> Maven: org.apache.cxf:cxf-rt-transports-http, Maven: org.apache.cxf:apache-cxf</p> <p>It is possible to configure Apache CXF to use the com.sun.net.ssl implementation via &#39;System.setProperty(&#34;java.protocol.handler.pkgs&#34;, &#34;com.sun.net.ssl.internal.www.protocol&#34;);&#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.</p> https://cve.radiocsirt.org/vuln/ghsa-jc7r-v6fg-2gpf https://cve.radiocsirt.org/vuln/gsd-2018-8039 gsd-2018-8039 https://cve.radiocsirt.org/vuln/gsd-2018-8039 https://cve.radiocsirt.org/vuln/rhsa-2018:2276 <p>apache-cxf: TLS hostname verification does not work correctly with com.sun.net.ssl.* wildfly-core: Path traversal can allow the extraction of .war archives to write arbitrary files (Zip Slip)</p> <p>apache-cxf: TLS hostname verification does not work correctly with com.sun.net.ssl.* wildfly-core: Path traversal can allow the extraction of .war archives to write arbitrary files (Zip Slip)</p> https://cve.radiocsirt.org/vuln/rhsa-2018:2276 https://cve.radiocsirt.org/vuln/wid-sec-w-2023-1594 <p>Ein entfernter, anonymer, authentisierter oder lokaler Angreifer kann mehrere Schwachstellen in IBM Tivoli Network Manager ausnutzen, um beliebigen Code auszuführen, Sicherheitsmaßnahmen zu umgehen, vertrauliche Informationen offenzulegen, einen Denial-of-Service-Zustand herbeizuführen, seine Privilegien auszuweiten, Daten zu manipulieren, nicht spezifizierte Auswirkungen zu verursachen und einen Cross-Site-Scripting-Angriff durchzuführen.</p> <p>Ein entfernter, anonymer, authentisierter oder lokaler Angreifer kann mehrere Schwachstellen in IBM Tivoli Network Manager ausnutzen, um beliebigen Code auszuführen, Sicherheitsmaßnahmen zu umgehen, vertrauliche Informationen offenzulegen, einen Denial-of-Service-Zustand herbeizuführen, seine Privilegien auszuweiten, Daten zu manipulieren, nicht spezifizierte Auswirkungen zu verursachen und einen Cross-Site-Scripting-Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2023-1594