| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Missing Encryption of Sensitive Data vulnerability in Apache Tomcat due to the fix for CVE-2026-29146 allowing the bypass of the EncryptInterceptor.
This issue affects Apache Tomcat: 11.0.20, 10.1.53, 9.0.116.
Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117, which fix the issue. |
| Improper Encoding or Escaping of Output vulnerability in the JsonAccessLogValve component of Apache Tomcat.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.40 through 9.0.116.
Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117 , which fix the issue. |
| Use of GET Request Method With Sensitive Query Strings vulnerability in Apache OpenMeetings.
The REST login endpoint uses HTTP GET method with username and password passed as query parameters. Please check references regarding possible impact
This issue affects Apache OpenMeetings: from 3.1.3 before 9.0.0.
Users are recommended to upgrade to version 9.0.0, which fixes the issue. |
| Integer Overflow or Wraparound vulnerability in Apache ActiveMQ, Apache ActiveMQ All, Apache ActiveMQ MQTT.
The fix for "CVE-2025-66168: MQTT control packet remaining length field is not properly validated" was only applied to 5.19.2 (and future 5.19.x) releases but was missed for all 6.0.0+ versions.
This issue affects Apache ActiveMQ: from 6.0.0 before 6.2.4; Apache ActiveMQ All: from 6.0.0 before 6.2.4; Apache ActiveMQ MQTT: from 6.0.0 before 6.2.4.
Users are recommended to upgrade to version 6.2.4 or a 5.19.x version starting with 5.19.2 or later (currently latest is 5.19.5), which fixes the issue. |
| Use of Hard-coded Cryptographic Key vulnerability in Apache OpenMeetings.
The remember-me cookie encryption key is set to default value in openmeetings.properties and not being auto-rotated. In case OM admin hasn't changed the default encryption key, an attacker who has stolen a cookie from a logged-in user can get full user credentials.
This issue affects Apache OpenMeetings: from 6.1.0 before 9.0.0.
Users are recommended to upgrade to version 9.0.0, which fixes the issue. |
| Improper Handling of Insufficient Privileges vulnerability in Apache OpenMeetings.
Any registered user can query web service with their credentials and get files/sub-folders of any folder by ID (metadata only NOT contents). Metadata includes id, type, name and some other field. Full list of fields get be checked at FileItemDTO object.
This issue affects Apache OpenMeetings: from 3.10 before 9.0.0.
Users are recommended to upgrade to version 9.0.0, which fixes the issue. |
| Improper Input Validation vulnerability in Apache Tomcat due to an incomplete fix of CVE-2025-66614.
This issue affects Apache Tomcat: from 11.0.15 through 11.0.19, from 10.1.50 through 10.1.52, from 9.0.113 through 9.0.115.
Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue. |
| Padding Oracle vulnerability in Apache Tomcat's EncryptInterceptor with default configuration.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.0.0-M1 through 10.1.52, from 9.0.13 through 9..115, from 8.5.38 through 8.5.100, from 7.0.100 through 7.0.109.
Users are recommended to upgrade to version 11.0.19, 10.1.53 and 9.0.116, which fixes the issue. |
| CLIENT_CERT authentication does not fail as expected for some scenarios when soft fail is disabled vulnerability in Apache Tomcat, Apache Tomcat Native.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M7 through 10.1.52, from 9.0.83 through 9.0.115; Apache Tomcat Native: from 1.1.23 through 1.1.34, from 1.2.0 through 1.2.39, from 1.3.0 through 1.3.6, from 2.0.0 through 2.0.13.
Users are recommended to upgrade to version Tomcat Native 1.3.7 or 2.0.14 and Tomcat 11.0.20, 10.1.53 and 9.0.116, which fix the issue. |
| Configured cipher preference order not preserved vulnerability in Apache Tomcat.
This issue affects Apache Tomcat: from 11.0.16 through 11.0.18, from 10.1.51 through 10.1.52, from 9.0.114 through 9.0.115.
Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue. |
| Occasional URL redirection to untrusted Site ('Open Redirect') vulnerability in Apache Tomcat via the LoadBalancerDrainingValve.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M1 through 10.1.52, from 9.0.0.M23 through 9.0.115, from 8.5.30 through 8.5.100.
Other, unsupported versions may also be affected
Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue. |
| Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in Apache Tomcat via invalid chunk extension.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.1.0-M1 through 10.1.52, from 9.0.0.M1 through 9.0.115, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109.
Other, unsupported versions may also be affected.
Users are recommended to upgrade to version 11.0.20, 10.1.52 or 9.0.116, which fix the issue. |
| Insertion of Sensitive Information into Log File vulnerability in the cloud membership for clustering component of Apache Tomcat exposed the Kubernetes bearer token.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.13 through 9.0.116.
Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117, which fix the issue. |
| Apache Log4j Core's Rfc5424Layout https://logging.apache.org/log4j/2.x/manual/layouts.html#RFC5424Layout , in versions 2.21.0 through 2.25.3, is vulnerable to log injection via CRLF sequences due to undocumented renames of security-relevant configuration attributes.
Two distinct issues affect users of stream-based syslog services who configure Rfc5424Layout directly:
* The newLineEscape attribute was silently renamed, causing newline escaping to stop working for users of TCP framing (RFC 6587), exposing them to CRLF injection in log output.
* The useTlsMessageFormat attribute was silently renamed, causing users of TLS framing (RFC 5425) to be silently downgraded to unframed TCP (RFC 6587), without newline escaping.
Users of the SyslogAppender are not affected, as its configuration attributes were not modified.
Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue. |
| The Log4j1XmlLayout from the Apache Log4j 1-to-Log4j 2 bridge fails to escape characters forbidden by the XML 1.0 standard, producing malformed XML output. Conforming XML parsers are required to reject documents containing such characters with a fatal error, which may cause downstream log processing systems to drop or fail to index affected records.
Two groups of users are affected:
* Those using Log4j1XmlLayout directly in a Log4j Core 2 configuration file.
* Those using the Log4j 1 configuration compatibility layer with org.apache.log4j.xml.XMLLayout specified as the layout class.
Users are advised to upgrade to Apache Log4j 1-to-Log4j 2 bridge version 2.25.4, which corrects this issue.
Note: The Apache Log4j 1-to-Log4j 2 bridge is deprecated and will not be present in Log4j 3. Users are encouraged to consult the Log4j 1 to Log4j 2 migration guide https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html , and specifically the section on eliminating reliance on the bridge. |
| Apache Log4j Core's XmlLayout https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout , in versions up to and including 2.25.3, fails to sanitize characters forbidden by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets producing invalid XML output whenever a log message or MDC value contains such characters.
The impact depends on the StAX implementation in use:
* JRE built-in StAX: Forbidden characters are silently written to the output, producing malformed XML. Conforming parsers must reject such documents with a fatal error, which may cause downstream log-processing systems to drop the affected records.
* Alternative StAX implementations (e.g., Woodstox https://github.com/FasterXML/woodstox , a transitive dependency of the Jackson XML Dataformat module): An exception is thrown during the logging call, and the log event is never delivered to its intended appender, only to Log4j's internal status logger.
Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output. |
| Apache Log4j's JsonTemplateLayout https://logging.apache.org/log4j/2.x/manual/json-template-layout.html , in versions up to and including 2.25.3, produces invalid JSON output when log events contain non-finite floating-point values (NaN, Infinity, or -Infinity), which are prohibited by RFC 8259. This may cause downstream log processing systems to reject or fail to index affected records.
An attacker can exploit this issue only if both of the following conditions are met:
* The application uses JsonTemplateLayout.
* The application logs a MapMessage containing an attacker-controlled floating-point value.
Users are advised to upgrade to Apache Log4j JSON Template Layout 2.25.4, which corrects this issue. |
| The fix for CVE-2025-68161 https://logging.apache.org/security.html#CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName system property, but not when configured through the verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName attribute of the <Ssl> element.
Although the verifyHostName configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value.
A network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:
* An SMTP, Socket, or Syslog appender is in use.
* TLS is configured via a nested <Ssl> element.
* The attacker can present a certificate issued by a CA trusted by the appender's configured trust store, or by the default Java trust store if none is configured.
This issue does not affect users of the HTTP appender, which uses a separate verifyHostname https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName attribute that was not subject to this bug and verifies host names by default.
Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue. |
| Apache Log4net's XmlLayout https://logging.apache.org/log4net/manual/configuration/layouts.html#layout-list and XmlLayoutSchemaLog4J https://logging.apache.org/log4net/manual/configuration/layouts.html#layout-list , in versions before 3.3.0, fail to sanitize characters forbidden by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets in MDC property keys and values, as well as the identity field that may carry attacker-influenced data. This causes an exception during serialization and the silent loss of the affected log event.
An attacker who can influence any of these fields can exploit this to suppress individual log records, impairing audit trails and detection of malicious activity.
Users are advised to upgrade to Apache Log4net 3.3.0, which fixes this issue. |
| Apache Log4cxx's XMLLayout https://logging.apache.org/log4cxx/1.7.0/classlog4cxx_1_1xml_1_1XMLLayout.html , in versions before 1.7.0, fails to sanitize characters forbidden by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets in log messages, NDC, and MDC property keys and values, producing invalid XML output. Conforming XML parsers must reject such documents with a fatal error, which may cause downstream log processing systems to drop or fail to index affected records.
An attacker who can influence logged data can exploit this to suppress individual log records, impairing audit trails and detection of malicious activity.
Users are advised to upgrade to Apache Log4cxx 1.7.0, which fixes this issue. |
