PHP2Shell: What the Critical PHP Vulnerabilities Mean for Your Servers

Schedule a demo and we’ll show you how it’s done. Book a demo →

What happened with PHP2Shell?

PHP2Shell is a pair of memory-handling bugs in the PHP engine itself, so it affects applications regardless of how well their own code is written.

The first, CVE-2026-109618, sits in how PHP handles a request that runs out of memory. PHP abandons the request mid-flight, and in certain contexts its cleanup routine then reads memory that was never properly initialized. An attacker who can shape that memory can steer what the cleanup code does next.

The second, CVE-2026-109619, is triggered by fatal errors. After one occurs, PHP can keep pointers to memory that was already freed at the end of the request. The next request handled by the same worker then reads that stale state.

Both are rated CVSS v4.0 9.2. Researchers demonstrated several ways to turn them into remote code execution, arbitrary file reads and leaks of server memory. In one demonstration, a single unauthenticated POST request was enough, and the attacker’s command ran before the application code even started. Code runs with the permissions of the PHP worker, so anything that process can read (config files, database credentials, API keys) is within reach.

What is PHP?

PHP is a server-side scripting language that has powered the web since the mid-1990s. It runs WordPress, Drupal, Magento, Laravel applications and a long tail of internal tools, and it is used by roughly 69% of websites whose server-side language is known.

Plenty of companies run PHP without thinking of themselves as a PHP shop. A marketing site on WordPress, a legacy admin panel nobody has touched since 2019, or a base image in your CI pipeline can all carry a vulnerable PHP build. It typically runs through Apache’s mod_php module or PHP-FPM behind Nginx, and the vulnerable code paths are present in both.

Who discovered PHP2Shell, and when

The bugs were reported jointly by researchers from Calif, Wiz and OpenAI, with Quarkslab also credited on the out-of-memory flaw. Researchers say AI helped them build working exploits in about a week.

The public timeline moved fast:

• October 17: a honeypot run by a major cloud provider logged an exploitation attempt, four days before public disclosure.
• October 20: the CVE identifiers became public ahead of the release, and PHP posted its disclosure.
• October 21: PHP shipped patched versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12, and security teams started reporting attempts in the wild.

Why PHP2Shell is controversial

A critical bug in a language this widespread would draw attention on its own. A few details about this disclosure have made it more contentious.

Someone had it early. An exploitation attempt showed up days before anyone outside the disclosure group was supposed to know about the flaw. Nobody has explained publicly how the attacker got the details, which means the usual assumption that you are safe if you patch on disclosure day does not hold here.

AI shortened the timeline. If skilled researchers working with AI can produce reliable exploits within a week, so can attackers. The gap between a patch going out and attacks scaling up is getting shorter, and teams that patch on a monthly cycle are exposed for longer than they think.

Older versions are in a gray zone. The vulnerable code traces back to PHP 5.4. Versions 7.4 through 8.1 received source-level backports rather than official releases, and anything older is end of life with no fix at all. Whether you are protected on those versions depends on your Linux distribution or LTS vendor, and reports disagree on what is covered.

The workarounds are disputed. Several interim mitigations are circulating, including disabling session upload progress and adjusting memory limits. Different research teams disagree on how much they help, with some saying they block part of the attack surface and others saying they do not protect you at all. Patching is the only fix everyone agrees on.

The score moved. Early identifiers circulated with a CVSS score of 10.0 before the PHP security team published its official 9.2, which created confusion during the first hours of triage.

How PHP2Shell affects you

If you run PHP anywhere that accepts web traffic, assume you are affected until you have checked. Internet-facing servers on Apache mod_php carry the highest risk, followed by PHP-FPM deployments.

Start with inventory. Run php -v and php-fpm -v on hosts and inside containers, and include CI images, which often hold secrets that make them attractive targets.

Patching closes the hole going forward, but it tells you nothing about what happened before you patched. Since attempts were seen as early as October 17, treat that date as the start of your investigation window and look for:

• Unusually large multipart POST requests, form submissions with an abnormal number of fields, or odd session parameters in web server logs
• Memory exhaustion errors during request startup, bursts of HTTP 500 responses, or PHP workers crashing and restarting without an obvious cause
• Oversized PHPSESSID values in Set-Cookie headers, which can point to memory being leaked back to the client
• Shell or other unexpected child processes spawned by PHP workers
• New outbound connections from web servers, unexpected changes to application files, or signs of persistence

One caveat: a successful exploit does not always crash the worker. The absence of errors is not proof that nothing happened, which is why process and network activity matter as much as application logs.

The cost of missing this adds up quickly. A compromised web server can expose database credentials and customer data, and it can give an attacker a foothold to move deeper into your cloud environment. Every day an intrusion goes unnoticed adds hours of forensic work, cleanup and potential disclosure obligations.

How Logz.io helps you catch PHP2Shell and the next vulnerability

Vulnerabilities like PHP2Shell will keep coming, and the window between disclosure and exploitation keeps shrinking. What protects you is visibility: knowing quickly when something unusual is happening on your servers, and having the context to act on it.

Logz.io Cloud SIEM brings your web server logs, PHP-FPM logs, host and process telemetry, and cloud audit logs into one place, with more than 350 built-in integrations. That means the signals listed above, which usually live in separate tools, can be correlated in a single view. A spike in oversized POST requests followed by a worker restart and a new outbound connection reads very differently together than it does spread across three dashboards.

If you’re already a Logz.io Cloud SIEM customer, you can set up detection for PHP2Shell in a single step. Open OrionIQ chat in your SIEM account and type: “Create new security rules for CVE-2026-109618 and CVE-2026-109619.” OrionIQ by Logz.io builds the rules from your own logs, so they reflect how your environment runs. The same request works for any new CVE, which means your detection can be ready the day a vulnerability is announced.

To have OrionIQ investigate when one of those rules fires, turn on Alert AI Analysis in the rule settings. Once it’s enabled, OrionIQ‘s AI agents start investigating the moment the rule triggers. They connect to your existing tools, pull the surrounding context across your stack and give your on-call engineer a clear account of what happened, where and what to check next. Without it, the rule still sends an alert, but no agent runs on it. The difference between catching an intrusion in the first hour and finding it weeks later is often the difference between a short incident and a costly breach.

If you need help with this fix, feel free to contact support.

If you want to see how this would look in your environment, book a demo or start a free 14-day trial. You can also review Logz.io pricing to see how consumption-based plans fit your log volume. Assess cost controls alongside data recovery, investigation workflows, and governance. The lowest possible ingestion volume can impair operations if it removes critical evidence.

FAQs