+
Book Your Live Demo Now
Schedule a 30-minute live demo with one of our experts
Oops! Something went wrong while submitting the form.
Your data is safe with us. Read our Privacy Policy.
A newly disclosed vulnerability in the popular Apache Tomcat server is being actively exploited, allowing attackers to remotely take control of Linux-based systems running the software. This critical flaw (tracked as CVE-2025-24813) enables unauthorized code execution via a simple web request, putting countless enterprise Linux servers at risk. In this article, we explain why this Tomcat vulnerability matters, how the exploit works, who is in the crosshairs, and most importantly, how to defend your systems using proactive security measures like execution integrity and zero-trust principles.
A severe security bug in Apache Tomcat – one of the most widely used Java application servers on Linux – has sent shockwaves through the cybersecurity community. Disclosed in March 2025, the flaw allows an attacker to gain remote code execution (RCE) on unpatched Linux servers simply by sending a specially crafted HTTP request. Within days of the vulnerability’s announcement, exploit code appeared on public forums, and attackers began scanning the internet for vulnerable servers to compromise.
This incident matters because it highlights how quickly threat actors weaponize new vulnerabilities. Even though Apache Tomcat’s default settings are secure against this particular exploit, many organizations unknowingly run Tomcat in configurations that enable the vulnerability. In fact, security analysts observed that malicious scans and attack attempts started barely 1–2 days after the bug’s disclosure, meaning defenders had almost no grace period. With Tomcat powering countless web applications in finance, government, education, and beyond, a successful exploit could lead to database theft, ransomware deployment, or an entire Linux server being hijacked. It’s a stark reminder that Linux systems, while robust, are not invincible – proactive defense is critical.
Apache Tomcat serves web applications and typically processes HTTP requests like GET (for fetching pages) and POST (for form submissions). This vulnerability hinges on a less common HTTP method: a “partial” PUT request with a Content-Range header, which is normally used to upload files in chunks. A bug in Tomcat’s request handling allows an attacker to exploit partial PUTs in a dangerous way when certain settings are enabled. Here’s a simplified breakdown of how the attack unfolds:
Content-Range header, tricking Tomcat into treating it as a partial file upload. Because of the bug, Tomcat doesn’t handle the file path correctly – it creates a temporary file on the server with an unusual name (replacing directory slashes with “.” in the filename). The content of this file is crafted by the attacker, often containing malicious Java serialized objects or web shell code. Importantly, no login or credentials are needed – the server sees the request as if it were a normal file upload.Once this exploit chain is successful, the attacker can perform any action on the server that Tomcat’s user account can. Typically, that means installing web shell backdoors, creating new user accounts, or launching further malware to take full control of the Linux server. All of this is achieved with a simple HTTP request sequence, making it a low-effort, high-impact attack for hackers.
Who is vulnerable? Any organization running Apache Tomcat on their Linux servers could be at risk if they have not updated to the fixed version and if their Tomcat configuration meets the exploit conditions. While the most recent Tomcat releases (9.0.99, 10.1.35, 11.0.3 and above) have patched this flaw, older Tomcat versions (9.x, 10.x, 11.0.2 and below) are susceptible. Even though the exploit requires non-default settings, real-world data suggests many servers are unknowingly configured in vulnerable ways. In the weeks following the disclosure, one analysis found that vulnerable Tomcat packages were downloaded nearly 100,000 times — indicating that numerous installations out there might still be deploying the flawed software. Attackers are banking on this fact by broadly scanning for any Tomcat server that responds to the exploit attempt.
Potential impact: For those unlucky systems that are both vulnerable and found by attackers, the consequences are severe. A successful exploit gives the adversary a foothold on the server with the ability to execute commands. This could lead to:
It’s worth noting that as of now, this vulnerability is mainly being exploited opportunistically — security researchers observed only a handful of attack sources in the very early days. However, that number was climbing, and more sophisticated attackers could adopt the exploit at any time. Every exposed Linux server running Tomcat is a potential target. Even if your own configuration is secure, it’s wise to double-check and ensure updates are applied, because attackers move quickly when a critical weakness is revealed. The broader lesson is clear: relying on defaults and reactive patching isn’t enough when threats evolve this fast.
Tomcat’s “partial PUT” vulnerability underlines the need for a proactive security posture. Simply waiting to react after an attack is detected can lead to catastrophe. Instead, Linux administrators should combine prompt patching with modern protection strategies that stop unauthorized execution in its tracks. Here are key measures to help defend against this threat (and future ones):
✅ Apply Updates: First and foremost, update Apache Tomcat to the latest patched version. The project has released fixes—make sure your Linux servers are not running the vulnerable releases. This removes the known flaw entirely.
✅ Review Configurations: Double-check Tomcat’s settings. Disable any optional features you don’t actively need. For instance, ensure the default file servlet remains read-only (as per default) and that features like file-based session persistence are only enabled if absolutely required.
✅ Reduce Attack Surface: If your web application doesn’t need to accept file uploads or the PUT method, consider disabling those methods or using a web application firewall to block unexpected request types. The less exposed functionality, the fewer avenues an attacker has.
Why? Patching closes the specific hole attackers are exploiting, and hardening configurations helps prevent similar tricks. By removing unnecessary features, you shrink the ways an attacker can attempt to break in.
✅ Allow-List Trusted Code: Configure your Linux servers to allow only known, trusted applications and scripts to run. Any unknown or modified executable should be blocked from launching. Solutions that maintain an allowlist of processes can enforce this automatically.
✅ Verify Code Before Execution: Use security tools or system policies that examine new files or code (like a newly uploaded .jsp or .jar file in Tomcat’s directories) before they execute. If the file isn’t recognized or is suspicious, it should never be allowed to run.
✅ Monitor Process Launches: Keep an eye on new processes. Tomcat typically should not spawn random shell processes — if it does (for example, an attacker’s payload starting a system shell), an integrity enforcement tool can detect this anomaly and terminate it.
Why? Execution integrity stops malware and unauthorized code in its tracks. Even if an attacker manages to drop a malicious file on your server, it can’t do harm if it’s never allowed to execute. This proactive stance is far more effective than trying to clean up after a malicious program has already run.
✅ Never Trust by Default: Treat every process and request within your server as untrusted until verified. For Tomcat, this means not assuming all incoming traffic is benign. Implement strict verification — for example, require admin approval or additional checks when the server tries to perform unusual actions (like writing to certain system directories).
✅ Least Privilege for Services: Run the Tomcat service under a dedicated low-privilege Linux user account, not as root. Lock down what that account can do on the system. If Tomcat doesn’t need to modify certain files or execute other programs, it shouldn’t have permission to.
✅ Isolate Critical Resources: Use containerization or virtualization to isolate the Tomcat process from the rest of your environment. Employ network segmentation so that even if Tomcat is compromised, an attacker can’t freely reach your database or internal network without encountering additional barriers.
Why? Zero-trust means assuming breach and limiting trust accordingly. By minimizing Tomcat’s privileges and isolating it, you greatly reduce the damage a successful exploit can cause. If an attacker does hijack the process, they find themselves constrained in a sandbox with limited access, rather than roaming free across your system.
✅ Watch Your Logs: Enable detailed logging on your web server and monitor for weird events. For example, alerts on HTTP PUT requests to your application can tip you off if someone is trying this exploit. Also monitor filesystem changes in Tomcat’s directories (e.g., sudden appearance of a .session file or .jsp file in odd places).
✅ Behavioral Analytics: Deploy intrusion detection or endpoint security that uses behavior analysis rather than just signatures. This can catch things like a Tomcat process suddenly spawning a shell or writing files to system directories – behaviors that are out of the ordinary.
✅ File Integrity Monitoring: Set up integrity checks on critical files (configuration files, binaries, libraries). If an attacker manages to alter any of these (for instance, planting a backdoor in a startup script), you want to get alerted immediately about the change.
Why? Early detection is key. The sooner you know something suspicious is happening, the faster you can respond to prevent a full-blown breach. Modern attacks often blend in with normal activity, so monitoring for subtle anomalies – not just known malware signatures – gives you a fighting chance to catch them.
✅ Egress Filtering: Limit or block your server from making outbound connections to the internet, except for what’s necessary. Tomcat servers usually serve content but don’t need to call out to external sites. By blocking unnecessary outbound traffic at the firewall or host level, you prevent an attacker from easily downloading second-stage tools or exfiltrating data if they do get in.
✅ Network Segmentation: Place your Tomcat servers in a segmented network zone with strict rules. For instance, they should only communicate on specific ports to the frontend and backend systems required (like a database). If an attacker compromises the server, strong network segmentation can stop them from reaching other sensitive systems or spreading laterally through your infrastructure.
✅ Continuous Verification: Implement zero-trust networking principles — even inside your data center. Require authentication and checks for any connection between the web server and other services. This way, an attacker who hijacks the web server process cannot automatically access everything else on the same network without overcoming additional security checks.
Why? By containing the server’s connectivity, you limit what a hacker can do post-exploit. Even if they gain a foothold, they’ll have a hard time communicating with command-and-control servers or moving deeper into your environment. It turns a potentially wide-ranging breach into a localized issue that you can root out more easily.
The rapid exploitation of this Tomcat vulnerability is a wake-up call for anyone responsible for Linux systems. Attackers are constantly probing for weaknesses and will strike as soon as one is revealed – often faster than organizations can patch. Relying solely on reactive measures like traditional firewalls or waiting for an attack alert means playing catch-up with threats. Instead, a paradigm shift toward proactive security is needed to stay ahead.
Key takeaways:
✅ Don’t rely on default trust or late patching – harden your systems and eliminate unnecessary risk factors before attackers find them.
✅ Prevent unauthorized code execution – through execution integrity controls and strict allowlisting, ensure malware never gets the chance to run.
✅ Assume breach and limit its impact – adopt zero-trust principles and robust monitoring so that even if something slips through, it’s detected early and contained.
Linux servers form the backbone of critical applications worldwide. Incidents like this Tomcat exploit show that even these backbone systems can falter if not vigilantly protected. The best defense is a proactive, preemptive security approach that doesn’t wait for a crisis to react. By updating your systems promptly and implementing strong preventive controls, you can significantly reduce the risk of compromise. In today’s threat landscape, staying one step ahead of attackers isn’t just advisable – it’s essential to keep your Linux environments secure.
Stay vigilant, stay proactive, and keep your Linux systems locked down against the next attack.
