RHSA-2026:76956HighCVSS 8.2

Red Hat Security Advisory: Red Hat JBoss Web Server 7.0.2 release and security update

Published
October 7, 2026
Last Modified
October 12, 2026

🔗 CVE IDs covered (13)

📋 Description

CVE-2026-34181 — openssl: PKCS#12 Files with PBMAC1 Are Accepted with Short HMAC Keys CVE-2026-45447 — openssl: Heap Use-After-Free in OpenSSL PKCS7_verify() CVE-2026-65182 — tomcat: Apache Tomcat: Security constraint bypass due to improper access control CVE-2026-65183 — tomcat: Apache Tomcat: Local information disclosure via Unix domain socket TOCTOU race condition CVE-2026-65637 — tomcat: Apache Tomcat: Improper Input Validation allows HTTP/2 no-authority bypass of strict SNI validation CVE-2026-65905 — tomcat: Apache Tomcat: Authentication bypass via limited replay attack in DIGEST authenticator CVE-2026-65927 — tomcat: Apache Tomcat: Access control bypass due to off-by-one error in RewriteValve [N] flag processing CVE-2026-66299 — tomcat: Apache Tomcat: Denial of Service via WebSocket chat example CVE-2026-66422 — tomcat: Apache Tomcat: Improper Authorization allows bypass of declarative role constraints CVE-2026-68525 — tomcat: Apache Tomcat: Unauthorized resource access via FORM authentication bypass CVE-2026-68569 — tomcat: Apache Tomcat: Improper Authentication due to principal lookup failure CVE-2026-68763 — tomcat: Apache Tomcat: Denial of Service via HTTP/2 allocation leak CVE-2026-73180 — tomcat: Apache Tomcat: Authenticated WebSocket session persists after HTTP session termination

🎯 Affected products1

  • Red Hat JBoss Web Server 7.0.2

✅ Remediation

Before applying the update, back up your existing Red Hat JBoss Web Server installation, including all applications and configuration files. The References section of this erratum contains a download link for the update. You must be logged in to download the update. Workaround: To mitigate this issue, enforce strict validation on all uploaded PKCS#12 files to reject those containing abnormally short security keys. Additionally, enabling FIPS mode on your system can help protect your environment, as the vulnerable OpenSSL code operates entirely outside the approved FIPS cryptographic boundary. 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 issue, ensure that security constraints in Apache Tomcat's web.xml configuration files are ordered from most specific to least specific. More restrictive constraints for shorter sub-paths must be defined before broader constraints for longer paths. Incorrect ordering can lead to a bypass of intended access controls. After modifying web.xml, a restart or reload of the Apache Tomcat service is required for the changes to take effect, which may temporarily interrupt service availability. Workaround: To mitigate this issue, disable DIGEST authentication in Apache Tomcat if it is not a required authentication mechanism for your deployment. Refer to the Apache Tomcat documentation for guidance on configuring authentication methods. Disabling DIGEST authentication will affect services that depend on it. A restart of the Tomcat service is necessary for the configuration changes to be applied. Workaround: To mitigate this vulnerability, remove the `examples` web application from your Apache Tomcat installation. This can typically be achieved by deleting the `examples` directory or `examples.war` file from the `webapps` directory of your Tomcat installation. A restart of the Tomcat service may be required for the changes to take full effect. Workaround: To mitigate this issue, avoid using CLIENT-CERT or SPNEGO authentication methods with the DataSourceRealm in Apache Tomcat. Alternatively, restrict network access to the Apache Tomcat instance to trusted clients only, thereby limiting exposure to potential attackers. If changes are made to the Tomcat configuration, a service restart may be required for the changes to take effect. Workaround: To mitigate this vulnerability, disable the HTTP/2 protocol in Apache Tomcat if it is not required for your deployment. This can be achieved by commenting out or removing the <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" /> element within the <Connector> configuration in the server.xml file. After modifying server.xml, a restart of the Apache Tomcat service is required for the changes to take effect.

🔗 References (17)