Post cover image
Generated by Gemini

November 2, 2026

PHP2SHELL, How One Vulnerability Disclosure Shook The Whole World

Table of Content

By Abdülselam İsmail

6 min read

Table of Content

Introduction

At the end of October with disclosure of a few critical vulnerabilities the whole IT world went into chaos. What stood out the most were two particular PHP vulnerabilities we call php2shell now. In this article I'm going to talk about what are these vulnerabilities, who is affected by them and how to secure yourself.

None

What is PHP2SHELL?

On October 21 14:00 UTC, PHP released security patch for two critical vulnerabilities identified as CVE-2026-109618 and CVE-2026-109619both rated CVSSv4 9.2. These vulnerabilities allowed for unauthenticated remote code execution(RCE) with the privileges of the web server process. The vulnerability was leaked a day before and a working Proof-of-Concepts (PoC) spread after the release.

First Reports

In 2024, the PHP Foundation organized the first external security audit of PHP in years, carried out by Quarkslab with funding from the Sovereign Tech Agency. While fixing one of the issues the audit found, a core developer spotted the first signs of the out-of-memory problem that later became CVE-2026–109618. Back then, nobody had found a concrete way to exploit it, and other bugs with clearer impact took priority. Fixing it was also hard. Every approach the PHP security team tried came with trade-offs, such as breaking backward compatibility, opening new denial-of-service risks, or forcing changes across many third-party extensions. The team works by consensus and had few engineers who knew the engine that deeply, so work on a fix stalled and restarted for months. The PHP Foundation later called this delay a "structural failure."

Everything changed on August 11, 2026, when Calif reported a remote code execution vulnerability stemming from the same underlying out-of-memory issue. Calif subsequently reported a second vulnerability on August 21.

Meanwhile, Wiz Research independently discovered an unauthenticated RCE vector on August 19. Its researchers confirmed successful exploitation against Drupal on August 20 and WordPress on August 21, before privately reporting their findings to the PHP security team on August 24.

OpenAI also reported additional exploitation vectors on September 18. Together, these independent discoveries and reports helped establish the full impact of the vulnerabilities, prompting the PHP Foundation to coordinate fixes across affected PHP branches.

Then, on October 17, Amazon Threat Intelligence detected exploitation attempts against these flaws on its AWS MadPot honeypot network, four days before disclosure. Time was running short. The PHP team had planned to release the security patch on October 22, 2026, but just two days before that, something unexpected happened.

Unexpected Chain of Events

On October 20, at approximately 15:00 UTC, an anonymous user posted the two embargoed CVE identifiers on the Hacker News forum, alongside an incorrect release time and an inflated CVSS 10.0 rumor. Although moderators quickly removed the post, screenshots had already begun circulating across security channels. At this stage, no technical details had been disclosed.

In response, the PHP security team published an official advance notice (php.announce/509) at 19:30 UTC, moving the release from October 22 to October 21 at 14:00 UTC. The notice also reserved the right to release the patches earlier if technical details became publicly available.

Around 20:00 UTC, following the initial leak and the advance notice, researchers at Calif accidentally published a PoC video demonstrating their exploit against several targets. Although the video was subsequently removed, copies circulated on social media, revealing additional technical details and accelerating the development of public PoCs.

None

At 02:29 UTC on October 21, an archive containing leaked vulnerability details was uploaded to VirusTotal. Then, at 07:41 UTC, approximately six hours before the scheduled release, container vendor Chainguard shipped patched PHP container images ahead of the official disclosure. The PHP Foundation criticized this as an embargo breach, arguing that the early availability of patched binaries gave attackers an opportunity to reverse-engineer the fixes through binary diffing before the official patches were released.

In summary, the PHP team was attempting to maintain a coordinated disclosure schedule initially planned for October 22, 2026. However, a series of events — including an initial CVE identifier leak, an accidentally published researcher PoC, the public disclosure of technical details, and an early vendor patch release — ultimately undermined the embargo.

Who is Affected?

The PHP project considers all PHP installations serving web requests potentially affected, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. However, exploitability and prerequisites vary depending on the SAPI, configuration and worker lifecycle.

According to Calif Research, the researchers successfully demonstrated unauthenticated remote code execution against several widely used PHP applications, including:

- WordPress 7.1.2
- Drupal 11.4.3
- Joomla 6.1.4
- MediaWiki 1.46.2
- Roundcube 1.7.4
- Magento 2.4.9
- phpMyAdmin 5.2.3
- Nextcloud 35.0.1
- Laravel 13.11
- Symfony 8.1
- WHMCS

