CVE-2020-9484: Apache Tomcat session persistence deserialization RCE

Automated analysis

Generated by VULONE's analysis model from the NVD record, CISA KEV and EPSS data on 19 September 2026. Confidence: high.

high priorityCVSS 3.1 is 7.0 HIGH and EPSS is 0.566 at the 99th percentile, but exploitation requires four specific preconditions including attacker-controlled files on the server.

What it is

Apache Tomcat's PersistenceManager with a FileStore can deserialize a session file whose name and contents an attacker controls, leading to remote code execution. The flaw is a CWE-502 untrusted deserialization issue and requires four specific preconditions to be met, so it is not universally exploitable. It matters because Tomcat is widely deployed and the default sessionAttributeValueClassNameFilter is null unless a SecurityManager is used.

Impact

An attacker who meets all preconditions can execute arbitrary code in the Tomcat process, gaining the privileges of that service. This can lead to full compromise of the application and its data.

Attack surface

The attack is triggered by a crafted HTTP request to the Tomcat instance, so it is network-reachable, but it requires the attacker to already control a file on the server and know its relative path from the FileStore storage location. No authentication or user interaction is required by the vector, though the file-control precondition implies some prior foothold.

Exploitation

CVE-2020-9484 is not listed in CISA KEV, but EPSS gives it a 30-day probability of 0.566 (99th percentile), and public proof-of-concept material is referenced. No ransomware groups are documented as using it.

What to do

• Upgrade Tomcat to a fixed release (10.0.0-M5 or later, 9.0.35 or later, 8.5.55 or later, 7.0.104 or later) as the primary action.
• If upgrade is not possible, avoid PersistenceManager with FileStore, or set a strict sessionAttributeValueClassNameFilter that only allows expected classes.
• Run Tomcat under a SecurityManager where feasible, since the default null filter applies only when no SecurityManager is used.
• Restrict filesystem write access for the Tomcat process so attackers cannot plant files in or near the session storage directory.
• Apply vendor patches for downstream products (Debian, Ubuntu, Fedora, openSUSE, Oracle, McAfee) that bundle affected Tomcat versions.

Detection

• Monitor Tomcat logs for deserialization errors or unexpected session file reads tied to crafted requests.
• Audit Tomcat configuration for PersistenceManager with FileStore and a null or lax sessionAttributeValueClassNameFilter.
• Watch for new or modified files in the session storage directory that do not match normal session naming patterns.
• Alert on suspicious child processes or outbound connections spawned by the Tomcat JVM.

This assessment is produced automatically and is not human-reviewed. Verify against the vendor advisory before acting on it.