https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-03T01:10:11.276471+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2020-00626 bdu:2020-00626 2026-10-03T01:10:11.294575+00:00 bdu:2020-00626 https://cve.radiocsirt.org/vuln/certfr-2018-avi-589 certfr-2018-avi-589 — De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquan… 2026-10-03T01:10:11.294627+00:00 certfr-2018-avi-589 https://cve.radiocsirt.org/vuln/cnvd-2018-12672 cnvd-2018-12672 2026-10-03T01:10:11.294683+00:00 cnvd-2018-12672 https://cve.radiocsirt.org/vuln/euvd-2026-185081 EUVD-2026-185081 2026-10-03T01:10:11.294696+00:00 EUVD-2026-185081 https://cve.radiocsirt.org/vuln/fkie_cve-2018-8039 fkie_cve-2018-8039 2026-10-03T01:10:11.294707+00:00

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.

 https://cve.radiocsirt.org/vuln/ghsa-jc7r-v6fg-2gpf GHSA-jc7r-v6fg-2gpf — Apache CXF TLS hostname verification does not work correctly with com.sun.net.ssl.* 2026-10-03T01:10:11.294742+00:00

Affected: Maven: org.apache.cxf:cxf-rt-transports-http, Maven: org.apache.cxf:apache-cxf

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.

 https://cve.radiocsirt.org/vuln/gsd-2018-8039 gsd-2018-8039 2026-10-03T01:10:11.294773+00:00 gsd-2018-8039 https://cve.radiocsirt.org/vuln/rhsa-2018:2276 RHSA-2018:2276 — Red Hat Security Advisory: Red Hat JBoss Enterprise Application Platform 7.1 security update 2026-10-03T01:10:11.294785+00:00

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)

 https://cve.radiocsirt.org/vuln/wid-sec-w-2023-1594 WID-SEC-W-2023-1594 — IBM Tivoli Network Manager: Mehrere Schwachstellen 2026-10-03T01:10:11.294806+00:00

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.