What Is Remote Code Execution (RCE)? Causes & Defense

Remote code execution (RCE) is a security vulnerability that allows an attacker to run arbitrary malicious code on a target system over a network, without physical access and in many cases without authentication. Once code runs, the attacker operates with the privileges of the compromised process, which is why RCE sits at the top of nearly every severity scale.

Severity ratings across the industry reflect exactly that reach. The most consequential RCE flaws of the past two years, including React2Shell in React Server Components and CVE-2026-21962 in Oracle’s WebLogic proxy plug-in, both carry a CVSS score of 10.0, the maximum the scoring system allows. What makes them dangerous is not only what they permit but how quickly attackers put them to use.

RCE vs. Arbitrary Code Execution and Command Injection

Vulnerability reports and CVE descriptions use three related terms almost interchangeably, and the distinctions between them matter when reading one.

Network reachability alone makes an RCE flaw exploitable, and that is the difference from the rest. An attacker exploiting a local ACE flaw needs a foothold on the machine already. An attacker exploiting RCE needs only a network path, which means automated scanners can find and attack every exposed instance on the internet in parallel.

How Does Remote Code Execution Work?

RCE works by getting attacker-controlled input to a place where the system treats it as instructions instead of data. Four stages describe the path from an exposed service to code running on the host.

1. An exposed attack surface receives the input. Web applications, API endpoints, application servers, and network services all accept external data and pass it into backend logic.
2. Crafted input reaches a processing path never intended to receive it. Weak validation lets data containing commands, code, or serialized objects flow through as trusted content.
3. The runtime interprets that input as code. At this point, the boundary between data and instruction has broken down, and the payload executes inside the application process or an operating system shell.
4. The attacker inherits the process privileges. Whatever the compromised service can do, the attacker can now do, which opens the way to privilege escalation, persistence, or lateral movement.

Privilege level at stage four decides how bad the outcome gets. A web server running as an unprivileged service account limits the immediate blast radius, while the same flaw on a process running as root or SYSTEM hands over the host. Follow-on activity maps to well-documented techniques in the MITRE ATT&CK framework, which makes the post-exploitation stage more detectable than the initial exploit.

Common Causes of RCE Vulnerabilities

Most RCE findings trace back to a handful of recurring weaknesses. They differ enough from each other that no single control addresses all of them.

Improper Input Validation

Applications that fail to validate, sanitize, or constrain untrusted input let that input reach interpreters, shells, and evaluation functions. Where the application constructs a command or query from user-supplied text without separating data from syntax, the interpreter has no way to tell the difference.

Insecure Deserialization

Deserialization converts stored or transmitted data back into live objects. When an application deserializes untrusted input without validating it, an attacker can supply an object whose reconstruction triggers code execution. This pattern appears repeatedly across Java, .NET, PHP, and Python ecosystems, and it is the root cause behind React2Shell in the React Server Components protocol.

Memory Corruption Flaws

Buffer overflows, use-after-free bugs, and similar memory-safety defects let an attacker write data outside the bounds a program expects. In languages without memory safety guarantees, such as C and C++, careful manipulation of that corruption can redirect program flow into attacker-supplied instructions. Network daemons and parsers written in these languages remain a steady source of critical RCE findings.

Unpatched Known Vulnerabilities

Most RCE exploitation targets flaws that already have CVE identifiers and available patches. Attackers monitor disclosure feeds, take published proof-of-concept code, and scan for unpatched instances at scale. Nothing about this route requires original research on the attacker’s part.

Unsafe File Upload and Template Handling

Upload features that fail to restrict file types or storage locations allow an attacker to place executable content where the server will run it. Server-side template injection produces the same outcome through a different mechanism, when user input is embedded into a template that the engine then evaluates.

Misconfigured and Exposed Services

Administrative consoles reachable from the internet, default credentials left in place, and management interfaces bound to public addresses all shorten the path to execution considerably. Several of the WebLogic vulnerabilities exploited in the wild target the administrative console specifically, which is why restricting console exposure appears in nearly every vendor advisory for that product.

How Quickly RCE Vulnerabilities Get Weaponized

Patch windows have collapsed to a point where quarterly cycles no longer protect anything. CloudSEK ran a high-interaction honeypot emulating a vulnerable Oracle WebLogic Server for twelve days between 22 January and 3 February 2026, and recorded the first exploitation attempt against CVE-2026-21962 on 22 January, the same day public exploit code appeared on GitHub. There was no lag between disclosure and mass scanning at all.

