Red Hat Security Advisory: tomcat9 security, bug fix, and enhancement update
🔗 CVE IDs covered (13)
📋 Description
CVE-2025-66614 — tomcat: Client certificate verification bypass due to virtual host mapping CVE-2026-24733 — tomcat: security constraint bypass with HTTP/0.9 CVE-2026-24734 — tomcat: Apache Tomcat: Certificate revocation bypass due to improper OCSP response validation CVE-2026-24880 — Apache Tomcat: Apache Tomcat: HTTP Request/Response Smuggling via invalid chunk extension CVE-2026-25854 — Apache Tomcat: Apache Tomcat: Open Redirect vulnerability via LoadBalancerDrainingValve CVE-2026-29129 — Apache Tomcat: Apache Tomcat: Configured cipher preference order not preserved CVE-2026-29145 — Apache Tomcat: Apache Tomcat: Authentication bypass due to CLIENT_CERT soft fail misconfiguration CVE-2026-29146 — Apache Tomcat: Apache Tomcat: Information disclosure via Padding Oracle vulnerability in EncryptInterceptor CVE-2026-32990 — Apache Tomcat: Apache Tomcat: Improper Input Validation vulnerability due to incomplete fix CVE-2026-34483 — Apache Tomcat: Apache Tomcat: Information disclosure due to improper encoding in JsonAccessLogValve CVE-2026-34486 — Apache Tomcat: Apache Tomcat: Missing Encryption of Sensitive Data due to EncryptInterceptor bypass CVE-2026-34487 — Apache Tomcat: Apache Tomcat: Information disclosure via sensitive data in log files CVE-2026-34500 — Apache Tomcat: Apache Tomcat: Authentication bypass via client certificate misconfiguration
🎯 Affected products10
- Red Hat Enterprise Linux AppStream (v. 10)
- tomcat9-1:9.0.117-2.el10_2.noarch as a component of Red Hat Enterprise Linux AppStream (v. 10)
- tomcat9-1:9.0.117-2.el10_2.src as a component of Red Hat Enterprise Linux AppStream (v. 10)
- tomcat9-admin-webapps-1:9.0.117-2.el10_2.noarch as a component of Red Hat Enterprise Linux AppStream (v. 10)
- tomcat9-docs-webapp-1:9.0.117-2.el10_2.noarch as a component of Red Hat Enterprise Linux AppStream (v. 10)
- tomcat9-el-3.0-api-1:9.0.117-2.el10_2.noarch as a component of Red Hat Enterprise Linux AppStream (v. 10)
- tomcat9-jsp-2.3-api-1:9.0.117-2.el10_2.noarch as a component of Red Hat Enterprise Linux AppStream (v. 10)
- tomcat9-lib-1:9.0.117-2.el10_2.noarch as a component of Red Hat Enterprise Linux AppStream (v. 10)
- tomcat9-servlet-4.0-api-1:9.0.117-2.el10_2.noarch as a component of Red Hat Enterprise Linux AppStream (v. 10)
- tomcat9-webapps-1:9.0.117-2.el10_2.noarch as a component of Red Hat Enterprise Linux AppStream (v. 10)
✅ Remediation
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability. Workaround: To mitigate this vulnerability, ensure that security constraints are consistent across similar methods (e.g., if GET is denied, HEAD should likely be denied) or block HTTP/0.9 traffic via a reverse proxy or firewall, if it is not required. Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability. Workaround: To mitigate this vulnerability, disable or remove the LoadBalancerDrainingValve configuration from the server.xml file in your Apache Tomcat installation. This valve is typically configured within a <Host> or <Engine> element. After modifying server.xml, restart the Apache Tomcat service for the changes to take effect. This action may impact load balancing functionality if the valve is actively used for draining connections. Workaround: Configure Apache Tomcat to explicitly allow only strong cipher suites. This ensures that even if the preference order is not strictly honored, only secure ciphers are utilized for TLS connections. Edit the `server.xml` file, typically located at `/etc/tomcat/server.xml` or `/opt/tomcat/conf/server.xml`, and modify the `<Connector>` element to include a `ciphers` attribute listing only approved strong cipher suites. For example: `<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLSv1.2+TLSv1.3" ciphers="TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_GCM_SHA256"/>` Replace the example cipher list with a comprehensive set of strong ciphers appropriate for your environment. This may impact compatibility with older clients that do not support the specified strong cipher suites. A restart of the Apache Tomcat service is required for the changes to take effect. Use the command `systemctl restart tomcat` or `systemctl restart tomcat9` depending on your installed package. Workaround: To mitigate this issue, ensure that CLIENT_CERT authentication is configured to strictly enforce client certificate validation. Review the Apache Tomcat conf/server.xml configuration. For SSLHostConfig or Connector elements, set the clientAuth attribute to required or ensure softFail is enabled if optional client certificate authentication is desired. A restart of the Apache Tomcat service is necessary for these configuration changes to apply. Workaround: This vulnerability can be mitigated by removing the affected jar file from the tomcat installation. It can be achieved by running the following command as root: ~~~ systemctl stop tomcat rm -fv /usr/share/java/tomcat/catalina-tribes.jar systemctl start tomcat ~~~ It's important to notice if the Tomcat instance is configured to run with clustering, this may lead to errors when restarting the tomcat service. Red Hat's distributed Apache Tomcat should not be run with Clustering enabled, so make sure to disable such configuration before proceed with the mitigation if that's the case. Workaround: Disable the cloud membership for clustering feature in Apache Tomcat if it is not actively used. Additionally, ensure that access to Apache Tomcat log files is strictly controlled and limited to authorized personnel only to prevent unauthorized disclosure of sensitive information. If the cloud membership for clustering feature is disabled, a restart of the Apache Tomcat service may be required for the changes to take effect.
🔗 References (6)
- selfhttps://access.redhat.com/errata/RHSA-2026:36790
- externalhttps://access.redhat.com/security/updates/classification/#important
- externalhttps://bugzilla.redhat.com/show_bug.cgi?id=2457020
- externalhttps://bugzilla.redhat.com/show_bug.cgi?id=2457027
- externalhttps://issues.redhat.com/browse/RHEL-185571
- selfhttps://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_36790.json