CVE-2020-9484: Deserialization RCE via Apache Tomcat Pers...

What CVE-2020-9484 Is

CVE-2020-9484 is a deserialization vulnerability in Apache Tomcat's session persistence layer that can lead to remote code execution (RCE) under a specific — but realistic — set of server-side conditions. The flaw lives in how Tomcat's PersistenceManager, when paired with a FileStore, handles session data written to disk. If an attacker can get a file of their choosing onto the filesystem, and can predict (or guess) the relative path Tomcat would use to locate a serialized session file, they can smuggle a malicious session ID into a request and cause Tomcat to deserialize attacker-controlled data — with code execution as the end result.

Unlike a "one-request, full-compromise" bug, CVE-2020-9484 is a chained vulnerability: it requires the attacker to already have some means of placing content on disk (for example, via a file upload feature elsewhere in the application) and to know the target file's name and path. That compound requirement is why the issue is rated as important rather than critical — but it is not exotic. File upload endpoints are extremely common, and once an attacker has any write-what-where primitive on a Tomcat host, this CVE turns that primitive into full RCE. For software supply chain and AppSec teams, it's a textbook example of how a "minor" file-handling weakness elsewhere in an application can be escalated by a completely unrelated component deep in the servlet container.

Affected Versions and Components

CVE-2020-9484 affects Apache Tomcat's session persistence mechanism specifically when the PersistenceManager is configured to use a FileStore for session storage — a configuration some deployments enable to survive restarts or to share/replicate session state.

According to the Apache Tomcat project's own security advisories, the affected version ranges are:

• Apache Tomcat 10.0.0-M1 through 10.0.0-M4
• Apache Tomcat 9.0.0.M1 through 9.0.34
• Apache Tomcat 8.5.0 through 8.5.54
• Apache Tomcat 7.0.0 through 7.0.104

The Apache Tomcat team fixed the issue in:

• 10.0.0-M5
• 9.0.35
• 8.5.55
• 7.0.105

Exploitation requires all of the following to be true simultaneously:

1. The attacker is able to control both the content and the name of a file on the server (most commonly through an unrelated file-upload feature in the deployed application).
2. The server is configured to use the PersistenceManager with a FileStore.
3. The PersistenceManager is configured with sessionAttributeValueClassNameFilter="null" (i.e., no class-filtering allow/deny list is in place), or with a filter that is not restrictive enough to block the gadget chain used.
4. The attacker knows the relative path from the FileStore's configured directory to the file they control.

If any one of these is absent, the vulnerability cannot be triggered — which is worth emphasizing to engineering teams who might otherwise dismiss it as "not applicable" without checking their actual context.xml / server.xml manager configuration.

CVSS, EPSS, and KEV Context

Apache Tomcat's own advisory and downstream trackers (NVD, Red Hat, Debian) classify this issue as "Important" rather than "Critical," reflecting the multi-step prerequisites above. NVD's CVSS v3 scoring for this CVE lands in the medium range rather than the 9.x territory typical of unauthenticated single-request RCEs — the high attack complexity (AC:H) driven by the need for an existing file-write primitive and path knowledge pulls the score down even though the resulting impact (arbitrary code execution) is severe.

We have not seen CVE-2020-9484 added to CISA's Known Exploited Vulnerabilities (KEV) catalog, and public EPSS scoring for this CVE has generally tracked low relative to headline Tomcat CVEs — consistent with a vulnerability that requires an attacker to already have a foothold or a co-located file-upload bug rather than being directly internet-triggerable. That said, low EPSS and absence from KEV should not be read as "safe to ignore": EPSS models near-term mass-exploitation likelihood, not the severity of a targeted attack against an application that happens to combine session persistence with a file upload feature — a combination that is common in enterprise Java applications, CMS platforms, and internal admin tools built on Tomcat/Spring Boot embedded containers.

Timeline

