Remote Code Execution (RCE)

Back to glossary

What Is Remote Code Execution?

Remote code execution (RCE) is a class of vulnerability that allows an attacker to run arbitrary code on a target system from a remote location, without requiring physical access or prior authentication. RCE vulnerabilities give attackers the ability to execute commands, install malware, exfiltrate data, or pivot deeper into an organization’s infrastructure.

RCE ranks among the most severe code execution vulnerabilities in application security. A single exploitable RCE flaw can grant an attacker full control of a server, container, or cloud workload, making it a top priority for security teams conducting vulnerability assessments and penetration testing across their application portfolios.

How RCE Attacks Work

A remote code execution attack typically follows a predictable sequence. The attacker identifies an input vector that accepts external data, such as an HTTP request parameter, file upload, or deserialization endpoint. They craft a payload that exploits a flaw in how the application processes that input. When the server handles the malicious input, it executes the attacker’s code in the context of the application or underlying operating system.

The key factor of an RCE vulnerability is that the attacker does not need local access. The exploit travels over the network, often through standard protocols like HTTP, SMTP, or DNS. Some RCE attacks require no authentication at all, which is what makes them particularly dangerous in internet-facing applications.

Successful RCE often leads to full system compromise. Once an attacker achieves code execution, they can install backdoors, escalate privileges, move laterally across the network, or deploy ransomware.

Common Root Causes of RCE Vulnerabilities

Several coding and design patterns consistently lead to RCE flaws. Understanding these root causes helps development teams prevent them at the source.

  • Unsafe deserialization: Applications that deserialize untrusted data without validation can allow attackers to inject objects that execute arbitrary code during the deserialization process. This affects languages like Java, PHP, Python, and .NET.
  • Command injection: When user input is concatenated directly into operating system commands without sanitization, attackers can append their own commands. Shell metacharacters like semicolons, pipes, and backticks enable command chaining.
  • Server-side template injection: Template engines that evaluate user-supplied expressions can be abused to execute code on the server. Frameworks like Jinja2, Freemarker, and Twig are common targets.
  • Unpatched dependencies: Third-party libraries and frameworks with known RCE flaws remain a leading attack vector. Applications that fail to update vulnerable dependencies inherit those risks.
  • Insecure file uploads: Applications that allow file uploads without proper content validation can be tricked into executing uploaded scripts or binaries on the server.

Notable Real-World RCE Examples

Several high-profile incidents demonstrate the scale of impact from remote code execution examples in widely deployed software.

Log4Shell (CVE-2021-44228) exploited a flaw in the Apache Log4j logging library that allowed RCE exploits through crafted log messages. The vulnerability affected millions of Java applications worldwide and remains one of the most widely known exploited vulnerabilities in CISA’s catalog.

Spring4Shell (CVE-2022-22965) targeted the Spring Framework’s data binding mechanism, enabling attackers to achieve remote code execution on Tomcat-based deployments through crafted HTTP requests. It highlighted the risk of complex framework internals that expose implicit execution paths.

The MOVEit Transfer vulnerability (CVE-2023-34362) exploited a SQL injection flaw to achieve RCE in a widely used file transfer platform. The Cl0p ransomware group used it to exfiltrate data from hundreds of organizations in a single campaign.

How to Detect and Prevent Remote Code Execution Vulnerabilities

Effective defense against RCE requires layered controls across the SDLC, from code review through runtime protections.

  • Static analysis: Static application security testing tools identify insecure deserialization, command injection patterns, and template injection sinks during code review, before the application reaches production.
  • Dependency management: Maintain an up-to-date software bill of materials and monitor dependencies for disclosed RCE flaws. Automate patching where possible.
  • Input validation and sandboxing: Validate all external inputs against strict allowlists. Where command execution is necessary, use parameterized APIs instead of shell invocations and sandbox processes with minimal privileges.
  • Runtime protections: Web application firewalls, runtime application self-protection (RASP), and network segmentation limit the blast radius if an RCE vulnerability is exploited.

Vulnerability prioritization is critical for RCE remediation. Not every RCE finding carries equal risk. Prioritize based on exploitability, reachability, and the business impact of the affected application.

FAQs

What is the difference between remote code execution and local privilege escalation?

Remote code execution allows an attacker to run code from a remote location over a network. Local privilege escalation requires existing access to the system and elevates the attacker’s permissions from that starting point.

Which programming languages or frameworks are most commonly affected by RCE?

Java, PHP, Python, and .NET are frequently targeted due to deserialization patterns, template engines, and dynamic evaluation features that create execution paths from untrusted input.

Can RCE vulnerabilities exist in internal-only or air-gapped applications?

Yes. Internal applications can be exploited through supply chain attacks, compromised dependencies, or lateral movement from an already-breached system within the network.

How quickly do attackers typically exploit a publicly disclosed RCE vulnerability?

Exploitation often begins within hours of public disclosure. High-severity RCE flaws in widely deployed software see mass scanning and exploitation attempts within the first day.

What CVSS score range do most critical RCE vulnerabilities fall into?

Critical RCE vulnerabilities typically receive CVSS scores between 9.0 and 10.0, reflecting the potential for full system compromise, remote exploitation, and minimal required attacker privileges.

Back to glossary
See Apiiro in action
Meet with our team of application security experts and learn how Apiiro is transforming the way modern applications and software supply chains are secured. Supporting the world’s brightest application security and development teams: