Secretive Apache Tomcat Critical Vulnerability Circumvents Security Filters: Is Your Security Compromised?

Image: cynoclub/Envato Elements
An active cybercriminal campaign targets Apache Tomcat by exploiting a newly revealed weakness that permits remote code execution (RCE).

Stealthy Apache Tomcat Critical Exploit Bypasses Security Filters: Are You at Risk?

Stealthy Apache Tomcat Critical Exploit Bypasses Security Filters: Are You at Risk?
Image: cynoclub/Envato Elements

An active cybercriminal campaign targets Apache Tomcat by exploiting a newly revealed weakness that permits remote code execution (RCE). Through basic HTTP requests, assailants can initiate the deserialisation of malevolent data, seizing command of impacted systems.

The weakness, CVE-2025-24813, was unveiled by Apache on March 10, and a primary proof of concept surfaced on GitHub around 30 hours later, posted by the user iSee857. Shortly after, security enterprise Wallarm detected this exploit in the wild, cautioning that these assaults escape detection by traditional security filters as the HTTP requests appear unremarkable and nasty payloads are encoded in base64.

Initially, an assailant dispatches a PUT request housing an encoded, serialized Java payload, which is then inscribed inside Tomcat’s session storage and automatically stored in a file. Subsequently, they send a GET request with a JSESSIONID cookie connected to the malevolent session.

Upon processing this request, Tomcat unserializes the session data lacking proper authentication, activating the embedded malevolent Java code and authorizing the assailant full remote control.

SEE: How to Utilize the Apache Web Server for Website Installation and Configuration

Which Apache Tomcat versions are susceptible?

Authenticating is unnecessary for a successful exploit; as per Apache’s security advisory, these conditions render a Tomcat application vulnerable:

  • Default servlet enables writes
  • Partial support for PUT requests is activated
  • Tomcat incorporates a library viable for deserialization offenses
  • Default storage location uses file-based session persistence

In addition to remote code execution exploits, if the following criteria are met, attackers can view or amend security-critical files:

  • Default servlet enables writes
  • Partial support for PUT requests is enabled
  • Security-sensitive files are placed in a publicly accessible folder and were uploaded via partial PUT
  • The attacker is aware of the filenames

Given these prerequisites, the following Apache Tomcat versions are all open to exploitation:

  • Apache Tomcat 11.0.0-M1 to 11.0.2
  • Apache Tomcat 10.1.0-M1 to 10.1.34
  • Apache Tomcat 9.0.0.M1 to 9.0.98

Mitigation: Safeguarding Your System

As a preventative measure, Apache advises updating to Tomcat versions 11.0.3 or later, 10.1.35 or later, or 9.0.99 or beyond, as they incorporate the necessary patches. Alternatively, users can deactivate partial PUT support, restrict writes for the default servlet, and refrain from storing security-sensitive files openly accessible folders.

Wallarm researchers caution that this vulnerability exposes the likelihood of other security faults manifesting due to Tomcat’s treatment of partial PUT requests, “allowing the upload of virtually any file to any location”.

“Attackers are poised to adjust their strategies, uploading malicious JSP files, adjusting configurations, and implanting backdoors beyond session storage,” said in a post on their blog. ”This marks only the initial wave.”

About Author

Subscribe To InfoSec Today News

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

World Wide Crypto will use the information you provide on this form to be in touch with you and to provide updates and marketing.