PHP Ships an Emergency Fix This Morning for Two Leaked Critical Flaws: Your Questions on PHP2Shell, Answered

Somewhere in almost every small business’s online footprint there is PHP: the company website, a customer portal, a hosting control panel, a ticketing system, even software bundled inside a network appliance. That is why an unusual notice from the PHP project on Tuesday has administrators clearing their calendars this morning.

This Q&A draws on The Hacker News’ developing explainer, along with reporting from BleepingComputer and SecurityWeek. It was written before the fixes shipped, so check PHP’s official release notes once they are out.

What exactly is happening today?

PHP’s security team scheduled an out-of-cycle security release for Wednesday, October 21, at 14:00 UTC, which is 10:00 a.m. Eastern. It covers two vulnerabilities the team rates 9.2 on version 4.0 of the CVSS scale. PHP has not described either flaw and says full details, affected versions and fixed versions will come with the release. The team also reserved the right to ship earlier if details go public or attacks are spotted.

Why did the warning come early?

Because the secret got out. On October 20, a since-deleted post on the Hacker News forum claimed two PHP remote code execution flaws, scored 10.0 and reaching back to PHP 5, would be disclosed on Thursday, October 22. Security firm watchTowr then confirmed publicly that the flaws were real and had been under embargo until Thursday. PHP published its own notice later that day and moved the release up to Wednesday.

What do we actually know about the bugs?

Researchers are tracking them as CVE-2026-109618 and CVE-2026-109619, identifiers that appeared in the leaked post. PHP’s notice does not name them.
watchTowr says both allow remote code execution, and it believes it has reproduced the first one. It is holding back technical details until patches exist.
CERT-EU says that, judging by the scores, both could be exploited without logging in.
SecurityWeek notes one report suggesting the first flaw is a use-after-free bug. No root cause, affected component or attack path has been published.
The nickname “PHP2Shell” comes from researchers, not from PHP.

Is my version affected?

Nobody can say for certain yet. The leak and watchTowr describe PHP 5 through 8 as affected, but The Hacker News points out that watchTowr’s own FAQ says that range has not been confirmed by an official advisory. What is certain is who gets a fix: only the four supported branches, PHP 8.2, 8.3, 8.4 and 8.5. Several trackers expect the new versions to be 8.5.12, 8.4.27, 8.3.36 and 8.2.35, though PHP has not confirmed those numbers.

Anything older, including 8.1, 8.0, 7.x and 5.x, is end of life. If the flaws reach those versions, there will be no PHP patch for them. Security company Mallory counted roughly 884,000 internet-facing hosts on October 20 whose web banner advertised PHP 8.1 or older, about 59% of the hosts that reported any version. That is a count of banners, not of confirmed vulnerable systems.

Is anyone being attacked yet?

Not as of the latest reports. watchTowr and Huntress both say they have not seen exploitation, Huntress says it is not aware of public exploit code, and the flaws were not in CISA’s Known Exploited Vulnerabilities catalog. That may change quickly. Security firm Sansec told SecurityWeek it expects mass exploitation to begin within 15 minutes of the patch release. For context, when a different PHP flaw on Windows went public in June 2024, Akamai saw attack attempts within a day.

What should I do before 10 a.m.?

PHP has not published a workaround, so the preparation is mostly about readiness. Drawing on guidance from Huntress and CERT-EU as summarized by The Hacker News:

Find every PHP installation you own, including the ones hiding inside appliances, Windows applications and control panels such as cPanel or Plesk.
Line up the update so you can apply it as soon as it lands, starting with internet-facing systems. If you use a Linux distribution’s packages or a hosting company, check their channels for backported fixes.
For anything on an end-of-life branch, plan an upgrade, or take it off the internet or put it behind a VPN or web application firewall until you can.
If you cannot patch right away, CERT-EU suggests considering isolating internet-facing applications from public networks until a fix is available.

And after the update is installed?

Watch what your web server does. An alert whenever php-fpm, php-cgi, Apache or httpd launches a shell, a scripting interpreter or a download tool is a strong signal. If something looks wrong, isolate the server, preserve its web and PHP logs, and look for web shells, unfamiliar files in the web root, new scheduled jobs and new accounts.

What is still unknown?

Which versions are truly affected, which part of PHP is involved, and whether an attack needs a particular setup, configuration or login. The release notes should answer most of that later today.

What this means for your company

Even if you never think about PHP, you probably rely on it. Ask your web developer, hosting provider or IT team three questions today: Where do we run PHP? Which version? Who is applying today’s update, and when? If any answer is “we’re not sure,” or if a site is still on PHP 8.1 or older, treat that as the priority. Managed hosting customers should confirm the provider has a plan rather than assume it.

Need help finding every place PHP runs in your business and getting today’s fix applied safely? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.