tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: java deserialization vulnerability for Tomcat 7/8
Date Wed, 11 Nov 2015 13:44:15 GMT

On 11/11/15 8:10 AM, Christopher Schultz wrote:
> Satish,
> On 11/11/15 7:58 AM, satish jupalli wrote:
>> Would like to get your opinion on the java deserialization vulnerability
>> issue for Tomcat. As Jboss seems to have been impacted with, is there a way
>> to verify wether this vulnerability affects Tomcat as well?
> Are you talking about this one?
> Tomcat does not deserialize object streams from untrusted sources, so
> Tomcat has no vulnerability, here. Also, Tomcat does not use any of the
> libraries mentioned in the report, though I'm sure that list is now
> exhaustive.
> Applications running on Tomcat may, however, be vulnerable to this
> attack, but the vector isn't Tomcat: it's the application and its
> failure to validate data from an untrusted source before deserializing
> such data.

Let me slightly amend my statement above: Tomcat could potentially be
used as an attack vector against a system by someone with write-access
to the part of the filesystem where Tomcat stores its serialized session
objects during a restart (if that session-saving feature is enabled):

1. Attacker locates an application with commons-collections
   (or a similar library with that kind of capability)
2. Attacker shuts down Tomcat
3. Attacker modifies the serialized session file to include
   a trojan horse

The attacker doesn't even have to restart Tomcat: if an administrator
notices that Tomcat is stopped, the admin might just go ahead and
re-start Tomcat and - boom - your exploit is run.

Now, the above isn't very likely, but it certainly is possible. If you
have an attacker with write access to your files, you have kind of
already lost the battle.

Even if there is no vulnerable application, an attacker with write
access to Tomcat's directories might be able to install
commons-collections (etc.) into Tomcat's lib/ directory and then perform
the same type of attack against the ROOT application.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message