Why does this Tomcat vulnerability mainly affect systems with specific non-default settings?

The exploit chain depends on multiple controls lining up at the same time. File writing in the default servlet, partial PUT support, file-based session storage, and vulnerable deserialization libraries create a path to remote code execution. If one of those prerequisites is missing, the chain usually breaks, which is why most installations are not exposed in practice.

Why the exploit only works when the server is configured a certain way

The vulnerability is not a universal Tomcat flaw, it is an exploit chain that depends on several server behaviours being enabled at once. The attacker needs a writeable path through the default servlet, partial PUT support, file-based session persistence, and a deserialization path that can turn a crafted file into code execution. Remove any one of those conditions and the chain usually fails.

That is why the issue is mainly dangerous on systems that depart from safer defaults. A standard installation often lacks one or more of the prerequisites, so the vulnerable sequence never fully forms. In practice, the risk comes from the interaction of configuration choices, not from Tomcat being equally exposed in every deployment.

Which settings create the exposed attack path?

The core prerequisite is that the web tier can be induced to write attacker-controlled content somewhere Tomcat will later treat as session data or another executable input. Partial PUT support expands the attack surface because it can be used to assemble or modify files in a way the defender may not expect. If sessions are persisted to disk, those files become a bridge from file write to object deserialization.

The final step depends on the application stack as much as the server stack. If the application includes a deserialisation library or object type that can be abused through the stored session data, the attacker can move from manipulating files to executing code. If session storage is in memory, if PUT is disabled, or if the write path is not reachable, the chain breaks before it becomes exploitable.

For practitioners, the important point is that “vulnerable” here means “vulnerable under a specific combination of features.” That combination is why two Tomcat instances at the same version can have very different exposure profiles. One may be effectively safe because the prerequisite settings are absent, while another becomes exploitable because convenience features were turned on for application compatibility.

Why configuration and application choices matter as much as patch level

This kind of issue is a good example of latent exposure. A patch reduces the base risk, but the practical attack surface is also shaped by how the server is deployed, what the application enables, and whether legacy features are still present. Operationally, that means vulnerability assessment should not stop at version matching alone.

When a product has a chained exploit, the defender has to think in terms of dependency mapping. If file writing, session persistence, and deserialization are all present, the environment is closer to an exploitable state than a simple “patched or unpatched” label suggests. That is also why hardening choices such as disabling unnecessary write paths and avoiding disk-backed session storage can materially reduce exposure even before code changes are made.

Risk and Threat Considerations

Systems with these settings exposed are at higher risk because the attacker does not need a single magical bug, only a sequence of ordinary features that line up in the wrong order. The danger is greatest when legacy compatibility settings are left on, because they can quietly preserve an attack path that defenders assume is absent.

Failure mechanism: A write-capable servlet path, partial upload support, disk-backed sessions, and unsafe deserialization combine into a multi-step remote code execution chain. If any prerequisite is removed, the path usually collapses.

Impact: Where the chain succeeds, an attacker can move from web access to code execution on the Tomcat host, turning a configuration weakness into full server compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-16 — Application Software Security	Tomcat exploit chains depend on insecure app-server features and code paths.
Recommendation — Disable unnecessary write paths and legacy features that expand the attack surface.
NIST SP 800-53 Rev 5	CM-6 — Configuration Settings	The issue is driven by non-default server settings that create exploitability.
Recommendation — Harden Tomcat by enforcing approved secure configuration baselines.
ISO/IEC 27001:2022	A.8.9 — Configuration management	Non-default settings determine whether the vulnerable chain can form.
Recommendation — Review and control server configurations that enable risky legacy behaviors.
OWASP ASVS	V13 — Configuration	The vulnerability depends on insecure server configuration choices.
Recommendation — Verify the deployment disables file write and deserialization-prone features.

Practitioner Guidance

What to verify: Confirm whether the default servlet can write, whether partial PUT is enabled, whether sessions are stored on disk, and whether any deserialization-capable library or object path is reachable from those files. Treat the combination as the real exposure test, not any single setting in isolation.

Decision rule: If the service does not require file writes, PUT handling, or file-based session persistence, disable them rather than accepting the extra attack surface. If one of those features is required, isolate it and document the compensating control so it is not re-enabled casually later.

Practitioner takeaway: The practical lesson is to assess Tomcat by deployed behaviour, not by product name or version alone, because chained exploits usually depend on a narrow set of opt-in features that are easy to overlook.