Remote Code Execution (RCE), in plain English

What this is

Remote Code Execution, usually shortened to RCE, is the industry term for “an attacker on the internet can run their own commands on your server”. It is the worst category of bug a server can have. Once an attacker has it, every other security control on that machine (firewalls, accounts, encryption) becomes irrelevant for the data the machine can reach.

In severity terms, an unauthenticated remote RCE almost always scores 9.8 or 10.0 out of 10.

What attackers actually do once they’re in

Public reporting on incident response gives a clearer picture of what happens after a successful RCE than the old “smash and grab” narrative. Modern attackers behave very differently depending on their goals.

Cryptominers are the closest thing to smash-and-grab. They land on your server, install a coin miner, and run it until somebody notices the CPU usage. Inconvenient, but limited blast radius.

Ransomware operators are patient. The Mandiant M-Trends report puts median attacker dwell time before ransomware deployment at several days to weeks. They use that time to map the network, find backups so they can disable them, and exfiltrate sensitive data before triggering encryption. The exfiltrated data is the leverage for the “double extortion” model: pay the ransom or we publish your customer database.

Initial-access brokers make money by reselling access. They land on your server, take care to stay quiet (no noisy crypto- miner, no obvious changes), and put your access up for sale on underground markets. The next attacker who buys it might be a ransomware operator, a state-aligned group, or a phishing crew. You may not see any direct effect for months.

Espionage actors are the most patient of all. State-aligned groups regularly maintain access to compromised infrastructure for months or years, exfiltrating documents, monitoring email, and watching internal communications. The MOVEit, SolarWinds, and 3CX campaigns of recent years are the public examples. Average detected dwell time for these has fallen as detection has improved (Mandiant reports a global median around 10 days in 2024, down from over 200 in 2014), but undetected campaigns by definition aren’t in those statistics.

Phishing and BEC operators use your compromised infrastructure as a launchpad. A server that already passes your domain’s email authentication checks is far more valuable than a fresh server they have to warm up. They send invoice fraud and CEO-fraud emails from your real domain, with your real signatures, to your real customers and suppliers. Detection is hard because the messages genuinely come from you.

Supply-chain operators (the rarest and most damaging category) modify your build pipeline to add their code to whatever your customers download from you. CCleaner in 2017, Codecov in 2021, 3CX in 2023.

The common thread: most modern attackers don’t make noise. They sit, watch, prepare, and act on their own schedule. By the time behaviour is visible, the attacker has had weeks of access already.

What enables an RCE

Several common roads lead to RCE. CVE descriptions in your scan report usually mention one of them.

Memory bugs in software written in C or C++ (buffer overflow, use-after-free) that let the attacker rewrite the program’s memory and divert it to run their bytes.
Command injection, where the application takes input from a request and passes it unchecked to the operating-system shell. Old admin panels and CGI scripts are classic culprits.
Insecure deserialization, where the application reads a structured blob from the network and the way it interprets the blob lets the attacker pick which code paths run. See our deserialization article.
Template injection, where server-side template engines (Jinja, Twig, Velocity) evaluate untrusted input and let the attacker write loops and method calls into the response.
Unrestricted file upload combined with a misconfigured server, where the attacker uploads a .php or .aspx file to a directory the web server interprets, then asks for it.

What to do

When the scanner reports an RCE-class CVE on one of your services, the order of operations is the same regardless of which subcategory above it falls into.

Patch as soon as you can, out of band if necessary. Internet-facing RCEs do not wait for the next maintenance window. For US federal agencies, CISA gives two to three weeks via the Known Exploited Vulnerabilities catalogue. That deadline is meant for organisations with formal change processes. A small business should aim for days.
If patching cannot happen yet, take the affected service off the public internet. Move it behind a VPN, restrict it to specific source IPs, or shut it down until patched. A service that is not reachable cannot be exploited.
If you have evidence the attack already happened, treat the host as compromised. Do not try to clean it. Rebuild from a known-good image and rotate every credential the host could have touched. Once an attacker has had RCE, there is no reliable way to be sure they did not drop a hidden backdoor before you noticed. Given how patient modern attackers are, “we patched it the next day” is not a defence against an attacker who already had several hours of access.

For the cases where exploitation is plausible (KEV-flagged CVEs that have been around for a while, scans that show signs of modification you don’t recognise), an incident-response engagement is worth the cost. Forensic analysis of memory and disk images can identify the implants attackers leave behind.

Reading the severity in your scan

For RCE-class findings, the scanner shows three signals you can use to prioritise. See How to read a CVE for the full framework. The short version:

CVSS 9–10, no account needed, network-reachable: treat as a fire drill.
CVSS 7–9, account or unusual conditions needed: patch this week.
EPSS > 0.5 or KEV-flagged: someone is exploiting it right now. Patch ahead of anything else, even higher-CVSS findings without KEV.