Glossary
What is RCE (Remote Code Execution) — why it's the worst class of bug
RCE (Remote Code Execution) lets an attacker run code on your server over the network — straight to takeover, the worst class. How it differs from XSS and SQLi, what sets the blast radius, and how to defend: fast patching, CVE monitoring, least privilege.
"A CVSS 10.0 RCE" — the phrase that makes security people tense up the most. Here's why RCE is the "worst class", and how it differs from other bugs, from zero.
How it differs from other bugs
Most vulnerabilities have limited blast radius. RCE runs commands on the server itself, so it's an order of magnitude worse.
| Vulnerability | Where code runs | Main damage | Typical severity |
|---|---|---|---|
| XSS | the browser | session theft, defacement | medium–high |
| SQLi | the database | read/alter data | high |
| RCE | the server itself | takeover, lateral movement, everything | worst (10.0-class) |
Why it's the worst class
An attacker running commands on your server means anything that process can do, they can do.
RCE achieved (arbitrary code execution)
.env and steal secretsThe blast radius is set by "that process's privileges". That's exactly why containerization, least privilege, and isolation (minimizing the blast radius) work. Run as root and it's all gone; run non-privileged and isolated and you contain it.
Most RCEs come from "known holes", not your own bugs
RCE very often comes not from a bug you wrote, but from a known hole in a framework or library you use. Many landmark incidents were RCEs.
- Log4Shell (CVE-2021-44228): RCE via a logging component; the world panicked.
- The neglected CVSS 10.0: a published RCE left unpatched for months.
What you can do to defend
Don't neglect published CVEs (the biggest defense)
Monitor CVEs with machines (Dependabot / osv-scanner) and update to fixed versions fast. Most RCEs come from neglecting known holes.
Judge by the running version
Measure risk by the version actually running, not the manifest floor. Trusting the text misjudges the danger.
Minimize the blast radius
Run as a non-privileged user; isolate containers and networks. Contain the damage if you are hit.
Don't pass input straight into execution
Never feed external input directly into shell commands, deserialization, or template evaluation. The basics of not authoring an RCE yourself.
Read next
- Glossary: What is a CVE · What is CVSS
- History: Log4Shell — RCE through a dependency
- Defense: Running Next.js safely (CVE hygiene)
FAQ
QHow is RCE different from common bugs like XSS?
XSS and friends mostly misbehave inside the user's browser; RCE runs arbitrary programs on the server itself. Because it can reach the server's privileges, data, and other services, it's generally the most severe class.
QHow far does RCE damage spread?
As far as the privileges of the process that was running when it was attacked. Run as root or with broad rights and the damage is huge; run as a non-privileged user with container isolation and you can contain it. That's why least privilege and isolation matter.
QHow do I (a developer) defend against RCE?
Besides not writing RCE bugs yourself (don't pass input straight into execution), the biggest defense is not neglecting published RCEs in the frameworks/libraries you use. CVE monitoring and fast updates are the core.