Most developers think of file uploads as a normal application feature.
Users upload:
- Profile pictures
- Documents
- PDFs
- Reports
Nothing unusual.
But sometimes the most dangerous vulnerabilities aren't caused by complex bugs.
They're caused by features behaving exactly as configured.
One famous example is the Apache Tomcat PUT Upload vulnerability.
At first glance, it looks harmless.
A server accepts uploaded files.
That's it.
But under certain conditions, an attacker could upload a file that the server would later execute.
And suddenly:
File Upload
↓
Code Execution
↓
Server Access
The feature didn't just store a file.
It became an entry point.
A Warehouse Analogy
Imagine a warehouse.
The company creates a delivery door so suppliers can drop off packages.
The process looks like this:
Supplier
↓
Delivery Door
↓
Warehouse Storage
Simple.
Now imagine nobody checks what gets delivered.
One day someone delivers:
A package
Containing instructions
For controlling the warehouse
The warehouse stores it.
Later, somebody opens it.
And those instructions start running.
The delivery system worked perfectly.
The problem was what was allowed through the door.
This is similar to what happened in the Tomcat vulnerability.
What Is Apache Tomcat?
Apache Tomcat is a Java web application server.
It runs many web applications and APIs.
A simplified view looks like:
Browser
↓
Tomcat
↓
Java Application
When users access a website, Tomcat receives requests and delivers responses.
Many enterprise applications rely on Tomcat.
This is one reason vulnerabilities in Tomcat attract so much attention.
Understanding HTTP Methods
Most developers are familiar with:
GET
Retrieve information.
Example:
GET /profile
And:
POST
Submit information.
Example:
POST /login
But HTTP supports other methods too.
Including:
PUT
PUT is intended for creating or replacing resources.
Conceptually:
Client
↓
Uploads Resource
↓
Server Stores Resource
Nothing inherently dangerous.
The risk comes from how the server handles the uploaded content.
The Feature That Became a Problem
Certain Tomcat configurations allowed PUT requests.
Example:
PUT /test.txt
The server would store:
test.txt
Perfectly reasonable.
The issue appears when the uploaded file isn't just data.
Imagine uploading:
application.jsp
Instead of:
image.png
document.pdf
report.docx
Now the server isn't storing a passive file.
It's storing executable code.
Why JSP Matters
Tomcat can execute Java Server Pages (JSP).
Think of a JSP file as code that runs on the server.
Example:
Browser
↓
Request JSP
↓
Tomcat Executes Code
↓
Response
This is useful for building dynamic applications.
Unfortunately, it also means uploaded JSP files may become executable.
The Attack Chain
The vulnerability can be understood as:
Attacker
↓
PUT Request
↓
Upload JSP File
↓
Tomcat Stores File
↓
Request JSP
↓
Tomcat Executes File
What started as a file upload ends as remote code execution.
Why Developers Should Care
Many developers hear about this vulnerability and think:
"That's a server problem."
Not really.
The underlying lesson appears in countless applications.
Developers frequently build:
- Document upload systems
- Media upload systems
- User-generated content platforms
- Internal tools
The core question is always:
What exactly are we allowing users to upload?
A file is not automatically safe simply because it's a file.
Why DevOps Engineers Should Care
For DevOps teams, this vulnerability highlights something equally important:
Configuration Is Security
Many incidents aren't caused by code bugs.
They're caused by:
Default Settings
Misconfigurations
Legacy Features
Forgotten Options
The application may be secure.
The infrastructure may not be.
A useful DevOps question is:
What capabilities are enabled
that nobody actually needs?
Reducing unnecessary functionality reduces risk.
Understanding Initial Access
One of the most important cybersecurity concepts is:
Initial Access
This simply means:
The first successful foothold an attacker gains.
In this case:
Upload File
↓
Execute File
↓
Gain Initial Access
The attacker doesn't immediately control everything.
But they now have a starting point.
And security incidents often begin with a small foothold.
Common Misconceptions
"The Upload Feature Is Vulnerable"
Not necessarily.
The upload feature may work exactly as designed.
The issue is whether executable content can be uploaded and executed.
"Only Tomcat Has This Problem"
No.
The same principle appears across many technologies.
Whenever applications:
Accept Files
Store Files
Execute Files
the risk must be considered.
"It's Just a Configuration Issue"
Configuration issues can become security issues.
From an attacker's perspective, the reason matters less than the result.
The Bigger Lesson
The Tomcat PUT Upload vulnerability isn't really about Tomcat.
It's about trust boundaries.
A user-controlled file crossed multiple layers:
User
↓
HTTP Request
↓
Web Server
↓
Application Server
↓
Code Execution
Every transition introduced risk.
And that's a lesson that applies to security, software development, and operations alike.
Key Takeaways
- HTTP PUT is designed for uploading or replacing resources.
- Apache Tomcat can execute JSP files.
- Uploading executable content can lead to remote code execution.
- Initial access often begins with a small foothold.
- Configuration choices can have major security consequences.
- Developers should carefully evaluate upload functionality.
- DevOps teams should minimize unnecessary server capabilities.
- Security failures often emerge where features and trust boundaries intersect.
Final Thoughts
One reason this vulnerability remains a valuable learning exercise is that it doesn't rely on an exotic bug.
Instead, it demonstrates a more common reality:
Features become dangerous when we forget how they interact with the rest of the system.
A file upload seems harmless.
A web server seems harmless.
A configuration setting seems harmless.
But when those pieces connect in unexpected ways, a simple upload can become server access.
And that's a lesson every developer, DevOps engineer, and security professional can benefit from understanding.
Top comments (0)