PHP2Shell Touches Most of the Web. Patch Fast, Then Find Every Place PHP Is Hiding.

Two critical flaws in PHP's core engine got emergency patches on October 21. They are tracked as CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0, and together they're nicknamed PHP2Shell. Unauthenticated remote code execution, confirmed on Apache with mod_php, plus the ability to read process memory where credentials and API keys tend to live.

The researchers reported the bug in August. The plan was a quiet, coordinated disclosure on October 22. Then details leaked on October 20, the PHP Foundation pulled the release forward a day, and exploit attempts showed up before many teams had even read the advisory. Reports differ on exactly when it started. Some vendors saw probing on the day of the patch, and one reported attempts four days earlier.

Why this one is different

It isn't a WordPress plugin bug or a Magento extension. It sits in the language runtime itself. Wiz estimates the flaws touch about 70% of websites worldwide regardless of CMS, and the affected range goes back to PHP 5.4. Patched releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with minimal backports for 7.4, 8.0 and 8.1.

That last part matters. VirusTotal counted roughly 758,000 servers running branches that are already end of life. For those teams, "just upgrade" is a project, not a Tuesday task.

The patch is not the hard part

Most engineering teams can bump a PHP version on the main app. The trouble is everything else:

• The legacy admin panel someone built in 2017 and nobody owns
• A WooCommerce or Magento store on a managed host you don't control
• A marketing microsite on a forgotten VPS
• Docker images pinned to a base tag from last year
• Vendor-hosted tools that quietly run PHP underneath

If you can't answer "where does PHP run in our company?" in under ten minutes, that's the actual finding from this week. The CVE just made it visible.

What we'd do today

1. Inventory first. Grep your Dockerfiles, CI configs and hosting accounts for PHP. Check the version actually running, not the one in the repo.
2. Patch the internet-facing stuff before anything else. Internal tools can wait a day. Public endpoints can't.
3. Rotate secrets on anything that was exposed unpatched. The memory-read angle means API keys and database credentials in process memory are fair game. If a host was reachable and vulnerable during the window, assume the keys need replacing.
4. Turn on your WAF rules, but don't stop there. Cloudflare shipped protections hours before disclosure, which helps. The PHP Foundation itself says mitigations reduce specific attack paths but don't make an install safe.
5. Write down who can approve an emergency change. Half the delay in incidents like this is people waiting for permission, not for code.

The takeaway

Disclosure windows are shrinking. When an exploit video is circulating overnight, you get hours, not a sprint. The teams that handle this well aren't faster typists. They already know what they run, who owns it, and how to ship a change to it without a meeting.

If you inherited a PHP estate you don't fully understand, this is the week to map it. Not because of one CVE, but because the next one will arrive on the same kind of timeline.

We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!