CVE-2026-68525 in Tomcat
Summary
by MITRE • 08/26/2026
Incorrect Authorization vulnerability in Apache Tomcat's FORM authentication process allows the bypassing of a security constraint that limits user has access to a resource POST but not GET.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.24, from 10.1.0-M1 through 10.1.57, from 9.0.0.M1 through 9.0.120.
The following versions were EOL at the time the CVE was created but are known to be affected: 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.25, 10.1.58 or 9.0.121, which fixes the issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in Apache Tomcat represents a critical flaw within its FORM authentication mechanism, specifically concerning how security constraints are evaluated against HTTP methods. In web application architecture, it is common practice to define granular access controls that restrict specific operations based on the HTTP method used by the client. For instance, an administrator might configure a resource such as /api/data to accept only POST requests for data submission while explicitly denying GET requests to prevent unauthorized data retrieval or enumeration attacks. This vulnerability exploits a logical error in Tomcat's request processing pipeline where the container fails to correctly enforce these method-specific restrictions during the authentication phase of FORM-based login flows.
When an unauthenticated user attempts to access a resource protected by such constraints, they are typically redirected to a custom login page defined by the application developer. The core issue arises when this redirect occurs or is processed; Tomcat incorrectly authorizes subsequent requests that should have been blocked due to their HTTP method mismatch. Specifically, if a security constraint dictates that POST is allowed but GET is denied for a given URL pattern, an attacker can bypass this restriction by leveraging the authentication flow's handling of redirects and session establishment. The flaw allows an unauthenticated or improperly authenticated actor to access resources via methods that were explicitly prohibited in the web application deployment descriptor (web.xml) or equivalent configuration files.
From a technical perspective, this is classified as CWE-285: Improper Authorization, which encompasses scenarios where software does not properly enforce privileges for specific actions on protected objects. The operational impact of this vulnerability is significant because it undermines the principle of least privilege and method-specific access control models often employed in RESTful APIs or complex web applications. An attacker can potentially retrieve sensitive data that was intended to be write-only, leading to information disclosure. In contexts where GET requests are assumed to be safe idempotent operations while POST triggers state-changing actions, this bypass could also facilitate unintended side effects if the application logic does not strictly separate read and write responsibilities at the business layer rather than relying solely on transport-level constraints.
This behavior aligns with MITRE ATT&CK technique T1078: Valid Accounts or potentially T1528: Steal Application Access Token, depending on how the session is hijacked or established during the flawed authentication process. The vulnerability effectively allows an attacker to bypass access control mechanisms that are designed to limit user interaction with specific resources based on their role and the nature of the request method. This can lead to unauthorized data exfiltration if GET requests were restricted to prevent scraping, or it could allow manipulation of application state if the security model relied heavily on preventing certain methods from reaching backend logic without proper authentication checks that respect those constraints.
The affected versions span multiple major release lines of Apache Tomcat, including 11.x up through 11.0.24, 10.x up through 10.1.57, and 9.x up through 9.0.120. Additionally, older end-of-life versions such as the 8.5 series up to 8.5.100 and the legacy 7.0 series up to 7.0.109 are also known to be susceptible. This wide range of affected software highlights the persistence of this logic error across different iterations of the codebase, suggesting it may stem from a fundamental aspect of how FORM authentication interacts with the security constraint evaluation engine rather than an isolated regression in a single version.
To mitigate this risk, organizations running Apache Tomcat must upgrade to patched versions immediately. The recommended updates are version 11.0.25 for the latest major release line, version 10.1.58 for the stable long-term support branch, and version 9.0.121 for the previous generation of supported releases. For environments still operating on end-of-life versions like 7.x or 8.5.x, upgrading to a currently supported version is strongly advised as these older branches no longer receive security patches from Apache Software Foundation. If immediate upgrade is not feasible due to compatibility constraints, administrators should implement compensating controls such as placing Tomcat behind a reverse proxy that enforces strict HTTP method filtering before requests reach the application server, although this does not address the root cause within the container itself and serves only as a temporary defensive measure.