Disclosure of React2Shell produced the same curve a few weeks earlier. React and Vercel published patches on 3 December 2025, and working proof-of-concept exploits appeared publicly around thirty hours later. Fake proof-of-concepts containing malware surfaced on GitHub during the same window, so the disclosure period carried a second risk for defenders testing their own exposure.

Mass exploitation followed within days of that proof-of-concept appearing. CloudSEK’s TRIAD team recovered nine months of command-and-control logs from an exposed RondoDox botnet server, and the timeline inside them shows scanning for the Next.js flaw beginning on 8 December 2025 and automated botnet deployment starting on 13 December. Operators logged more than forty repeat attacks against the same vulnerability across six days, dropping cryptominers and Mirai variants onto the servers they reached.

Those same logs record the group working through Struts2, Drupal, WordPress plugins, WebLogic, and consumer routers over the preceding nine months, escalating from sporadic manual testing in March 2025 to hourly automated deployment by December. React2Shell entered an existing mass-exploitation pipeline rather than triggering a bespoke campaign, which is the pattern that now follows any critical RCE disclosure.

Older flaws keep earning attackers results alongside the new ones. The same honeypot captured sustained attacks against WebLogic flaws disclosed in 2017 and 2020, including CVE-2017-10271, CVE-2020-2551, and CVE-2020-14882. CloudSEK’s conclusion was that attackers rely on a small set of highly effective, simple-to-exploit vulnerabilities rather than continuously seeking new ones, which means an unpatched server stays a target for years rather than weeks.

Notable Remote Code Execution Vulnerabilities

Each incident below turned a single RCE flaw into large-scale compromise, and each one changed how the affected technology gets deployed afterwards.

Recent entries in that list show how fast this picture moves. React2Shell was disclosed with a maximum CVSS rating of 10.0 in December 2025, affecting React 19.x and Next.js 15.x and 16.x applications using the App Router, and CISA added it to the Known Exploited Vulnerabilities catalog within two days. CVE-2026-21962 reached the same catalog after confirmed exploitation, including use by a China-linked group targeting infrastructure across more than a hundred countries.

Both cases point to a dependency problem rather than a coding problem. Organizations running affected versions did not always know the vulnerable component was present, because it arrived as a transitive dependency inside something else. Response therefore starts with inventory rather than with patching.

How to Detect RCE Attacks

Detection depends on watching behavior rather than matching payloads, because a successful exploit runs code through a legitimate process. Five signal sources carry most of the value.

• Process lineage on application hosts. A web server or application server spawning a shell, scripting host, or command interpreter is abnormal in almost every environment and is the clearest single indicator.
• Outbound connections from server processes. Application servers rarely initiate connections to unfamiliar external addresses. Traffic of that kind after a suspicious request suggests a payload retrieval or command-and-control callback.
• Application and web server logs. Unusual request parameters, malformed headers, repeated failures against a single endpoint, and requests to paths the application does not expose all warrant investigation.
• File system changes in web-accessible directories. New files appearing where the server can execute them is the standard signature of web shell installation following exploitation.
• Endpoint detection telemetry. EDR tooling flags unauthorized process execution, privilege escalation attempts, and dropped binaries, which catches the post-exploitation stage even when the initial request went unnoticed.

Network intrusion detection adds coverage for known exploit patterns and misses novel ones by design. Treating it as one layer rather than the primary control keeps expectations aligned with what signature matching can deliver.

How to Prevent RCE Attacks

Prevention works on two fronts: closing the flaws that allow execution, and limiting what execution achieves when a flaw is missed. The controls below run in rough order of impact.

1. Patch internet-facing systems on a schedule measured in days, not quarters, and prioritize anything listed in the CISA Known Exploited Vulnerabilities catalog regardless of its CVSS score.
2. Maintain a software bill of materials so a newly disclosed library flaw can be traced to affected systems in minutes rather than through a manual audit.
3. Validate and encode untrusted input at every boundary, and avoid passing user-supplied data into interpreters, shells, or evaluation functions at all.
4. Treat deserialization of untrusted data as unsafe by default, using allowlists of permitted types or data formats that carry no executable semantics.
5. Run applications with least privilege, so a compromised process cannot reach the operating system, adjacent services, or credential stores.
6. Remove administrative consoles and management interfaces from public networks, placing them behind VPN or identity-aware access controls.
7. Deploy a web application firewall as a compensating control that buys time between disclosure and patching, rather than as a substitute for the patch.
8. Segment networks so that code execution on one host does not grant reachability to backup infrastructure, domain controllers, or database servers.

