PHP2Shell: Inside the Critical PHP RCE That Put 70% of the Web on Patch Alert

Posted on 26th Oct 2026 11:03:58 in Artificial Intelligence, Machine Learning

Tagged as: PHP2Shell, PHP Security, CVE-2026-109618, WordPress Security, AI Security, Patch Management

On the morning of October 21, 2026, websites across Europe started going dark on purpose. Tweakers, one of the Netherlands' largest tech publications, pulled its site. So did the Dutch House of Representatives, the national cyber security centre, and a school platform used by thousands of students. Banks, retailers, gaming sites, hospitals and government agencies in several countries took internet-facing systems offline as a precaution.

The cause was not a ransomware outbreak or a cloud outage. It was a pair of bugs inside PHP, the open-source scripting language that quietly powers an estimated 70% of the web-facing internet. The flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, allow an unauthenticated attacker to run their own code on a vulnerable server. No password. No phishing link. No file for a user to open. The US Cybersecurity and Infrastructure Security Agency rated the situation serious enough to issue an emergency alert telling organisations to patch immediately.

What makes PHP2Shell more than another emergency patch notice is the story of how it was found. The vulnerable code had been sitting in PHP since version 5.4.0, released in 2012. Human auditors had brushed past it. It took a security firm working inside an OpenAI vulnerability-hunting programme, using a frontier model as a research assistant, to connect the dots and turn a fourteen-year-old loose end into a working attack.

What Actually Broke, in Plain English

Both bugs belong to a category called use-after-free. In normal operation, PHP allocates memory to handle a web request, then frees it when the request finishes. The flaws appear when something goes wrong mid-request, specifically when a request hits PHP's memory_limit and the engine throws a fatal error to abort it.

That abort is not a clean shutdown. It is a longjmp, an abrupt jump out of native C code that skips the normal cleanup steps. According to the PHP Foundation's post-mortem, the result is internal state that still points at memory which has already been freed. A later request handled by the same worker process can then read that stale memory as if it were live data, or branch on values an attacker controls. Palo Alto Networks' Unit 42 summarised CVE-2026-109618 as memory left uninitialised by improper control flow management, and CVE-2026-109619 as global memory pointing at freed regions that later requests can read or branch on.

The practical consequence is remote code execution: an attacker can plant a web shell, move laterally, or establish a foothold that survives reboots. CVE-2026-109618 carries a second sting. Security firm Sansec notes that PHP's upload-progress handler can hand freed worker memory back to the client inside a PHPSESSID response cookie. That memory can contain passwords, session tokens, API keys, and TLS private keys belonging to other requests. The handler runs before application code, so the leak works even on sites that never call session_start().

The trigger in both cases is a malformed multipart/form-data upload, the same format a browser uses when someone submits a form with a file attached. PHP parses that body before your application does anything, which is why the flaw cannot be fixed with a WordPress plugin or a CMS update.

Why 70% of the Web Was in Scope

PHP is not glamorous, but it is everywhere. WordPress runs on it, and so do Drupal, Joomla, MediaWiki, Magento, WooCommerce, Shopware, Laravel, Symfony and Nextcloud. Calif, the security firm that found the flaws, confirmed pre-authentication code execution against 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 and WHMCS.

PHP also lives outside web servers. It ships inside developer tooling, command-line utilities, routers, storage appliances and enterprise security devices such as firewalls and VPNs. That is why CISA's guidance warns that organisations may not be able to see PHP in a simple software inventory: the runtime is often a component buried inside something else.

For a small business in India running a WordPress site, the exposure is direct. Your hosting account almost certainly runs PHP. If you are on shared hosting, a managed WordPress plan, or a reseller account, the version of PHP serving your pages is decided by your provider, not by you.

The AI Discovery Angle: Real, but Not Magic

The headline version of this story is simple: AI found a bug that humans missed. The accurate version is more interesting.

In OpenAI's account, researcher Calif identified a critical flaw using GPT-5.6 Sol as part of the company's Patch the Planet initiative, while cloud security firm Wiz independently discovered and reported both vulnerabilities. The PHP Foundation's timeline adds detail: Calif began auditing PHP on July 30, 2026, reported its first bug on August 11, shared a working proof of concept on August 14, and reported the second flaw on August 21. OpenAI independently reported the same root cause and further attack vectors on September 18. Wiz reported on August 24. Trail of Bits has since joined the audit effort.

Calif's own write-up pushes back hard on the idea that a prompt can shake loose critical bugs. Lead researcher Ryan Austin wrote that no special harness or access to non-public models was used, and that the work leaned on a background in PHP's exploitation history. His framing: no model is simply capable of unearthing all bugs with simple prompts, at least for now. What models did well was generalise a pattern once a human pointed at the right place. After the first finding, the team had a model turn the pattern into a reusable skill file, which then surfaced a second vulnerability in PHP's session upload-progress code.

The uncomfortable part is that this bug was not unknown. PHP's 2024 external audit, run through OSTIF and Quarkslab with funding from the Sovereign Tech Agency, turned up the first signs of the out-of-memory problem. Exploitation was not proven at the time, so it was not fixed. The PHP Foundation is unusually candid about what happened next, describing the delay as a structural failure caused by the security team's consensus decision process and a lack of resources. Fixing it meant choosing between backward-compatibility breaks, new denial-of-service risk, or changes across a large ecosystem of third-party extensions. Months passed. The right people were occupied. The bug stayed.

