Apache Tomcat versions 7.0.0 to 7.0.84, 8.0.0.RC1 to 8.0.49 and 8.5.0 to 8.5.27 only apply security constraints defined by Servlets once those Servlets are loaded. Depending on the order that Servlets load, some security constraints may not be applied leading to unintended resource exposure.

External References:

https://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.85 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.50 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.28

Upstream Fixes:

Tomcat 7.0.x:

http://svn.apache.org/viewvc?view=rev&rev=1823322 http://svn.apache.org/viewvc?view=rev&rev=1824360

Tomcat 8.0.x:

http://svn.apache.org/viewvc?view=rev&rev=1823319 http://svn.apache.org/viewvc?view=rev&rev=1824359

Tomcat 8.5.x:

http://svn.apache.org/viewvc?view=rev&rev=1823314 http://svn.apache.org/viewvc?view=rev&rev=1824358

Apache Tomcat versions 7.0.0 to 7.0.84, 8.0.0.RC1 to 8.0.49 and 8.5.0 to 8.5.27 does not properly handle the URL empty string ("") when used as part of a security constraint definition. This can lead to the security constraint being ignored, leading to unitended exposure of resources.

External References:

https://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.85 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.50 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.28

Upstream Bug Report:

https://bz.apache.org/bugzilla/showbug.cgi?id=62067

Upstream Fixes:

Tomcat 7.0.x:

http://svn.apache.org/viewvc?view=rev&rev=1823309

Tomcat 8.0.x:

http://svn.apache.org/viewvc?view=rev&rev=1814827

Tomcat 8.5.x:

http://svn.apache.org/viewvc?view=rev&rev=1823307

A flaw was found in Apache tomcat. When the default servlet returned a redirect to a directory (e.g. redirecting to /foo/ when the user requested /foo) a specially crafted URL could be used to cause the redirect to be generated to any URI of the attackers choice.

References:

https://lists.apache.org/thread.html/23134c9b5a23892a205dc140cdd8c9c0add233600f76b313dda6bd75@%3Cannounce.tomcat.apache.org%3E

Apache CXF’s OIDC relying-party component could redirect users to an attacker-controlled URL after successful authentication. The issue occurs because attacker-controlled state parameters are preserved and later used as redirect targets without validating that the final decoded URI belongs to the RP’s origin. Both directly encoded and double-encoded external URLs can trigger the issue, depending on which validation path is used. Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue.

The CORS Filter did not add an HTTP Vary header indicating that the response varies depending on Origin. This permitted client and server side cache poisoning in some circumstances.

Affected versions: 7.0.41 to 7.0.78, 8.0.0.RC1 to 8.0.44, 8.5.0 to 8.5.15

Upstream patches:

Tomcat 7: https://svn.apache.org/viewvc?view=revision&revision=1795816 Tomcat 8.0.x: https://svn.apache.org/viewvc?view=revision&revision=1795815 Tomcat 8.5.x: https://svn.apache.org/viewvc?view=revision&revision=1795814

External References:

https://tomcat.apache.org/security-7.html https://tomcat.apache.org/security-8.html

Last updated 18 August 2025

ResourceLinkFactory.setGlobalContext() is a public method and was accessible by web applications running under a security manager without any checks. This allowed a malicious web application to inject a malicious global context that could in turn be used to disrupt other web applications and/or read and write data owned by other web applications.

External references:

http://seclists.org/bugtraq/2016/Feb/147

Apache Tomcat 6.x before 6.0.45, 7.x before 7.0.68, 8.x before 8.0.31, and 9.x before 9.0.0.M2 does not place org.apache.catalina.manager.StatusManagerServlet on the org/apache/catalina/core/RestrictedServlets.properties list, which allows remote authenticated users to bypass intended SecurityManager restrictions and read arbitrary HTTP requests, and consequently discover session ID values, via a crafted web application.

Summary

Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.

Mitigations

To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes.

Warning: To take effect, both the client and server must support this countermeasure.

As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.

Details

The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSHMSGEXTINFO sent after the first message after SSHMSGNEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario.

The attack works by an attacker injecting an arbitrary number of SSHMSGIGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSHMSGIGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange.

In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers.

For more details see https://terrapin-attack.com.

Impact

This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.

The fix for CVE-2025-68161

Impact

Authentication Bypass: A vulnerability exists in Apache Shiro that allows authentication bypass for static files when served from a case-insensitive filesystem (such as the default configuration on macOS or Windows).

The issue arises when Shiro's URL filters are configured with lower-case rules (a common default), but the underlying operating system treats mixed-case filenames as identical. An attacker can access protected static resources by varying the capitalization of the filename in the request (e.g., requesting /SECRET.TXT to bypass a rule for /secret.txt).

This issue specifically affects static file handling and does not impact dynamic resource paths that are case-sensitive.

Patches Users should upgrade to Apache Shiro 2.1.0 or later.

Important Configuration Note: Version 2.1.0 introduces a new configuration parameter to handle case-insensitivity, which must be enabled manually to resolve the issue:

shiro.ini: ini filterChainResolver.caseInsensitive = true Spring Boot (application.properties): properties shiro.caseInsensitive=true

Note: Apache Shiro 3.0.0 (upcoming) will enable this setting by default.

Workarounds Ensure that the filesystem hosting the application is case-sensitive (e.g., Linux/Unix). Manually configure all Shiro filter chains to handle all possible case variations of protected filenames (not recommended due to complexity).

