Back to glossary

Remote code execution (RCE)

2 min read

In offensive security, remote code execution (RCE) is a flaw that lets an attacker run their own instructions on a target system across the network, without needing an account on that system. It is the outcome that other classes of bug lead to, and the finding that decides the severity of a report.

July 29, 2026
Compartir:

How it works

Remote code execution is a result, not a technique. Several routes reach it. Untrusted input reaches an interpreter or a shell, which is command injection or template injection. Untrusted bytes reach a deserialiser that can construct arbitrary objects, which is insecure deserialisation. A memory safety defect lets an attacker control the instruction pointer. A file upload lands somewhere the server will execute it. A vulnerable dependency provides any of the above inside code nobody wrote.

What all of them share is that the boundary between data and instructions has been crossed. Once it is crossed, the attacker inherits the identity, the network position and the secrets of the affected process. That is the part that decides how bad it is.

What goes wrong

The mistake that costs the most is treating every instance as equally critical. Execution as an unprivileged user inside a container with no credentials and no outbound network is a serious finding. The same defect in a process that holds a database password, a cloud instance role and unrestricted egress is a breach in progress, because the next steps are credential dumping and lateral movement, not the execution itself.

The second mistake is proving it by running a command that also does harm. On a live estate the proof has to be something with no side effect: a controlled callback, a benign identity command, a file written to a scratch path. We agree what is acceptable before we start, because a proof that takes production down is not a proof, it is an incident we caused.

Where this shows up in an audit

An execution finding is written as a chain: the entry point, the injected input, the evidence that our instructions ran, the identity they ran as, and what that identity could reach. We include the exact request and the response that demonstrates control, and we state what we deliberately did not do. Scores are attached from the house rating process using CVSS and the observed blast radius, never from a number copied out of an advisory for a different environment. This is part of how we chain findings to a working proof on a web target.

¿Quieres ver cómo trabajamos en Asperis Security?

Agenda 30 minutos con uno de nuestros especialistas. Revisamos tu stack y te decimos qué conviene probar primero.