A Coordinated Disclosure That Slipped

The embargo did not hold. On October 20 at roughly 15:00 UTC, the two CVE identifiers began circulating on forums and social media, attached to a wrong release time and an inflated CVSS score of 10.0. The real score is 9.2. PHP moved its pre-announcement forward and pulled the release date from October 22 to October 21 at 14:00 UTC.

Then, at 07:41 UTC on release day, more than six hours before the coordinated time, Chainguard published built images containing the fix. Because PHP is open source, the patch itself was now available for inspection by anyone while most of the world was still waiting. Cloudflare logged early exploitation attempts at 07:43 UTC. PHP's maintainers noted a video from one of the reporting firms was mistakenly published around the same time, showing proof-of-concept runs against live targets and accelerating the spread of working exploits.

What the Exploitation Picture Actually Looks Like

This is where several early reports need correcting. On October 23, Unit 42 said it had observed post-compromise activity tied to PHP2Shell, describing an attack against a European government agency. On October 25 it retracted that update, stating it could not confirm that initial access was associated with these CVEs.

Sansec's assessment is that mass exploitation is less likely than first feared. Its researchers found that the public proof-of-concept exploits do not work against a default PHP installation. Most require the target application to already contain a local file inclusion bug, which is itself a severe flaw. Nobody has published the equivalent of a single request that works against any vulnerable server, the way Log4Shell and Shellshock worked. What defenders are seeing so far is large-scale scanning and probing rather than confirmed code execution.

That is not a reason to relax. Palo Alto's Cortex Xpanse counted more than 22.6 million exposed instances potentially vulnerable based on its telemetry. Cloudflare's chief executive reported an exponential rise in exploitation attempts after disclosure. A leaky bug that hands back another user's session cookie is dangerous even when full remote code execution proves finicky, and smaller IT teams with legacy PHP installs will be slow to patch.

What Your Business Should Do This Week

• Find every PHP install. Check your hosting control panel, staging environment, internal tools, and any appliance that runs a web interface. If you cannot inventory it, you cannot patch it.
• Patch to a fixed release. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On shared or managed hosting, open a ticket and ask your provider to confirm the PHP version serving your site, in writing.
• Handle end-of-life PHP deliberately. PHP supports 8.2 and later. If you are on 8.1 or older, PHP publishes no fixed release, though the security team issued source patches and several vendors backported fixes. CISA's advice is blunt: if you cannot update, take the PHP-based system offline until you can.
• Apply temporary mitigations only as a stopgap. Blocking multipart/form-data at nginx or Apache closes the known trigger, at the cost of breaking file uploads, so test a cart or checkout flow afterwards. Calif also published PHP settings to disable session upload progress and remove the memory cap; PHP core developer Gina Peter Banyard has warned that the upload-progress setting alone is not enough, and removing the memory cap lets a single request consume all server memory. Neither step replaces a patch.
• Hunt for evidence. CISA's guidance points defenders at PHP worker processes launching shells or downloading tools. Monitor for unexpected outbound connections from web workers, new files in upload directories, and unfamiliar scheduled tasks.
• Rotate secrets if you were exposed. Given the memory-disclosure path, treat any unpatched window as possible credential exposure: rotate database passwords, API keys, and session secrets, and invalidate active sessions.
• Use the free tooling. OpenAI published a PHP version checker as a Codex skill at github.com/openai/php2shell-checker, and the patchtheplanet.org site collects official guidance and vendor advisories.

The Bigger Lesson for Small Business Websites

PHP2Shell will probably not be the incident that takes down your site. But it exposes a pattern that will keep repeating. The web runs on a layer of decades-old open-source infrastructure maintained by small teams, and a growing share of the vulnerability research now pointing at that layer is automated. OpenAI has committed $1 billion in subsidised access to its security tooling for organisations with limited resources, and the PHP Foundation says it now receives far more reports than before, including more than 100 that turned out to be invalid or duplicate since July.

For a business, the lesson is less about PHP and more about maintenance discipline. Know what your site runs on. Know who is responsible for patching it. Keep a tested backup and a rollback plan, because the next critical disclosure will arrive with a short window and a lot of noise. The organisations that came through this week unscathed were not the ones with the cleverest firewall rules. They were the ones who could answer one question quickly: what version are we running, and who is going to update it today?

Sources

• OpenAI — Patch the Planet: global response coordination as agents uncover critical vulnerabilities
• The PHP Foundation — Today's PHP Security Release, and How We're Strengthening PHP Security
• CISA — Critical Vulnerabilities in PHP Require Immediate Patching
• Calif Research — PHP2Shell: A tale of two PHP remote vulnerabilities
• Sansec — PHP2Shell: PHP RCE (CVE-2026-109618, CVE-2026-109619)
• Palo Alto Networks Unit 42 — Threat Brief: Critical Vulnerabilities in PHP (Updated October 25)
• TechCrunch — PHP-ocalypse: How two critical web bugs almost broke the internet
• PHP.net — PHP October 2026 Security Release