Resources CVE-2026-23903 Mailing List Announcement OSS-Security List

Apache Log4j Core's Rfc5424Layout

Directory traversal vulnerability in RequestUtil.java in Apache Tomcat 6.x before 6.0.45, 7.x before 7.0.65, and 8.x before 8.0.27 allows remote authenticated users to bypass intended SecurityManager restrictions and list a parent directory via a /.. (slash dot dot) in a pathname used by a web application in a getResource, getResourceAsStream, or getResourcePaths call, as demonstrated by the $CATALINABASE/webapps directory.

The Mapper component in Apache Tomcat 6.x before 6.0.45, 7.x before 7.0.68, 8.x before 8.0.30, and 9.x before 9.0.0.M2 processes redirects before considering security constraints and Filters, which allows remote attackers to determine the existence of a directory via a URL that lacks a trailing / (slash) character.

Improper Neutralization of Special Elements Used in a Template Engine vulnerability in Apache OFBiz.

This issue affects Apache OFBiz: before 24.09.06.

Users are recommended to upgrade to version 24.09.06, which fixes the issue.

Please note that in the updated version, "Data Resource" records with dataTemplateTypeId = "FTL" are no longer supported.

Additionally, in the updated version, the "Ecommerce Customer" security group no longer includes content management grants. Users are advised to remove these permissions from any production site as well.

Improper Input Validation vulnerability in Apache OFBiz.

This issue affects Apache OFBiz: before 24.09.06.

Users are recommended to upgrade to version 24.09.06, which fixes the issue.

Improper Access Control vulnerability in Apache OFBiz in multi-tenant deployments.

This issue affects Apache OFBiz: before 24.09.06.

Users are recommended to upgrade to version 24.09.06, which fixes the issue.

Improper Authorization vulnerability in Apache OFBiz Webtools.

This issue affects Apache OFBiz: before 24.09.06.

Users are recommended to upgrade to version 24.09.06, which fixes the issue.

Improper Control of Generation of Code ('Code Injection') vulnerability in email services of Apache OFBiz.

This issue affects Apache OFBiz: before 24.09.06.

Users are recommended to upgrade to version 24.09.06, which fixes the issue.

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache OFBiz.

This issue affects Apache OFBiz: before 24.09.06.

Users are recommended to upgrade to version 24.09.06, which fixes the issue.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), Improper Control of Generation of Code ('Code Injection') vulnerability in Apache OFBiz.

This issue affects Apache OFBiz: before 24.09.06.

Users are recommended to upgrade to version 24.09.06, which fixes the issue.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Apache OFBiz.

This issue affects Apache OFBiz: before 24.09.06.

Users are recommended to upgrade to version 24.09.06, which fixes the issue.

Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') vulnerability in Apache OFBiz.

This issue affects Apache OFBiz: before 24.09.06.

Users are recommended to upgrade to version 24.09.06, which fixes the issue.

Improper Authentication vulnerability in Apache OFBiz.

This issue affects Apache OFBiz: before 24.09.06.

Users are recommended to upgrade to version 24.09.06, which fixes the issue.

A vulnerability exists in Apache Artemis whereby an application using the STOMP protocol with security credentials that grant either the consume or send permission on an address can augment the routing-type supported by that address even if said user doesn't have the createAddress permission for that particular address. A user could successfully send a message to an address or consume a message from a queue with a routing-type not supported by the corresponding address when that operation should actually be rejected on the basis that the user doesn't have permission to change the routing-type of the address. Even though the user was already granted permission to send and/or consume messages, they should not be able to augment the routing-type of the address without the createAddress permission.

This issue affects Apache Artemis: from 2.50.0 through 2.53.0; Apache ActiveMQ Artemis: from 2.0.0 through 2.44.0.

Users are recommended to upgrade to version 2.54.0, which fixes the issue.

It was found that the expression language resolver evaluated expressions within a privileged code section. A malicious web application could use this flaw to bypass security manager protections.

Upstream patches:

http://svn.apache.org/viewvc?view=revision&revision=1644019 http://svn.apache.org/viewvc?view=revision&revision=1645644

External References:

http://tomcat.apache.org/security-6.html#FixedinApacheTomcat6.0.44 http://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.59 http://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.17

java/org/apache/coyote/http11/filters/ChunkedInputFilter.java in Apache Tomcat 6.x before 6.0.42, 7.x before 7.0.55, and 8.x before 8.0.9 does not properly handle attempts to continue reading data after an error has occurred, which allows remote attackers to conduct HTTP request smuggling attacks or cause a denial of service (resource consumption) by streaming data with malformed chunked transfer coding.

Apache Tomcat before 6.0.40, 7.x before 7.0.54, and 8.x before 8.0.6 does not properly constrain the class loader that accesses the XML parser used with an XSLT stylesheet, which allows remote attackers to (1) read arbitrary files via a crafted web application that provides an XML external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) issue, or (2) read files associated with different web applications on a single Tomcat instance via a crafted web application.

Integer overflow in java/org/apache/tomcat/util/buf/Ascii.java in Apache Tomcat before 6.0.40, 7.x before 7.0.53, and 8.x before 8.0.4, when operated behind a reverse proxy, allows remote attackers to conduct HTTP request smuggling attacks via a crafted Content-Length HTTP header.

It was found that the org.apache.catalina.servlets.DefaultServlet implementation in Apache Tomcat allowed the definition of XXEs in provided XSLTs. A malicious application could use this to circumvent security restrictions to disclose sensitive information.