Getting prioritization right matters more than covering every finding. Published severity scores describe technical impact and say nothing about whether a given flaw is reachable in a specific environment, which is the question a security threat assessment answers. An internet-facing service running a vulnerable library warrants emergency action, while the same library on an isolated internal host rarely does.

What Are Real-World Examples of RCE Attacks?

Remote Code Execution attacks have caused some of the most serious security incidents in recent years. These examples show how a single vulnerability can give attackers remote control over systems.

Log4Shell (Apache Log4j)

Log4Shell was a Remote Code Execution vulnerability found in the Apache Log4j logging library. Attackers could trigger it by sending a specially crafted message, which caused vulnerable applications to run malicious code.

Because Log4j is used in many Java applications, this flaw affected thousands of systems worldwide. Attackers used it to install malware and ransomware.

Microsoft Exchange Server

Several Microsoft Exchange Server vulnerabilities allowed attackers to execute code remotely on email servers. Once exploited, attackers could install web shells to maintain access.

This made it possible to read emails, steal data, and move deeper into company networks. Many organizations were affected before patches were applied.

WannaCry Ransomware

The WannaCry attack used a Remote Code Execution flaw in the Windows SMB service. This allowed the ransomware to spread automatically between unpatched computers.

No user action was required, which made the attack spread extremely fast. Entire networks were locked down within hours.

Vulnerable Web Applications

Remote Code Execution vulnerabilities are also common in web applications and content management systems. Attackers exploit these flaws to run commands on web servers or upload malicious files.

These attacks are often used as a starting point for data theft, malware installation, or further system compromise.

‍

RCE Compared With Other Vulnerability Classes

Severity comparisons make more sense once the level of access each class grants is set side by side.

Chaining is common, which is why these categories overlap in real incidents. An authentication bypass that exposes an administrative console, followed by a deserialization flaw in that console, produces RCE from two lower-severity findings. Ransomware operators use exactly this pattern, and initial access through an unpatched internet-facing service remains one of the most reliable entry points for ransomware-as-a-service affiliates.

Reducing RCE Exposure with External Attack Surface Visibility

Patching cannot begin until someone knows the vulnerable system exists. Forgotten staging servers, inherited infrastructure, and services stood up outside change control are the assets that stay unpatched longest, and they are invisible to scanners pointed only at documented inventory. CloudSEK BeVigil fingerprints an organization’s internet-facing estate and scans it continuously across web applications, mobile applications, APIs, cloud, CVE, DNS, SSL, and network surfaces.

Exposure data answers the reachability question that severity scores leave open. Knowing which vulnerable services are actually exposed turns a long CVE list into a short list of systems that need attention today, which is the practical output of external attack surface management. CloudSEK Threat Intelligence adds the other half by tracking which CVEs attackers are exploiting now, so prioritization reflects observed activity rather than theoretical severity.

Detection and remediation stay with the existing stack. WAFs, EDR tooling, and patch management do the enforcement work, and external visibility contributes the inventory and exploitation context those systems cannot generate on their own.

Frequently Asked Questions

Is remote code execution always a critical vulnerability?

Not always. Severity depends on whether authentication is required, what privileges the process holds, and whether the affected service is reachable from untrusted networks.

Can a web application firewall stop RCE attacks?

It can block known exploit patterns and buys time before patching. Novel payloads and obfuscated variants get through, so a WAF works as a compensating control rather than a fix.

What is the difference between RCE and a zero-day?

RCE describes what a flaw allows. A zero-day describes when it is exploited, meaning before a patch exists. A vulnerability can be one, both, or neither.

Do memory-safe languages eliminate RCE risk?

No. They remove buffer overflow and use-after-free classes, and deserialization flaws, command injection, and template injection all remain possible in Rust, Go, Java, and Python.

How do attackers find vulnerable systems to exploit?

Through automated internet-wide scanning and search engines that index exposed services. Published exploit code is applied at scale against every reachable instance rather than selected targets.

Does exploiting RCE require user interaction?

Rarely. Most RCE flaws are triggered by a network request the attacker sends directly, which is what separates them from phishing-dependent attacks and makes automated exploitation practical.

Conclusion

Remote code execution keeps its place at the top of severity scales because it removes every intermediate step an attacker would otherwise need. There is no credential to steal, no user to deceive, and no lateral movement required before the attacker holds a position inside the environment.

What has changed is the timeline. Honeypot evidence shows exploitation beginning the day exploit code becomes public, and working proofs-of-concept for React2Shell circulated roughly thirty hours after disclosure. Response capability has to match that pace, which means knowing what is exposed before the advisory lands, tracking which flaws attackers are actually using, and running applications with privileges narrow enough that execution alone does not equal compromise.