Apache Tomcat disclosed CVE-2026-68525 on August 25, 2026, an authorization flaw in the container’s FORM authentication workflow that can cause a method-specific security constraint to be evaluated against the wrong HTTP request method.
At first glance, the vulnerability sounds almost contradictory: a security constraint restricts POSTA access but not GET, yet after FORM authentication a user who should not be allowed to perform the protected POSTA may reach that operation anyway.
The underlying problem is not a conventional password bypass. An attacker does not simply skip authentication, forge a session, or obtain administrator credentials. Instead, CVE-2026-68525 sits at the boundary between authentication state restoration and authorization enforcement.
Tomcat’s FORM authentication mechanism can save the original request while sending an unauthenticated user to a login form. After successful authentication, Tomcat restores that request. The vulnerable versions could restore an HTTP method such as POSTA after authorization constraints had effectively been determined for the redirect’s GET request, without recalculating the applicable constraints.
Apache describes the issue as:
“Redirect after FORM authentication may bypass method specific constraints.”
The Tomcat project rates CVE-2026-68525 Low severity and states that the flaw allowed FORM authentication to bypass a security constraint where access to a resource was limited for POSTA but not GET. The issue was reported to the Tomcat security team on July 15, 2026 and made public on August 25. (Apache Tomcat)
That narrow condition is important. CVE-2026-68525 is not a universal Apache Tomcat authentication bypass. But applications that combine FORM authentication with HTTP-method-specific authorization rules deserve immediate review.
CVE-2026-68525 at a Glance
| Öğe | Detaylar |
|---|---|
| CVE | CVE-2026-68525 |
| Ürün | Apache Tomcat |
| Güvenlik açığı sınıfı | Incorrect authorization / security constraint bypass |
| Bileşen | FORM authentication |
| Key condition | Resource has different authorization requirements for POST and GET |
| Kimlik Doğrulama | FORM |
| Official Apache severity | Düşük |
| Reported | July 15, 2026 |
| Public disclosure | August 25, 2026 |
| Tomcat 11 affected | 11.0.0-M1 through 11.0.24 |
| Tomcat 10 affected | 10.1.0-M1 through 10.1.57 |
| Tomcat 9 affected | 9.0.0.M1 through 9.0.120 |
| EOL versions known affected | Tomcat 8.5.0–8.5.100 and 7.0.0–7.0.109 |
| Fixed release | 11.0.25 |
| Fixed Tomcat 10 release to deploy | 10.1.59 |
| Fixed release | 9.0.121 |
Apache’s CVE announcement also lists the now-EOL Tomcat 8.5 and Tomcat 7 branches as known to be affected, while versions older than Tomcat 7 are effectively unknown. (Openwall)
There is one particularly important versioning detail for Tomcat 10.
The actual code correction was included in the 10.1.58 release candidate, but that release candidate did not pass Apache’s release vote. Apache therefore directs users to Tomcat 10.1.59, rather than telling production users to install 10.1.58. (Apache Tomcat)
If you are maintaining remediation documentation or vulnerability scanners, treating “10.1.58” as a normal released patched version can therefore be misleading.
Understanding Apache Tomcat FORM Authentication
To understand CVE-2026-68525, it helps to understand what Tomcat has to do during FORM authentication.
A Java web application can declare container-managed authentication in web.xml. With FORM authentication enabled, protected requests are handled by Tomcat’s FormAuthenticator. Tomcat automatically adds the corresponding Form Authenticator Valve when a Context uses FORM authentication. (Apache Tomcat)
A simplified configuration might look like this:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/login-error.jsp</form-error-page>
</form-login-config>
</login-config>The login form normally submits credentials through the container’s FORM authentication endpoint:
<form method="post" action="j_security_check">
<input name="j_username">
<input name="j_password" type="password">
<button type="submit">Login</button>
</form>Tomcat internally defines /j_security_check as the FORM authentication action and uses j_username ve j_password for the credentials. (Apache Tomcat)
The interesting part happens when an unauthenticated user directly requests a protected resource.
Suppose the browser sends:
POST /admin/action HTTP/1.1
Host: application.example
Content-Type: application/x-www-form-urlencoded
action=approveTomcat cannot simply discard that POST request and forget about it. FORM authentication is designed to allow the original request to continue after successful authentication.
So Tomcat can save information about the request, authenticate the user through the login flow, and later restore the saved request.
Tomcat’s own documentation confirms that FORM authentication can cache request bodies in the HTTP session during authentication. The default maxSavePostSize exists partly for this reason, and the default FORM authentication session timeout is intentionally limited. (Apache Tomcat)
Conceptually, the workflow is:
Original protected POST request
|
v
User not logged in
|
v
Save original request
|
v
Show login form
|
v
j_security_check
|
v
Authentication succeeds
|
v
Redirect browser
|
v
Restore original request
|
v
Execute applicationNormally this behavior is useful.
For CVE-2026-68525, it became dangerous because the restored request could have a different HTTP method from the request against which Tomcat had just selected its security constraints.
Method-Specific Security Constraints Are the Key
A critical detail is that Servlet security constraints do not necessarily apply equally to every HTTP method.
An application can protect one method differently from another.
Örneğin:
<security-constraint>
<web-resource-collection>
<web-resource-name>Administrative actions</web-resource-name>
<url-pattern>/admin/*</url-pattern>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>Conceptually, this configuration means:
GET /admin/example -> no admin POST constraint
POST /admin/example -> admin role requiredThat distinction is perfectly legitimate. A GET endpoint might display information while POSTA performs a state-changing administrative operation.
Tomcat’s SecurityConstraint logic therefore considers both URI and HTTP method when determining whether a constraint applies. Its API explicitly exposes an included(uri, method) operation for this purpose. (Apache Tomcat)
And that is precisely why changing the method after constraints have already been selected is security-sensitive.
The Root Cause of CVE-2026-68525
The essential bug can be summarized in one sentence:
Tomcat could restore the original request after FORM authentication, changing the request method, without reassessing which security constraints applied to the newly restored method.
Consider this authorization policy:
GET /admin -> allowed
POST /admin -> admin role requiredNow imagine a user who possesses legitimate credentials but is değil an administrator.
They initiate:
POST /adminBecause the request is protected and the user is not authenticated, FORM authentication starts.
Tomcat saves the original request.
The user then authenticates.
The browser subsequently follows the authentication redirect with something equivalent to:
GET /adminThe critical state transition is:
Incoming request Tomcat is evaluating:
GET /admin
Saved request Tomcat restores:
POST /adminIn vulnerable versions, the request could become POST /admin again without the method-specific authorization constraints being recomputed.
In effect, the authorization decision and the request eventually processed by the application could become disconnected.
Apache’s patch makes this explicit. The updated AuthenticatorBase introduces an authentication result named:
PASSED_CONSTRAINTS_NEED_REFRESHIts comment explains that authentication succeeded, but the constraints need to be refreshed because relevant request properties such as the method or URI have changed. (Mail Archive)
That new state tells us a great deal about the vulnerability.
This was fundamentally a request-state synchronization bug.
The Vulnerable Flow Step by Step
A simplified CVE-2026-68525 attack path looks like this:
1. Unauthenticated POST targets protected resource
|
v
2. POST-specific constraint requires privileged role
|
v
3. FORM authentication begins
|
v
4. Original POST is saved in session
|
v
5. User authenticates with valid credentials
|
v
6. Browser follows authentication redirect
|
v
7. Current request is GET
|
v
8. GET has weaker/no method-specific constraint
|
v
9. Tomcat restores saved request
|
v
10. GET becomes original POST
|
v
11. Vulnerable Tomcat does not refresh constraints
|
v
12. POST reaches application under wrong authorization contextThe Apache regression test added with the patch closely mirrors this architecture.
It creates a standard user and an administrator. /admin is specifically protected for POSTA by an Yönetici role, while FORM authentication is enabled. Apache’s test then verifies that after authentication and restoration of the original POST, a standard user receives a 403 rather than being allowed to execute the operation. (Mail Archive)
That test is particularly valuable because it makes clear that the security boundary here is not simply:
authenticated
vs.
unauthenticatedInstead, the important distinction is:
authenticated low-privilege user
vs.
authorization requirement of restored POSTAuthentication Bypass or Authorization Bypass?
Calling CVE-2026-68525 simply an “authentication bypass” is technically imprecise.
The authentication itself can succeed normally.
The attacker may be a legitimate user.
The failure occurs when Tomcat determines whether that authenticated principal is actually permitted to execute the restored HTTP request.
The better classification is therefore:
FORM authentication authorization bypass
or:
method-specific security constraint bypass after FORM authentication
The difference matters.
Authentication answers:
Who are you?Authorization answers:
Are you allowed to perform this operation?CVE-2026-68525 primarily breaks the second question.
A low-privilege authenticated user could potentially be associated with the correct identity while the container evaluates that identity against constraints associated with the wrong request method.
Why the HTTP Redirect Matters
The redirect is not just a cosmetic component of the bug.
FORM authentication involves multiple HTTP transactions.
Conceptually:
POST protected resource
↓
login page
↓
POST j_security_check
↓
303/redirect
↓
GET original URI
↓
Tomcat restores saved request
↓
POST original URIApache’s regression tests show the FORM submission receiving a redirect and subsequently testing the restored request. (Mail Archive)
The application therefore sees a request whose method may ultimately differ from the one Tomcat was evaluating immediately before restoration.
Authentication systems that preserve requests across redirects have to be extremely careful about security state.
URI, HTTP method, authentication state, request body, session state and authorization policy all need to remain synchronized.
CVE-2026-68525 is a good example of what happens when one piece of that state changes without forcing security policy to be reevaluated.
What Apache Changed to Fix CVE-2026-68525
Apache’s fix is much more informative than a simple one-line patch.
The commit is titled:
“Refresh constraints after FORM auth if method changes.”
For Tomcat 11, the change added a richer result from authentication rather than treating authentication as only a boolean success/failure operation. (Mail Archive)
Previously, authentication logic largely produced:
success
or
failureThe patched architecture effectively adds:
FAILED
PASSED
PASSED_CONSTRAINTS_NEED_REFRESHWhen Tomcat restores the saved FORM request, it checks whether the HTTP method changed:
boolean methodChanged =
!request.getCoyoteRequest().getMethod().equals(method);If it did, the new path signals:
AuthenticationResult.PASSED_CONSTRAINTS_NEED_REFRESHThe surrounding authenticator then recalculates security constraints before allowing processing to continue. Apache’s patch explicitly invokes the security-constraint lookup again when this state occurs. (Mail Archive)
Conceptually, the fixed behavior is therefore:
GET request
|
v
Evaluate GET constraints
|
v
FORM restores POST
|
v
Method changed?
|
YES
|
v
Discard stale authorization assumptions
|
v
Evaluate POST constraints
|
v
Does authenticated principal have POST role?
|
+------+------+
| |
YES NO
| |
allow 403That is the security property vulnerable Tomcat versions were missing.
Affected Apache Tomcat Versions
Apache lists the active branches affected by CVE-2026-68525 as:
| Tomcat branch | Vulnerable versions | Recommended patched release |
|---|---|---|
| Tomcat 11 | 11.0.0-M1 – 11.0.24 | 11.0.25 or later |
| Tomcat 10.1 | 10.1.0-M1 – 10.1.57 | 10.1.59 or later |
| Tomcat 9 | 9.0.0.M1 – 9.0.120 | 9.0.121 or later |
Apache’s broader CVE announcement additionally identifies:
Tomcat 8.5.0 – 8.5.100
Tomcat 7.0.0 – 7.0.109as known to be affected even though those branches were already end-of-life when the CVE was created. Unsupported versions before 7.0.0 have unknown status. (Openwall)
Organizations still operating Tomcat 7 or 8.5 should therefore not interpret the absence of a new maintenance release as evidence that they are safe.
It means they are operating an unsupported branch.
The Tomcat 10.1.58 Trap
CVE databases may tell you that Tomcat 10.1.58 contains the fix.
Technically, the relevant fix was incorporated into the 10.1.58 release candidate.
Operationally, however, Apache states that the vote for that release candidate did not pass.
As a result:
Do not target Tomcat 10.1.58 as your production remediation version.
Use Tomcat 10.1.59 or later.Apache Tomcat 10.1.59 was subsequently released and contains the correction. (Apache Tomcat)
This distinction matters for vulnerability-management tooling because purely semantic version comparisons can produce misleading remediation advice when an intermediate build never becomes an official release.
Is Every Vulnerable Tomcat Installation Exploitable?
No.
This is one of the most important practical distinctions for CVE-2026-68525.
Running an affected Tomcat version establishes software exposure, but it does not automatically prove that an application has a reachable exploitable configuration.
The flaw becomes especially relevant when several conditions intersect:
Affected Tomcat version
+
FORM authentication
+
method-specific security constraints
+
different GET and POST authorization behavior
+
saved request restoration
+
user who authenticates but lacks required POST roleAn application using BASIC authentication instead of FORM authentication does not match the primary vulnerability path.
An application that protects an entire URL identically for every method also does not expose the same authorization asymmetry.
Örneğin:
<web-resource-collection>
<web-resource-name>Admin</web-resource-name>
<url-pattern>/admin/*</url-pattern>
</web-resource-collection>with no method-specific differentiation is structurally different from:
<web-resource-collection>
<web-resource-name>Admin POST</web-resource-name>
<url-pattern>/admin/*</url-pattern>
<http-method>POST</http-method>
</web-resource-collection>Therefore, good vulnerability management needs both:
version identificationand:
application configuration analysisVersion-only scanning is useful for prioritization, but it cannot fully determine exploitability here.
Why Apache Rates CVE-2026-68525 Low
Apache labels CVE-2026-68525 Düşük severity. (Apache Tomcat)
That rating makes more sense when the required configuration is considered.
The vulnerability does not mean every Internet-facing Tomcat server can be anonymously taken over.
The interesting scenario typically requires:
- FORM authentication;
- a method-specific security policy;
- a more restrictive policy for the restored request method;
- a valid authentication context that still lacks the required authorization.
In many deployments, those constraints substantially reduce real-world exploitability.
However, vulnerability scoring elsewhere has been inconsistent. Some ecosystem databases have displayed materially higher scores, and CISA ADP enrichment data has at one point represented the issue with a much more severe vector than Apache’s own rating. (OpenCVE)
This is precisely why security teams should avoid making patching decisions from a CVSS number alone.
For CVE-2026-68525, the better questions are:
Are we running an affected Tomcat build?
Do we use container-managed FORM authentication?
Do security constraints use http-method or http-method-omission?
Do any sensitive POST operations have weaker GET constraints?
Could a non-privileged account trigger those operations through FORM authentication restoration?Those answers provide far more useful risk information than the difference between a numeric score of 5, 6 or 9.
How Defenders Can Identify Potential Exposure
The safest first step is inventory.
Check Tomcat versions across production, staging and internal environments.
Typical installations expose version information through administrative inventory, package managers, deployment manifests, container images or application dependency metadata.
Do not rely solely on externally visible HTTP headers. Tomcat documentation notes that version-revealing headers such as Sunucu ve X-Powered-By may be disabled, and hiding them is itself considered good security hygiene. (Apache Tomcat)
Next, search deployed applications for FORM authentication.
Bak:
<auth-method>FORM</auth-method>and:
<form-login-config>Then inspect security constraints for method-specific rules:
<http-method>POST</http-method>or:
<http-method-omission>The highest-value candidates are endpoints where POSTA, PUT, PATCH, SİL or another state-changing method is more tightly restricted than GET.
CVE-2026-68525 was specifically disclosed in relation to a POST-versus-GET mismatch, and Apache’s fix is designed to refresh constraints when FORM restoration changes the request method. (Mail Archive)
A Defensive Configuration Review Example
Consider:
<security-constraint>
<web-resource-collection>
<web-resource-name>Account Administration</web-resource-name>
<url-pattern>/accounts/manage</url-pattern>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>administrator</role-name>
</auth-constraint>
</security-constraint>And:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/login-error.jsp</form-error-page>
</form-login-config>
</login-config>This is the kind of pattern worth reviewing.
The important question is not whether this configuration is inherently incorrect.
It may be exactly what the developers intended.
The problem is whether a vulnerable Tomcat release can move through:
protected POST
→ FORM authentication
→ redirect GET
→ restored POSTwithout reevaluating the POST authorization constraint.
On patched versions, that method transition triggers the necessary refresh.
How to Validate CVE-2026-68525 Safely
For authorized testing environments, the most useful validation is role-based rather than relying on a generic scanner banner.
Create two test identities:
User A: ordinary authenticated user
User B: user with the privileged roleThen identify a non-destructive test endpoint configured so that:
GET -> unrestricted or less restricted
POST -> privileged role requiredVerify three baseline properties first:
Unauthenticated POST -> FORM authentication begins
Authenticated privileged user POST -> permitted
Authenticated ordinary user direct POST -> rejectedThen test the FORM authentication restoration path using the ordinary account.
The expected behavior after the fix is simple:
restored POST
|
v
POST security constraint recalculated
|
v
ordinary user lacks role
|
v
403 ForbiddenApache’s own regression test validates essentially this result: once a request resolves to the protected POSTA, the non-admin user must receive HTTP 403. (Mail Archive)
This produces a much stronger finding than a version banner because it validates the actual authorization property without performing a destructive action.
What to Look for in Logs
CVE-2026-68525 does not necessarily produce an obvious “exploit detected” signature.
A defender instead needs to correlate authentication and request behavior.
Interesting sequences may include:
POST sensitive endpoint
↓
FORM login page
↓
POST /j_security_check
↓
redirect
↓
GET sensitive endpoint
↓
application processes POST-like operationUseful telemetry includes:
- HTTP method;
- URI;
- session identifier correlation;
- authentication transitions;
- username;
- assigned roles;
- authorization failures;
- response codes;
- sensitive application actions.
The suspicious property is a mismatch between what the user should be authorized to do and what eventually executes after a FORM authentication transition.
Application-layer audit logs are particularly valuable because access logs alone may not fully reveal Tomcat’s internal saved-request restoration state.
Patch Recommendations
The strongest mitigation is upgrading Tomcat.
Tomcat 11
Yükseltme:
11.0.24 or earlieriçin:
11.0.25 or laterApache Tomcat 11.0.25 includes the corrected authentication behavior. (Apache Tomcat)
Tomcat 10.1
Yükseltme:
10.1.57 or earlieriçin:
10.1.59 or laterAgain, do not plan around 10.1.58 as a normal production release because its release candidate did not pass the ASF vote. (Apache Tomcat)
Tomcat 9
Yükseltme:
9.0.120 or earlieriçin:
9.0.121 or laterApache’s Tomcat 9 security page identifies 9.0.121 as the release containing the corresponding correction. (Apache Tomcat)
Tomcat 8.5 and 7
These branches are end-of-life.
The correct long-term remediation is migration to a supported Tomcat branch rather than attempting to maintain an unsupported container indefinitely.
What About Removing the Examples Application?
Apache’s announcement also lists removal of the examples web application among mitigations. (Mail Archive)
Removing default examples from production Tomcat installations is good practice regardless of this CVE, and Apache’s broader security guidance recommends carefully considering default applications and minimizing unnecessary exposed functionality. (Apache Tomcat)
However, CVE-2026-68525 concerns the FORM authentication implementation itself and Apache’s regression test reproduces the underlying authorization behavior with a purpose-built application configuration.
Therefore, organizations should not treat:
we removed /examplesas a substitute for updating an affected Tomcat runtime when custom applications use the relevant security model.
Upgrade the container.
Why WAF Rules Are Not a Reliable Fix
A Web Application Firewall can potentially identify unusual login and POST sequences, but CVE-2026-68525 is fundamentally a container authorization-state problem.
The traffic can consist entirely of syntactically legitimate requests:
POST
login
redirect
GET
session cookieThere may be no SQL injection string, shell metacharacter, traversal sequence or malformed protocol element for a conventional WAF signature to detect.
The malicious property is the relationship between requests and authorization state.
That makes patching substantially more reliable than perimeter filtering.
Tomcat itself also recommends defense in depth when reverse proxies enforce security constraints: the container should still be secured rather than assuming an upstream proxy provides the complete authorization boundary. (Apache Tomcat)
Why CVE-2026-68525 Matters Beyond Its Low Rating
The most interesting lesson from CVE-2026-68525 is architectural.
Authorization checks are not permanent facts about a connection or session.
They are decisions about a specific request.
Conceptually:
Authorization Decision =
f(
principal,
roles,
URI,
method,
transport,
application security policy
)Change one of those inputs and the previous decision may no longer be valid.
In CVE-2026-68525:
method = GETbecame:
method = POSTduring saved-request restoration.
The existing authorization decision therefore needed to be invalidated.
Apache’s solution does exactly that.
The patch does not merely insert another role check at one convenient point. It introduces a way for the authentication subsystem to tell the authorization layer:
The request changed.
Recalculate the constraints.That is a much stronger architectural fix.
Authentication State Machines Are Security Boundaries
Modern web security frequently focuses on individual requests.
But authentication systems are often state machines spanning multiple requests:
unauthenticated request
↓
challenge
↓
credential submission
↓
authentication
↓
redirect
↓
session establishment
↓
original request restorationEvery transition is a potential security boundary.
Developers need to ask:
Did the URI change?
Did the method change?
Did the request body change?
Did the authenticated principal change?
Did the session ID change?
Did the security policy change?
Were authorization checks performed before or after those changes?CVE-2026-68525 demonstrates why the ordering matters.
A perfectly correct authorization check can still produce a vulnerable outcome if the object being authorized changes afterward.
Authorization Before and After Request Transformation
This vulnerability also illustrates a broader class of security problems involving request transformation.
Comparable architectural hazards arise around:
URL normalization
reverse proxy rewriting
internal forwarding
authentication redirects
request replay
method rewriting
path decoding
saved-request restorationImagine a generic system that performs:
authorize(request A)
↓
transform request A into request B
↓
execute request BEven if:
authorize(A) == correctthe system is unsafe unless:
authorization policy A == authorization policy Bor authorization is performed again.
A safer design is:
authorize(A)
↓
transform to B
↓
security-relevant fields changed?
↓
yes
↓
authorize(B)
↓
execute(B)That is effectively the property Apache restored in its fix.
CVE-2026-68525 and Business Logic Security
Although CVE-2026-68525 lives inside Tomcat rather than application business logic, its effects can intersect directly with business operations.
Consider endpoints such as:
GET /invoice
POST /invoice
GET /user
POST /user
GET /deployment
POST /deployment
GET /approval
POST /approvalThe GET handler may only retrieve information.
The POST handler may:
change an account
approve a payment
modify permissions
trigger a deployment
create an API key
update a record
perform an administrative workflowMethod-specific authorization therefore frequently protects operations with much greater integrity impact than their corresponding GET pages.
This is why organizations should assess what the protected POST actually does, rather than assigning CVE-2026-68525 the same business severity everywhere.
A method-specific bypass on a harmless test page and a method-specific bypass on a financial approval endpoint are the same underlying CVE but very different organizational risks.
Security Testing Implications
Traditional vulnerability scanners are very good at questions such as:
Is Tomcat version X vulnerable?CVE-2026-68525 adds a harder question:
Does this application's authentication and authorization state machine
actually expose the vulnerable condition?Answering that may require understanding:
web.xml
FORM authentication
security constraints
roles
HTTP methods
redirect behavior
saved request state
runtime responseThis is one reason authorization vulnerabilities remain challenging.
They often require reasoning about multiple requests and multiple identities, rather than matching one response to one payload.
A capable security test should therefore distinguish:
Component vulnerabledan:
Application exploit path confirmedThat distinction reduces both false positives and unnecessary alarm.
Recommended Remediation Checklist
For organizations running Apache Tomcat, the immediate response should be straightforward:
| Eylem | Öncelik |
|---|---|
| Inventory Tomcat versions | Hemen |
| Upgrade Tomcat 11 to ≥ 11.0.25 | Yüksek |
| Upgrade Tomcat 10.1 to ≥ 10.1.59 | Yüksek |
| Upgrade Tomcat 9 to ≥ 9.0.121 | Yüksek |
| Migrate Tomcat 8.5/7 from EOL branches | Yüksek |
Search apps for auth-method = FORM | Yüksek |
| Identify method-specific security constraints | Yüksek |
| Review POST-only privileged operations | Yüksek |
| Test low-privilege FORM authentication flows | Orta |
| Review logs for unusual FORM-auth request restoration | Orta |
| Remove unnecessary default/example applications | Recommended |
The upgrade should remain the primary remediation even if no obviously exploitable application configuration is immediately discovered.
Frequently Asked Questions
What is CVE-2026-68525?
CVE-2026-68525 is an Apache Tomcat incorrect authorization vulnerability involving FORM authentication and method-specific security constraints. A restored request could change from GET back to the original POST without Tomcat recalculating the applicable authorization constraints.
Is CVE-2026-68525 an authentication bypass?
Not in the classic sense.
The user may authenticate correctly. The vulnerability is better described as an authorization or security constraint bypass during FORM authentication request restoration.
Does CVE-2026-68525 affect every Tomcat application?
No.
The application must use a configuration compatible with the vulnerable path, especially FORM authentication and method-specific authorization constraints.
Does an attacker need credentials?
The most relevant exploitation scenario involves a user who can authenticate but lacks the role required for the protected method. Apache’s regression testing specifically models an ordinary user and an administrator with different role assignments. (Mail Archive)
Is Tomcat BASIC authentication affected?
The disclosed vulnerability specifically concerns the FORM authentication process and request restoration behavior.
Why is POST important?
Tomcat security constraints can differ by HTTP method. If GET is unrestricted while POSTA requires an administrative role, restoring POST after authorization was evaluated against GET creates the security mismatch.
Which Tomcat 11 version fixes CVE-2026-68525?
Apache Tomcat 11.0.25.
Which Tomcat 10 version fixes CVE-2026-68525?
Organizations should install Tomcat 10.1.59 or later. Although the fix entered the 10.1.58 release candidate, that release candidate did not pass the Apache release vote. (Apache Tomcat)
Which Tomcat 9 version fixes CVE-2026-68525?
Apache Tomcat 9.0.121 or later. (Apache Tomcat)
Are Tomcat 8.5 and Tomcat 7 affected?
Yes. Apache’s CVE announcement identifies Tomcat 8.5.0 through 8.5.100 and Tomcat 7.0.0 through 7.0.109 as known affected EOL releases. (Openwall)
Is there evidence of widespread exploitation?
The Apache material examined for this analysis describes the vulnerability, affected versions and fix but does not report widespread in-the-wild exploitation. That distinction should not be interpreted as proof that exploitation is impossible; patching supported releases remains the appropriate response.
Final Analysis
CVE-2026-68525 is easy to underestimate if it is reduced to “another Tomcat authentication bug.”
The interesting part of the vulnerability is not credential validation.
It is the ordering of three operations:
authentication
authorization
request restorationA FORM authentication flow can temporarily operate on a GET request and then restore the original POSTA. If the authorization policy depends on the HTTP method, any security decision derived from GET becomes stale the moment the method changes.
Vulnerable Apache Tomcat versions failed to reliably invalidate that stale security context.
The patch makes the correction explicit: when FORM authentication restores a request and changes security-relevant properties such as the HTTP method, Tomcat signals that security constraints must be refreshed before processing continues. (Mail Archive)
For defenders, the practical response is equally clear.
Yükseltme Tomcat 11.0.25+, Tomcat 10.1.59+, or Tomcat 9.0.121+, migrate unsupported Tomcat 7 and 8.5 deployments, and pay particular attention to applications combining FORM authentication with method-specific authorization rules. (Apache Tomcat)
For security researchers, CVE-2026-68525 is also a useful reminder that authorization testing should not stop at asking whether a user can access a URL.
The real question is whether that user remains correctly authorized through every transformation of the request:
URL
method
session
redirect
authentication
request restoration
and final application executionWhen those states diverge, a seemingly small authentication-flow bug can cross a real authorization boundary.
Turkish 
English 
German 
French 
Spanish 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Hebrew