PHP Says Patch Two 9.2-Rated Flaws at 14:00 UTC. It Has Not Said Which Versions Are Affected

PHP's security team has told every PHP user to get ready to patch and has not said which versions are broken. The fix is scheduled for 14:00 UTC on Wednesday, October 21, 2026, which is 9 a.m. Central. As of 3 a.m. Central, neither the affected versions nor the fixed ones are public.

What PHP has actually said

The notice on php.net is short. It names two critical vulnerabilities, both rated 9.2, and gives a release time. It also says the team reserves the right to ship earlier if details become public or if attacks show up in the wild. CERT-EU lists the flaws as CVE-2026-109618 and CVE-2026-109619 and says that, apart from the scores, no technical details exist in public.

CERT-EU's own advisory says its summary rests on leaks. The references it lists include two social media posts, one of them from the security firm watchTowr. PHP has not said what leaked or confirmed that anything did.

Where the PHP 5 claim comes from

The widest claim in circulation is that every PHP version from PHP 5 onward could be affected. CERT-EU and the Australian agency both repeated it, according to Reuters. CERT-EU's advisory sources that line to a social media post, not to PHP, and Reuters notes PHP has not said which versions are vulnerable. As of this writing it is an unconfirmed claim that two government agencies have passed along.

Set it against the supported list on php.net. That list has four branches: 8.2, 8.3, 8.4 and 8.5. PHP 8.2 gets security fixes only, and even that ends on December 31, 2026. A claim reaching back to PHP 5 covers a lot of servers outside that list. The notice does not say whether the release includes builds for any of them, so the people running old PHP have the least certain path.

Offline versus isolated

Reuters wrote that EU officials said organizations unable to patch should consider taking affected websites offline. The advisory text on CERT-EU's site reads differently. It says to consider isolating internet-facing applications from public networks until a fix is available. Isolating can mean restricting who can reach an application rather than switching a site off, though CERT-EU does not spell out the steps.

Who is exposed, and how sure anyone is

Huntress, a security company, put the reach plainly in a blog post that Reuters quoted: "PHP is everywhere." It named WordPress, Drupal, Joomla and Magento sites, shared hosting platforms and control panels among the users. GoDaddy told Reuters the flaws could let attackers run code on servers over the internet, with data theft, defacement or full system compromise as outcomes.

Those are worst-case descriptions of flaws whose details nobody outside PHP has published. The Australian agency's position is the measured one: identify PHP systems, prepare to patch, watch applications for signs of abuse, and note that it sees no exploitation so far. Reuters is the only outlet here with the vendor quotes, and its story traces back to the same PHP notice and CERT-EU advisory.

What settles it after 14:00 UTC

Three things. The fixed version numbers, whether any branch older than 8.2 gets a build, and whether attacks appear once fixes are public. Attackers can compare a patch to the code it replaces, which is the usual pattern after a release, and nobody has reported it happening here. PHP's reserved right to release early covers that case.

In the 2026 news items I read on php.net, the September 24 security release for PHP 8.4.26 arrived as a finished release, not as an advance warning. This one came with a day of notice, which suggests PHP sees it as unusual, though PHP has not said so. A 9.2 tells administrators how bad it could be. Only the release can tell them whether their version is covered.