Remote Code Execution (RCE)
detect, understand, remediate
Remote code execution lets attackers run arbitrary commands on your server by exploiting code injection flaws, unsafe deserialization, or unpatched dependencies, often leading to full system compromise.
No credit card required. Free plan available forever.
What is remote code execution?
Remote code execution (RCE) is one of the most critical vulnerability classes in application security. It allows an attacker to run arbitrary code on a target server or system from a remote location, without requiring physical access or pre-existing credentials. RCE vulnerabilities are classified under CWE-94 (Improper Control of Generation of Code) and consistently receive the highest severity ratings on the CVSS scoring scale, often achieving a 9.8 or 10.0.
When an attacker achieves remote code execution, the consequences are devastating. They gain the ability to read and write files on the server, access databases, install backdoors, pivot to internal networks, and exfiltrate sensitive data. RCE effectively gives the attacker the same level of control as the application process itself, and in many cases, this means root or administrator-level access to the underlying operating system.
RCE vulnerabilities arise from multiple attack vectors, including command injection, server-side template injection, unsafe deserialization, and exploitation of unpatched software components. Despite being well-documented, RCE remains prevalent because modern applications rely on complex dependency chains, dynamic code evaluation, and third-party libraries that introduce unexpected execution paths.
How it works
Identify input reaching code execution
The attacker discovers an input vector (form field, API parameter, file upload, or header) that is processed by a code execution function on the server.
Inject malicious payload
A crafted payload is submitted that contains executable code, shell commands, or serialized objects designed to trigger arbitrary code execution on the server.
Server executes attacker code
The application processes the input without adequate validation and passes it to an execution context such as eval(), a template engine, or a deserialization handler.
Full system compromise
The attacker achieves remote code execution with the privileges of the application process, enabling data theft, backdoor installation, lateral movement, and persistent access.
Common causes
Use of eval() and dynamic code execution
Passing user-controlled input to functions like eval(), Function(), setTimeout with strings, or exec() in languages such as JavaScript, Python, and PHP.
Unsafe deserialization
Deserializing objects from untrusted sources using native serialization mechanisms (Java ObjectInputStream, Python pickle, PHP unserialize) that execute code during reconstruction.
Template injection
Embedding user input directly into server-side template engines (Jinja2, Twig, Freemarker, Velocity) without sandboxing, allowing attackers to escape the template context and execute system commands.
Unpatched software and dependencies
Running outdated versions of frameworks, libraries, or server software that contain known RCE vulnerabilities with publicly available exploit code.
How to detect it
Automated detection
- SecPortal's code scanning uses Semgrep-powered SAST rules to identify dangerous patterns like eval(), exec(), and unsafe deserialization calls in your source code
- Dependency scanning (SCA) detects known RCE vulnerabilities in third-party libraries and frameworks, flagging outdated packages with published exploits
- SecPortal's authenticated scanner tests for runtime injection vectors by submitting payloads to discovered endpoints and monitoring for execution indicators
Manual testing
- Inject template syntax (e.g. {{ 7*7 }}) into input fields to test for server-side template injection that could escalate to RCE
- Submit serialized payloads crafted with tools like ysoserial or phpggc to test for unsafe deserialization in session tokens and API parameters
- Use out-of-band detection techniques (DNS callbacks, HTTP requests to a controlled server) to confirm blind RCE where output is not reflected
How to fix it
Eliminate eval() and dynamic code execution
Remove all uses of eval(), Function(), and similar dynamic code execution functions. Replace them with safe alternatives such as JSON.parse() for data parsing or static configuration for dynamic behaviour.
Sandbox execution environments
If dynamic code execution is absolutely necessary, run it in a sandboxed environment with strict resource limits, no filesystem access, no network access, and minimal privileges.
Validate and sanitise all input
Apply strict input validation using allow-lists for expected formats. Reject any input containing template syntax, shell metacharacters, or serialized object markers before it reaches processing logic.
Deploy a web application firewall (WAF)
Configure WAF rules to detect and block common RCE payloads, including template injection syntax, serialized objects, and shell command patterns. A WAF provides defense-in-depth but should not be the sole protection.
Maintain a rigorous patching schedule
Keep all frameworks, libraries, and server software up to date. Subscribe to security advisories for your technology stack and prioritise patches for known RCE vulnerabilities.
Compliance impact
Find RCE vulnerabilities before attackers do
SecPortal combines SAST code analysis with authenticated dynamic testing to detect code injection, unsafe eval, and deserialization flaws. Start free.
No credit card required. Free plan available forever.