Understanding PHP2Shell: Everything you need to know about CVE-2026-109618 & CVE-2026-109619

PHP remains one of the most widely deployed server-side languages on the web. Estimates suggest it powers close to 70% of all websites, from small personal blogs to large-scale government services, banking platforms, and e-commerce applications. With such huge presence, any vulnerability in PHP's core engine carries the potential to affect a significant portion of the web.

On October 21st, 2026, the PHP project released emergency patches for two critical remote code execution (RCE) vulnerabilities, collectively documented as PHP2Shell. These vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, are deeply embedded within PHP's memory management and error handling subsystems, meaning nearly every PHP request touches the vulnerable code. With a CVSS score of 9.2, the severity of these findings cannot be overstated.

In this article, we'll break down the four known attack chains, cover what you should do to detect and protect your infrastructure, and explore how CrowdRecon can help your organization stay ahead of threats like these.

Let's dive in!

Overview of CVE-2026-109618 & CVE-2026-109619

Both CVEs share a common theme, they exploit the way PHP handles internal state during error conditions. When things go wrong at exactly the wrong moment, PHP can leave behind corrupted or stale data structures that a subsequent request, or even the same request, can abuse for full remote code execution. Let's take a look at each of the four confirmed attack chains.

Attack chain 1: Out-of-memory (OOM) corruption via Apache mod_php (CVE-2026-109618)

This is the most severe of the four chains because it requires no authentication and can be triggered before any application code runs.

PHP employs longjmp() to exit when an out-of-memory (OOM) error occurs. When an attacker sends a crafted multipart POST that exhausts memory_limit during request startup, the longjmp() bailout exits the current context while request memory is still in a partially initialized state. The important detail here is that Apache's mod_php unconditionally invokes the request shutdown procedure, even when request startup has failed. Shutdown then reads and operates on this invalid state, giving the attacker a path to controlled code execution. The security firm Calif, via OpenAI's Patch the Planet program, demonstrated full unconditional RCE with default PHP settings. This attack chain does, however, rely on the target running on Apache with the mod_php server module enabled.

Attack chain 2: Stale global state via fatal-error backtrace (CVE-2026-109619)

On PHP 8.5, the fatal_error_backtraces feature stores backtrace state owned by the current request in a global that the worker retains. The official advisory confirms that resetting this global state is always missed during shutdown. When a fatal error (including OOM) occurs, the request heap is freed while the backtrace global still points to the now-freed memory. A diagnostic on a subsequent request, such as a warning raised while applying INI settings, reaches the stale value before normal request initialization has a chance to reset it, resulting in a use-after-free.

It is essential to note that the consumer does not need to be fatal, displayed, or logged. Even a deprecation warning from a configured INI setting (such as auto_detect_line_endings=1 or legacy assert.* settings) is sufficient to trigger access to the stale state.

Attack chain 3: Stale session state via upload progress (CVE-2026-109619)

This chain exploits the session.upload_progress lifecycle. An upload can initialize request-owned session and decoding state before normal module initialization. If an out-of-memory (OOM) or another fatal error occurs after that state has been published, PHP frees the request heap while persistent session or decoder globals still refer to it. A later upload progress operation on the next request reaches those globals before ordinary initialization and treats them as valid state, giving the attacker a use-after-free.

This chain is confirmed on both Apache mod_php and PHP-FPM. On mod_php, both the producing operation and the fatal error can occur during multipart startup. On FPM, the producing operation occurs during application execution after a successful startup (since FPM terminates the child when startup itself fails), and session upload progress serves as the early consumer on the next request.

Attack chain 4: Memory disclosure (CVE-2026-109618)

Beyond code execution, Wiz researchers demonstrated that the same OOM corruption mechanism can be used to read arbitrary server memory. This means an attacker could extract sensitive data from the PHP worker's memory space, including session tokens, database credentials, API keys, and other secrets that may have been processed by previous requests. This attack chain is particularly dangerous because it operates below the application layer and can be carried out while leaving minimal traces in standard application logs. In practice, this memory disclosure can also be accompanied by the first attack chain, as the leaked data reveals memory layout information that makes the OOM-corruption RCE more reliable.

Mitigation advisory

According to the PHP group, the single most important action you can take right now is to update. The PHP project has released patched versions across all supported branches:

If you cannot update immediately to the latest version, the PHP Group has released a list of actions you can take immediately to reduce exposure to PHP2Shell significantly. However, it's worth noting that updating remains crucial.

Web Application Firewalls

If you are running a firewall infront of your assets, it's possible to apply firewall rules to block potential attempts at exploitation. Web Application Firewall vendors such as Akamai, Cloudflare, and F5 have recently published mitigation guides to deter PHP2Shell attacks.

Some firewall rules have been applied automatically, while others may require additional configuration to prevent possibly rejecting non-malicious client requests.

Additionally, ensure all your entrypoints are behind your WAF, failure to correctly set up your firewall can result in exposure. Learn more about how server origin leaks occur, and most importantly, what attackers can do once they can directly reach your origin server.

Advice to organizations

Our advice is that if you have an asset inventory, talk to your engineering team and check what PHP applications are internet-facing, and find out your potentially impacted assets. Verify their version numbers. If you make use of managed services, reach out to your suppliers to check that they are patching and on top of this.

Look at what you are hosting as well, and as general advice, keep an eye on the news. The reason for keeping up to date with the media is that when things like this happen, a day later a patch or an updated exploit usually comes out, so you need to keep on top of patching for at least a week/couple of weeks. Patching is not a one-and-done task, so make sure your team is aware of that.

3 Immediate steps you can take today

1. Understand your inventory and what you are hosting.

2. Ask your engineering team to check for exposed hosts running one of PHP's affected versions.

3. Updating to the latest version is the recommended approach according to the official advisory notice. When patching is not available, you may resort to the additional measures the PHP Group has recommended and/or apply Web Application Firewall rules to deter PHP2Shell attacks. Try to keep up with the latest developments, as bypasses and other mutations are likely to surface in the upcoming days.

Long-term actions you can take:

We recommend reviewing the patched versions for your branch and planning your update as soon as possible. If you're hosting products in a fully managed environment, stay in contact with your vendor to confirm that patches have been applied.

Organizations can also leverage CrowdRecon, which provides real-world attack surface intelligence gathered by Intigriti’s global researcher community. With access to this asset data, teams can identify shadow IT and other overlooked targets, enabling them to mitigate potential threats quickly.

Should organizations pay bug bounties for zero-days?

Most Intigriti customers have a 14-day cooldown period for zero-day vulnerabilities. This means that submissions sent through the platform during this timeframe do not automatically qualify for a bounty. It allows your team to assess the situation internally before including the issue in your bug bounty program. Researchers are still able to submit the vulnerability to your program and may receive a bonus at your discretion.

Not running a vulnerability disclosure program yet?

If you're not set up with a vulnerability disclosure program (VDP), schedule a conversation with our security experts today to discuss how you can transition from occasional spot-check testing to continuous testing.

In the meantime, we recommend you set up a secure method for security researchers to reach out to you and responsibly disclose their findings. The Security.txt initiative is the most straightforward approach to setting up a responsible disclosure.

Conclusion

The PHP2Shell vulnerabilities serve as a stark reminder that even the most foundational and widely deployed technologies are not immune to critical security flaws. With multiple independent RCE chains affecting the core PHP engine across 14 years of releases, the potential impact spans millions of websites and services worldwide.

In this article, we've covered the four confirmed attack chains and what steps you should take to protect your infrastructure. As a customer of Intigriti, you are always welcome to reach out to your dedicated CSM for any questions or concerns.