These demonstrations highlight the potential impact across a wide range of PHP-based applications. However, the vulnerabilities exist within the PHP runtime itself, rather than in the applications listed above. Consequently, any web application running on an unpatched and affected PHP version may be exposed, regardless of the framework or CMS it uses. The exact exploitation conditions depend on the PHP version, SAPI, configuration and worker lifecycle.

What to Do If You are Affected?

If you are running a vulnerable version of PHP, you should update to a patched release as soon as possible. The PHP project has released security fixes for the following supported branches:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

Make sure to update all PHP environments, including production servers, containers, staging environments and deployment pipelines

What if you are running an older PHP version?

PHP 8.1 and earlier have reached end of life and do not receive official security releases from the PHP project. If you are running those versions you can do following:

  • Upgrade: Isolate the affected application and plan an upgrade to a supported PHP branch, preferably PHP 8.4 or 8.5, after verifying application compatibility.
  • Vendor backports: Check whether your operating system provider or long-term support (LTS) vendor offers patched PHP packages for your current version.
  • Source backports: PHP has published minimal source-level backports for PHP 7.4, 8.0 and 8.1. These are primarily intended for teams capable of building and maintaining PHP from source.

You can also implement temporary mitigation measures using a Web Application Firewall (WAF) or reverse proxy rules to block known malicious requests. However, these measures should not be considered a replacement for applying the security patches.

If an upgrade or security backport is not immediately possible, consider temporarily isolating the affected service or taking it offline until it can be secured.

Check If You Have Been Compromised

According to Bitdefender report you can do following if you think you could have been compromised:

  • Check for Abnormally Huge Requests: Look at your reverse proxy or WAF logs for incoming requests that are several megabytes in size. Since logs typically don't record the full request payload, you must track request size rather than request content to spot the massive, bloated form field names used against CVE-2026-109618 (this indicator does not apply to CVE-2026-109619).
  • Search Error Logs for Startup OOMs and Segfaults: Look for bursts of worker crashes (SIGSEGV / SIGABRT) or Out-of-Memory errors occurring at Unknown on line 0.
  • Audit What Your PHP Workers Have Spawned: Use ps, auditd, or your EDR to check if parent processes like php-fpm, apache2/httpd, lsphp, or frankenphp have spawned child shells (sh, bash, dash), network utilities (curl, wget, nc, socat), or reconnaissance commands (whoami, id, uname).
  • Check For Script Files: Look for new script files in upload, cache and tmp directories.
  • Assume Memory Disclosure & Rotate Secrets: Because CVE-2026-109619 is confirmed to leak in-memory data, if you see signs of probing against an unpatched server, rotate your database credentials, API keys, .env secrets, and active user session keys after patching.

Conclusion

With PHP powering approximately 70% of websites whose server-side programming language is known, the potential impact extends across a significant portion of the web. It doesn't help that during that week other critical vulnerabilities were reported as well urging for immediate remediation. However we still can't relax especially with flood of vulnerabilities not stopping anytime soon. In times like this having good inventory management system as well as strict patch policy is as important as ever.

This article was written by the author with the help of AI for drafting certain passages and improving overall structure.

References

php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ | Tenable® Two critical PHP vulnerabilities could lead to unauthenticated remote code execution. Patches are available for…

PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet | Wiz Blog Core PHP engine flaws enable remote code execution and Heartbleed-style memory disclosure across the web.

PHP2Shell Exploitation Attempt Detected Four Days Before Disclosure Threat intelligence analysts now observe large-scale evidence of exploitation of the two critical PHP vulnerabilities

php2shell: What AI Actually Changed, and What It Didn't The headline says AI found a 22-year-old bug in 2 days. Both numbers are wrong, and the real ones tell a better story…

TechOwl | PHP2Shell: Exploitation Attempts Began Four Days Before the Patch Two critical flaws in PHP's C runtime (CVE-2026-109618 and CVE-2026-109619) allow unauthenticated remote code execution…

Technical Advisory: PHP2Shell Pre-Auth RCE (CVE-2026-109618, CVE-2026-109619) CRITICAL] | CVSS v4.

PHP2Shell by Calif Research A tale of two PHP remote vulnerabilities

PHP2Shell on end of life PHP: options for 5.x, 7.x, 8.0 and 8.1 Stuck on PHP 5.x, 7.x, 8.0 or 8.1 after PHP2Shell? Use a vendor backport, build php.net's source backport or isolate…

Usage Statistics and Market Share of PHP for Websites, October 2026 How many websites are using PHP

https://watchtowr.com/intelligence/php-remote-code-execution-php2shell

https://blog.virustotal.com/2026/10/sizing-php-exposure-window-for-cve-2026.html