What Is Remote Code Execution (RCE)?

What is remote code execution?

Remote code execution is a class of vulnerability that lets an attacker run arbitrary code on a system they do not control, from across a network. Instead of only reading data or crashing a service, the attacker gets the target to execute instructions of their choosing. That is why RCE consistently rates among the most severe flaws in any scoring system: once an attacker can run code, they can often move to full control of the application, the container, or the host.

RCE is rarely a single bug on its own. It is usually the end of a chain: untrusted input enters the application, passes through a weakness that was never meant to run code, and reaches a function that executes it. Understanding RCE means understanding that chain.

How RCE attacks work

Every RCE follows the same shape. Attacker-controlled input reaches a dangerous sink, a place in the code where data is turned into executable instructions. The vulnerability is whatever lets untrusted input travel to that sink without being neutralized. The exploit is the crafted input that runs once it arrives.

Because the mechanism is a data-to-execution path, RCE is most dangerous in code that accepts external input and has a legitimate reason to evaluate, deserialize, or spawn something. The attacker does not need a special channel. They only need their input to reach the sink.

Common causes of remote code execution

• Command injection. User input is passed into a system shell or process call without proper separation, so the attacker's text becomes part of the command (CWE-78).
• Unsafe deserialization. The application rebuilds objects from untrusted serialized data, and crafted data triggers code during or after deserialization (CWE-502).
• Expression-language and template injection. Input is evaluated by an expression engine or template renderer. Server-side template injection (SSTI) is a common route to RCE.
• Unsafe code evaluation. Functions that evaluate strings as code receive untrusted input (CWE-94).
• Unrestricted file upload. An attacker uploads an executable file that the server later runs.

Many of the highest-profile CVEs of recent years are RCE chains of exactly these kinds. For real examples across ecosystems, see the CVE archive.

Why most critical RCE findings are not actually exploitable

A scanner flags an RCE-class CVE by its presence in your dependencies or code. That is not the same as risk. An RCE vulnerability only matters if the vulnerable code path is actually reachable and executes in your running application. A critical RCE in a library you import but never call on that path is not an urgent problem. A lower-scored issue on a code path that runs on every request may be.

This is the gap between theoretical severity and operational risk. Reachability analysis and runtime intelligence close it by confirming which vulnerable paths actually load and execute, so an RCE backlog becomes the short list that genuinely threatens the application.

How to prevent and detect RCE

Prevention is about keeping untrusted input away from execution sinks: validate and constrain input, avoid passing data to shells or evaluators, use safe deserialization, run with least privilege, and sandbox anything that must handle external content. These reduce how often a data-to-execution path exists at all.

Detection is the other half, because zero-days and logic flaws will slip past prevention. The goal is to catch an RCE at the moment it begins to execute, not after data has left. That is the role of application detection and response (ADR): it watches how the application actually executes and flags the moment behavior crosses from normal into an exploit, paired with runtime application protection to respond. Prevention plus runtime detection is what keeps an RCE from becoming an incident.

Frequently Asked Questions