Remote Code Execution (RCE)

Remote code execution, usually shortened to RCE, is a class of security vulnerability that lets an attacker run code of their choosing on a target computer over a network. The attacker needs no physical access and, in the most serious cases, no account or credentials: a crafted network request is enough. RCE is the most severe outcome a vulnerability can have, because once an attacker can execute code, everything else, from stealing data to installing persistent access to moving to other systems, follows from it. PHP2Shell showed what that means in October 2026: two flaws in the PHP runtime, rated 9.2 under CVSS v4.0, that an attacker could trigger over HTTP without logging in, with public exploits already circulating.

What is remote code execution?

An RCE vulnerability is a flaw in how a program handles input it receives from the network. The program is supposed to treat that input as data. A bug lets specially constructed input change the program's behavior instead, until the attacker controls what the processor executes. Two common mechanisms are memory corruption bugs, such as buffer overflows and use-after-free errors in C and C++ code, where crafted input overwrites memory the program later trusts, and injection bugs, where input is passed to an interpreter, a shell, or a deserializer that executes it.

Two qualifiers matter when reading an advisory. Unauthenticated RCE means the attacker needs no login; anyone who can reach the service over the network can exploit it. Pre-authentication or "before application code runs" means the flaw is in the server or runtime itself, so the application's own input validation never gets a chance to act. The PHP2Shell flaws of October 2026, CVE-2026-109618 and CVE-2026-109619, show both. Neither needed a login, and on Apache with mod_php, an unauthenticated request could trigger CVE-2026-109618 before any application code ran, so the application's own input validation offered no protection.

Why RCE matters

Severity scoring reflects it. Under CVSS, an unauthenticated RCE that is exploitable over the network with no user interaction scores near the top of the scale; PHP2Shell was rated 9.2 under CVSS v4.0.

RCE also sets the pace of response. Once a fix for an RCE is public, attackers can study the patch to build an exploit. For PHP2Shell, public exploit tooling was circulating, and the Dutch NCSC considered large-scale exploitation likely in the short term. The time between a fix going public and your last host being patched is the exposure window, and for an unauthenticated RCE in an internet-facing service it has to be measured in hours. Our guide on staying secure when AI finds vulnerabilities faster covers the engineering it takes to close that window.

AI-assisted discovery skews toward RCE. Of the 2026 vulnerabilities the Google Threat Intelligence Group identified as likely AI-discovered, half result in remote code execution, against 26 percent across the wider CVE ecosystem. AI-assisted research is good at the step that turns a known memory bug into a proven exploit path, which is how one of the PHP2Shell flaws went from an unprioritized 2024 audit finding to a critical RCE.

RCE compared with related vulnerability classes

Class	What the attacker gains	Typical severity
Remote code execution	Runs arbitrary code on the target over the network	Critical
Privilege escalation	Turns limited access into higher privileges, often root; can be chained after an RCE or a stolen credential	High
Information disclosure	Reads data they should not see, such as memory contents or files	Medium to High
Denial of service	Crashes or stalls the service	Medium
Cross-site scripting	Runs script in another user's browser, not on the server	Medium

An RCE in a service running as root is the worst case. An RCE in a service running as an unprivileged user with role-based access controls and a confined environment is still serious, but the attacker has further work to do, which is why least privilege and confinement reduce the impact even when they cannot prevent the initial exploit.

Defending against RCE

• Patch quickly on every version you run. The fix is the only complete remedy. Because distributions backport fixes into pinned versions, check the distribution's fixed package version, not the upstream version number.
• Reduce the attack surface. Don't run network services you don't need. For PHP2Shell, the CIQ knowledge base advised stopping and disabling php-fpm on hosts where PHP was installed but not in use. Put internet-facing services behind a reverse proxy, and limit who can reach administrative interfaces.
• Run services with least privilege. An exploit inherits the privileges of the process it compromises. Unprivileged service accounts, SELinux confinement, and container boundaries limit the damage.
• Apply vendor mitigations as a bridge. Configuration changes recommended in an advisory can close specific attack paths while a patch is being rolled out. They don't replace the patch. For PHP2Shell, the PHP security team warned that updating to a patched release is the only reliable mitigation.
• Detect exploitation in progress. Runtime integrity monitoring can flag an attacker who uses a foothold to tamper with the kernel or escalate privileges. It detects exploitation attempts. It doesn't prevent them, and it doesn't replace patching.
• Rebuild images on a fixed base. Containers and stateless nodes run the vulnerable code from their image, so patching a running instance doesn't last. Rebuild on a fixed base and redeploy.

For a worked example, from checking which PHP stream a host runs to the fixed package for each RLC Pro release, see the PHP2Shell guide.