PHP2Shell (CVE-2026-109618, CVE-2026-109619): what to do now

PHP2Shell is the name given to two critical vulnerabilities in the PHP language runtime, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. Both can let an unauthenticated attacker run code on a web server that serves PHP. The fix is to update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart every PHP worker.

PHP runs a large share of the web, including widely used platforms such as WordPress, Drupal and Magento, so your own systems are only half the question. This post explains what the two flaws are, what the PHP project recommends, how to work out which of your vendors are exposed, and how to track them to closure. All facts are as of 23 October 2026 and come from the PHP project's own advisories.

What is PHP2Shell?

The PHP security team published two advisories on 21 October 2026, alongside emergency security releases. Details had leaked publicly the day before, ahead of the planned disclosure, which is why patches and public discussion arrived almost together.

• [CVE-2026-109618](https://www.cve.org/CVERecord?id=CVE-2026-109618), "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w). When PHP runs out of memory at the wrong moment, internal request data can be left only partly set up, and request cleanup then treats the invalid data as valid.
• [CVE-2026-109619](https://www.cve.org/CVERecord?id=CVE-2026-109619), "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp). Internal state owned by one request can survive after its memory is freed, and a later request handled by the same worker can use it before normal initialization resets it.

Both are rated CVSS v4.0 9.2 (critical). The scoring marks the attack as high complexity with specific preconditions, but it needs no account and no user interaction, and the confirmed impact is code execution with the web worker's privileges. The PHP project states plainly that updating is the only complete fix.

Which PHP versions and setups are affected?

Every PHP release before the fixed versions below is affected. The PHP project says all installations serving web requests are at risk, and rates Apache with mod_php highest, because a demonstrated attack works with a single unauthenticated request before any application code runs.

Server setups named in the advisories include Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. Exposure differs by setup (for example, PHP-FPM is exposed under narrower conditions than mod_php), but no web-facing setup should be treated as safe until it is updated.

What should you do if you cannot patch today?

The PHP project's advisory lists interim measures. It is explicit that they reduce exposure to specific attack paths and do not make an installation safe.

On 23 October 2026 the PHP project added an informational advisory for a related, much narrower issue, CVE-2026-115560, and recommends keeping session.upload_progress.enabled=0 until the next regular release. If you already applied that setting, no further action is needed.

How do you find which vendors are exposed?

A vendor running PHP on an internet-facing system is a downstream exposure for you if that system holds your data, serves your customers or connects to your environment. Work from risk, not from the alphabet.

1. Start with the vendors that matter most. Begin with Tier 1 and Tier 2 vendors, then vendors that host your data or run customer-facing services. The vendor tiering guide explains why this order holds up with examiners.
2. Use what you can see from outside. Some web servers announce their PHP version in response headers. That is a useful lead, not proof: many servers hide or misreport versions, and distributions backport fixes without changing the version number.
3. Ask, and ask for evidence. A short, targeted request beats a full reassessment. Ask the questions below and accept evidence, not a yes.
4. Include fourth parties. Managed hosting providers and SaaS platforms built on PHP can expose your vendors, and through them, you. See downstream risk in your vendor chain.

How do you track vendors to closure?

Treat each exposed vendor as a finding with an owner and a due date set by tier, and record the evidence when it arrives. Where a vendor cannot patch quickly, for example because it runs an end-of-life PHP version, record a time-bound risk acceptance with compensating measures, an owner and a review date, rather than leaving the finding open with no decision.

Security researchers have reported exploitation attempts since 21 October 2026. As of the catalog update of 21 October 2026, CISA had not added either CVE to its Known Exploited Vulnerabilities catalog. Watch for that change: it raises the priority for everyone. If a vendor tells you a system was compromised, switch to your incident playbook; the first 72 hours after a vendor breach covers the steps.

How does VendRisk360 support this?

The VendRisk360 platform and website do not run PHP, so they are not affected by these vulnerabilities. For your vendors, VendRisk360 helps in four ways.

• Outside-in visibility. Attack surface monitoring lists vulnerabilities in the software each vendor exposes, with whether they are known to be exploited (CISA KEV), exploit likelihood, public exploits and end-of-life software. A vulnerability inferred only from a version banner is listed as unverified for checking and never lowers the vendor's score on its own, so a hidden or backported PHP version does not create a false alarm.
• Act on what you find. From a finding you can request remediation from the vendor with the evidence attached, acknowledge it, accept it or mark it a false positive. Your decisions change your organization's view only, and a material change can bring the vendor's next assessment forward.
• Ask for evidence. Send the targeted questions above through the vendor portal and keep the answers and evidence on the vendor record, where auditors and examiners can see them.
• See the chain. Hosting, DNS and other providers seen in vendors' public records feed fourth-party and concentration analysis, so a shared hosting provider shows every vendor that depends on it.

Teams that want this handled for them can use Continuous Vendor Monitoring, where the VendRisk360 team triages signals and confirms them before they alert.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name for two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. Both can allow an unauthenticated attacker to run code on a web server that serves PHP, with the privileges of the web worker. Both are rated CVSS v4.0 9.2.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both vulnerabilities. Earlier releases in those branches are affected. PHP 8.1, 8.0 and 7.4 have no official release, though the PHP team published minimal source backports, and PHP 7.3 and older have no fix.

Is turning off session upload progress enough?

No. Setting session.upload_progress.enabled=0 blocks the confirmed session-based paths for CVE-2026-109619, but not other variants, and does nothing for CVE-2026-109618. The PHP project says updating to a fixed release is the only complete fix; interim settings only reduce exposure until you can update.

What should we ask our vendors about PHP2Shell?

Ask whether they run PHP on internet-facing systems that handle your data, which versions, whether those systems are updated to a fixed release with workers restarted, what interim measures are in place, the plan for any end-of-life PHP, and whether they reviewed affected systems for signs of compromise. Ask for evidence with each answer.