Updated October 22, 2026
On 21 October 2026, PHP shipped an out-of-cycle security release for two remote code execution flaws that its security team rated 9.2 on CVSS v4.0 (PHP announcement). Only weeks earlier, a use-after-free bug in Redis put every exposed instance at risk. Different languages and root causes can lead to the same outcome: an attacker running their own code on a server they do not own, with the ability to execute arbitrary commands and potentially take over the whole system.
It’s one of those vulnerabilities that attackers are quick to take advantage of. Once they can run code on a system they don’t own, the situation can escalate quickly. Let’s see what Remote Code Execution involves and how to prevent it.
Understanding remote code execution
Remote Code Execution (RCE) allows attackers to run their own code on someone else’s system. When this happens, the attacker can typically do anything the system itself can do. That may mean accessing sensitive data, creating new privileged accounts, deploying ransomware, or using the compromised machine to move deeper into the network.
It’s important to understand that RCE is usually the result of another underlying vulnerability, not a standalone flaw. Issues such as command injection, insecure deserialization, misconfigurations, or even weaknesses in third‑party components can all create the conditions that make remote code execution possible.
Supply chain visibility is really crucial because if a dependency contains an RCE flaw, every application using it inherits that risk and could be exposed to a supply chain attack.
The reason RCE is so serious is the control it grants, as the attacker no longer needs to authenticate or guess passwords. In fact, RCE vulnerabilities often receive some of the highest CVSS scores.
Remote code execution does not require physical access to the target system, making it especially dangerous. All attackers need is a network connection and a vulnerable system. The attacker’s ability to exploit these vulnerabilities determines the extent of damage they can cause, including bypassing security measures and escalating privileges.
Types of remote code execution vulnerabilities
Most remote code execution attacks exploit flaws elsewhere in an application. These underlying issues give attackers the opportunity to execute arbitrary code if exploited.
Remote Code Execution vulnerabilities have several forms, each having its own challenges for defenders and opportunities for attackers. Knowing the different types of RCE vulnerabilities is essential for developing robust security measures and reducing the risk of remote code execution attacks.
Here are some of the most frequent sources of RCE:
Injection vulnerabilities
RCE often starts with code injection, where untrusted input reaches a part of the system that executes commands. A typical example is command injection, where user input goes directly to a system shell. Without proper validation, attackers can run arbitrary commands on the server.
Also, XSS is basically unauthorized code execution in the victim’s browser. Other types of vulnerabilities that can lead to code execution include Server-Side Template Injection (SSTI) and even SQL injection. Thinking of RCE this way makes it easier to find insecure patterns and prevent security problems.
Another factor to consider is the use of embedded interpreters (e.g., Python, Lua). Embedding a scripting engine lets applications be flexible, but it also opens a direct path to RCE if untrusted input reaches the interpreter.
Deserialization vulnerabilities
Some web applications serialize data to store or transfer it, then deserialize it later. If the data being deserialized can be controlled or modified by an attacker, they can craft payloads that execute code during the deserialization process. This can lead to complete control of the application or server.
Buffer overflows
If a program writes more data into memory than it should, it can overwrite nearby memory structures. With careful manipulation, attackers use this to inject and run arbitrary code. This is found more in native and legacy software; however, it remains a vector.
Why RCE leads to serious incidents
When an attacker gains the ability to execute commands remotely, they can:
-
Deploy malware, including ransomware, to further compromise the environment.
-
Steal or read sensitive information.
-
Install backdoors or malware for persistent access.
-
Move laterally to other systems in the network.
-
Disable security tools or modify system configurations.
The impact can be huge. Since March 2023, the Akira ransomware group has exploited RCE vulnerabilities to affect over 250 organizations. The group has actively targeted critical RCE flaws in enterprise systems, demonstrating how quickly threat actors can weaponize them.
Many major breaches originated from a single RCE vulnerability on an internal or externally exposed service. Even strong network segmentation or perimeter controls can fail if one internal service has a flaw that allows remote code execution.
Learning from Redis
As mentioned earlier, a recent Redis attack shows how RCE vulnerabilities can hide in plain sight. Last month, researchers disclosed RediShell, a use-after-free vulnerability in Redis’s Lua scripting engine that had existed undetected for 13 years.
The flaw allows authenticated attackers to send a specially crafted Lua script that escapes the Redis environment and run any command they want on the host machine. This means complete control, not just over Redis data, but over the entire server.
From there, the attack follows a familiar RCE pattern, including stealing credentials, deploying malware, exfiltrating data, or moving laterally across the network. It might only start as database access, but could become a complete system compromise.
Learning from PHP: the PHP2shell flaws
In October 2026, PHP’s security team pre-announced two critical vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, and nicknamed PHP2shell by researchers. Both allow remote code execution. The fixes landed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 (PHP changelog).
The flaws sit in the interpreter’s own request handling, not in any application code. The first, CVE-2026-109618, sits in out-of-memory handling. When a request pushes PHP out of memory, cleanup can run while internal request data is only half set up, and treat that half-built data as valid. The second, CVE-2026-109619, is state belonging to one request that survives after its memory is freed, so the next request on the same worker runs on stale data before it is reset. In both cases, the attacker shapes a request so that memory PHP believes is clean is theirs to control (PHP security advisory).
No login is needed and no unusual configuration. Every setup that serves web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php the most exposed. The demonstrated exploit fires before a single line of application code runs.
Two things make this case worth studying. First, the scope. Older PHP branches are end of life and receive no fixes, and on 20 October about 884,000 internet-facing hosts still reported PHP 8.1 or older in their HTTP banner, 59% of all hosts reporting a version (Mallory, Shodan data). A vulnerability in a runtime is a vulnerability in every application built on it, patched or not.
Second, the speed. When CVE-2024-4577, an earlier PHP RCE flaw in CGI mode on Windows, became public in June 2024, exploit attempts hit honeypots within 24 hours (Akamai). The window between disclosure and attack is measured in hours, which is why the habits in the next section matter more than any single patch.
For developers, the lesson is the same as with Redis. The bug is in the runtime, so secure application code cannot prevent it, but it decides how much damage follows. PHP’s own mitigation list ends with a task for developers: fix fatal errors and execution timeouts an attacker can trigger, including callbacks, upload handling, and cleanup, because a crash an attacker controls is now a route to the second flaw. SecureFlag’s PHP labs train exactly that: handling untrusted input and failure paths so your code never breaks in a way an attacker can use. We break the flaws down in how the PHP2shell flaws work.
How to reduce the risk of remote code execution
While no single step eliminates RCE risk entirely, several practices can significantly reduce it.
-
Always validate and sanitize user input to stop code injection and other risks.
-
Avoid running system commands directly whenever possible.
-
Limit or disable dynamic module loading to reduce attack surfaces.
-
Keep internal services and admin interfaces hidden from external access.
-
Keep an inventory of your runtimes, not just your dependencies, including the versions bundled in appliances and control panels, so you can upgrade within hours when the language itself is the vulnerability.
-
Apply least-privilege principles for services, containers, and cloud roles.
-
Conduct regular code reviews and hands-on security testing.
-
Follow secure coding best practices, including code analysis.
Even small changes can prevent attackers from gaining access, such as adjusting default configurations or removing unnecessary service exposure.
Learn to prevent RCE with SecureFlag
Remote code execution is best understood through real-world practice rather than theory alone. SecureFlag provides hands-on secure coding training for developers to detect and prevent security vulnerabilities, including RCE. The labs cover the languages behind the incidents in this guide, including PHP and Lua, so the exercises match the code your team ships.
This includes training labs covering scenarios such as:
-
Identifying and fixing RCE vulnerabilities in code.
-
Cloud and container security practices.
-
Secure Redis configuration and data protection.
Working in realistic, guided environments, teams experience how attacks unfold and what effective prevention looks like in practice, reducing risk before issues reach production.
If your organization wants to strengthen its security capabilities and reduce the likelihood of vulnerabilities, such as Remote Code Execution, SecureFlag can help.
