
What is remote code execution (RCE)?
Remote code execution, or RCE for short, describes a vulnerability that allows attackers to remotely execute arbitrary code on a target system—often without physical access or local system privileges. This makes RCE one of the most dangerous threats in IT security.
There are typical attack vectors such as insecure deserialization, file upload without validation, buffer overflows, or insecure PUT/POST requests.
Why is RCE so critical?
- Initial access: Attackers can hijack systems via RCE, install web shells, and set up backdoors.
 - Impact: Data theft, ransomware, cryptomining, lateral movement in the network – complete takeover.
 - Active exploits: In 2025, there were several critical CVEs such as CVE-2025-24813 (Apache Tomcat), CVE-2025-53770 (SharePoint ToolShell), CVE-2025-47812 (Wing FTP) – all actively exploited in real-world operations.
 
Current RCE examples from 2025
CVE‑2025‑24813 – Apache Tomcat
Insecure temp file handling in PUT with content range allows malicious session files to be stored via PUT requests, which execute code when deserialized during retrieval via JSESSIONID – completely without authentication.
CVE‑2025‑53770 – Microsoft SharePoint („ToolShell“)
Multiple deserialization vulnerabilities in SharePoint On-Prem component ToolPane.aspx enable unauthenticated RCE – Microsoft lists active attacks, CISA calls for patch by August 2025.
CVE‑2025‑47812 – Wing FTP Server
A critical RCE bug allows zero-byte injection via user names and execution of Lua code during session deserialization. Root/SYSTEM access possible – attacks already in use at Airbus, US Air Force, and more.
Other highlights
- Veeam Backup & Replication CVE-2025-23120: Domain users can execute code system-wide.
 - WordPress “Contact Form 7” plugin CVE-2025-3515: Insecure uploads (.phar) lead to code execution.
 - A-Blog CMS CVE-2025-31103: Insecure deserialization and arbitrary file upload → RCE.
 
How RCE exploitation works
Typical attack methods:
- Deserialization attacks: Insecure deserialization (SharePoint, WordPress, CMSs).
 - File upload vulnerabilities: Uploading .php/.phar files via insufficient checks (e.g., WordPress).
 - PUT/POST exploits: Temp file manipulation or POCs via HTTP PUT (e.g., Tomcat).
Buffer overflows, null byte injection (e.g., Wing FTP). 
Simplified attack flow:
- Attacker identifies open attack surface (e.g., PUT endpoint, upload function).
 - Craft payload: Websocket, serialized object, or .phar with PHP webshell.
 - Send request: PUT/POST with payload.
 - Vulnerable server loads file/deserializes object.
 - Code runs with privileged rights.
 - Persistence: Install shell, lateral movement, manipulate logs.
 
Practical example: How an RCE works in practice
To help you better understand what a remote code execution attack looks like in reality, let’s take a simplified scenario.
Important: This example is for demonstration purposes only – please do not apply it to external systems!
Scenario
A company operates an internal web app for document management.
- The app allows PDF uploads.
 - Uploaded files are stored in /uploads/.
 - The app only checks the file extension, not the actual content.
 
Step 1: Recon – Find the gap
An attacker checks the upload function:
He uploads a harmless test.pdf file and notices:
The file can be accessed directly at:
https://intranet.example.com/uploads/test.pdf
This means that files end up publicly accessible on the web server.
Step 2: Create payload
The attacker creates a webshell, e.g. in PHP:
<?php
// simple webshell
if(isset($_GET['cmd'])){
  system($_GET['cmd']);
}
?>
He saves this file as shell.php.pdf (double extension) and uploads it.
Step 3: Server processes the file
- The server only checks for .pdf → Upload successful.
 - The file ends up in /uploads/shell.php.pdf.
 - The web server (Apache/Nginx) interprets .php before .pdf → PHP is executed!
 
Step 4: Remote Code Execution
The attacker opens the file in the browser and enters a command with:
https://intranet.example.com/uploads/shell.php.pdf?cmd=whoamiResult:
- The server executes the command and returns www-data.
 - RCE successful!
 
Step 5: Expansion of the attack
The attacker can now execute further commands, e.g.
?cmd=cat /etc/passwd
?cmd=powershell Invoke-WebRequest ...
In reality, the following usually happens next:
- Persistence (backdoor/shell)
 - Privilege escalation (admin/SYSTEM)
 - Lateral movement in the network
 
How could this have been prevented?
- Whitelist of file types (e.g., only genuine PDFs based on MIME & magic number)
 - No direct executability of uploads in Webroot
 - Web application firewall against cmd= parameters
 
Prevention & protective measures
Patching & Updates
- Install patches for Apache Tomcat (version 11.0.3 or higher), SharePoint, Wing FTP, WordPress plugins, etc. immediately.
 - Microsoft Patch Tuesday for RDP client (CVE-2025-29966) and IE mode (CVE-2025-30397) is essential.
 
Security for uploads
- Whitelist instead of blacklist: Only allow permitted file types.
 - Check not only MIME types, but also file extensions and content.
 - Sandboxing or quotes for deserialization.
 
Secure deserialization
- Avoid BinaryFormatter or unsafe deserialization in .NET.
 - Use secure libraries or manual validation.
 - Disable legacy APIs or workflows (e.g., SharePoint Workflow) if unnecessary.
 
Deploying a web application firewall (WAF)
Rules block POST with Content‑Type: application/octet-stream on workflow.aspx, file‑upload‑Pattern, PUT‑Requests, etc.
Least Privilege & Auditing
- Restrict user rights: no excessive ScriptVar access, limited admin rights.
 - Monitor logs: unexpected PowerShell starts, w3wp.exe activities, anomalies.
 
Threat Hunting & Incident Response
- Search for indicators of compromise (IOC): unusual POSTs, shared payloads, unknown processes such as cmd.exe or powershell.
 - Remove compromised systems – patch plus forensics if exploits have already occurred.
 
Security awareness within the team
- Train developers: secure deserialization, input validation, secure upload handling.
 - Raise awareness among administrators: no RDP connections to unknown servers (especially RDP client CVE-2025-29966).
 
Conclusion
Remote code execution is not a theoretical risk – in 2025, numerous active exploits (Tomcat, SharePoint, FTP servers, WordPress) show how vulnerable systems still are. In your company, you should:
- Patch quickly,
 - Avoid insecure uploads and deserialization,
 - Use WAF rules,
 - Minimize access rights,
 - Monitor logs continuously.
 - With solid protective measures, you can effectively prevent RCE attacks and significantly increase the security of your systems.
 
Stay safe – and don’t get hacked! 😎