• Disclosure and fix: The Apache Tomcat Security Team addressed CVE-2020-9484 as part of the 7.0.105, 8.5.55, 9.0.35, and 10.0.0-M5 releases, publishing details in the project's standard security advisory format on the Apache Tomcat security page.
• Public advisory propagation: Following the Apache release, downstream distributions and vendors that bundle Tomcat (Linux distros, application servers, container base images) issued their own advisories and backported patches over the following weeks, which is the normal cadence for Tomcat CVEs given how widely it's embedded (directly, via Spring Boot, or via commercial app servers built on it).
• Ongoing relevance: Because Tomcat is frequently vendored or embedded rather than run standalone, CVE-2020-9484 continues to surface in SBOM and dependency scans years after the fix, particularly in legacy internal applications, appliances, and vendor products that pin older Tomcat versions and are infrequently rebuilt.

If you cannot confirm the exact patch date for your specific distribution's Tomcat package, treat "am I on a fixed version" (per the ranges above) as the authoritative check rather than relying on calendar dates alone — vendors backport at different times.

Remediation Steps

1. Upgrade first. Move to Apache Tomcat 7.0.105+, 8.5.55+, 9.0.35+, or 10.0.0-M5+ (or your vendor's equivalent backport). This is the only complete fix.
2. Audit your Manager configuration. Search context.xml, server.xml, and any per-webapp META-INF/context.xml for <Manager className="org.apache.catalina.session.PersistenceManager"> combined with a <Store className="org.apache.catalina.session.FileStore">. If you don't use file-based session persistence, you're not exposed to this specific chain — but confirm rather than assume, since defaults and inherited configs can enable it silently.
3. Set a class-name filter regardless of patch status. Apache added the sessionAttributeValueClassNameFilter attribute as defense in depth. Even on patched versions, configuring an explicit allow-list of classes permitted in session attributes reduces blast radius from this and future deserialization issues.
4. Break the prerequisite chain. Since exploitation depends on an attacker controlling a file's name and content elsewhere in the application, harden file upload handling: enforce strict filename validation, store uploads outside any directory Tomcat might resolve session store paths into, and avoid letting user input influence file paths on disk.
5. Inventory embedded Tomcat. Because Tomcat ships inside Spring Boot fat JARs, commercial products, and appliances, run a dependency/SBOM scan across your fleet rather than only checking standalone Tomcat installs. Version strings in embedded distributions are easy to miss during manual review.
6. Re-check after upgrades. Confirm the fixed version is actually in effect post-deployment (via manifest/version endpoints or SBOM diffing), since embedded or containerized deployments can silently retain a cached, older Tomcat layer.

How Safeguard Helps

CVE-2020-9484 is a good illustration of why point-in-time vulnerability scanning isn't enough: the risk here isn't just "is Tomcat outdated," it's "is Tomcat outdated and configured with file-based session persistence and does the application have a co-located file-write primitive." Safeguard is built for exactly this kind of compound, configuration-dependent risk.

• Continuous SBOM and dependency visibility surfaces every instance of Apache Tomcat across your software supply chain — including versions embedded inside Spring Boot artifacts, vendor appliances, and container base images — not just standalone installs your team remembers to check.
• Vulnerability correlation against real usage flags affected Tomcat versions the moment CVE-2020-9484 (or any newly disclosed Tomcat CVE) enters the feed, mapped to the specific artifacts and services in your environment rather than a generic "you might be affected" alert.
• Policy-driven gating lets you block builds or deployments that pull in vulnerable Tomcat versions before they reach production, and enforce remediation SLAs based on exploitability context rather than CVSS score alone.
• Attestation and provenance tracking give you an auditable record that patched Tomcat versions actually shipped — closing the gap between "we upgraded" and "we can prove it," which matters for SOC 2 and customer security questionnaires.

Deserialization bugs like CVE-2020-9484 rarely announce themselves loudly, but they compound quietly with other weaknesses in your stack. Safeguard's job is to make sure you see that compounding risk before an attacker does.