Two Critical PHP Vulnerabilities Expose 22.6 Million Instances, and AI Found Them
The flaws allow unauthenticated remote code execution, proofs of concept are circulating, and frontier models helped with the discovery. Patching is the only real fix for PHP vulnerabilities.
PHP released emergency updates on 21 October for two PHP vulnerabilities that allow an unauthenticated attacker to run code on a server, and the security world has spent the days since working out how many systems are exposed. The flaws, tracked as CVE-2026-109618 and CVE-2026-109619, each carry a CVSS 4.0 score of 9.2. Palo Alto Networks‘ attack-surface unit, Cortex Xpanse, puts the number of potentially vulnerable instances it can see on the public internet at more than 22.6 million. National agencies in the United Kingdom, the European Union and Canada issued alerts within a day, and proofs of concept are already circulating.
Two things make this disclosure different from the usual critical-vulnerability cycle. The first is where the flaws sit: in PHP’s memory management and error handling, the parts of the runtime that almost every request touches, which makes them both severe and hard to fix without breaking compatibility or performance. The second is how they were found. The research that uncovered them used frontier AI models, and Google has said its Gemini model contributed to finding the flaw, developing an exploit and validating the patch. That is a preview of a security problem that will define the next few years, and it is why this story matters beyond the immediate patching.
What was disclosed
The PHP project released fixes in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October. The two vulnerabilities affect every version from 5.4 through 8.5.11, which is to say almost every PHP installation in service. They affect the common ways PHP runs behind a web server: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers mod_php the highest-risk configuration, because a demonstrated exploit lets one unauthenticated request trigger the flaw before any application code runs. PHP 8.1 and older have reached end of life and receive no upstream fixes, though the security team published minimal source backports for 7.4, 8.0 and 8.1 for organisations that build from source or have no long-term-support vendor.
The disclosure process itself is worth noting. Wiz Research found the flaws and worked with the PHP project, which pre-announced the release on 20 October so that distributors and long-term-support vendors could prepare. That pre-announcement is now standard practice, and it is also a trade-off: it gives defenders a head start and tells attackers exactly when to look. The PHP Foundation, in its own account, describes the flaws as sitting in parts of the language that nearly every request touches, and explains that this is what made them both serious and hard to fix without breaking compatibility, hurting performance, or forcing changes across the large ecosystem of third-party extensions. That last point is why a language as mature as PHP still carries bugs of this class.
The two flaws, and why they matter
CVE-2026-109618 corrupts memory when a request hits PHP’s memory limit. PHP enforces that limit with a mechanism that aborts the request, and if the abort happens while internal request data is only partly initialised, the cleanup routine can treat invalid data as valid and free memory that an attacker controls. CVE-2026-109619 leaves stale state behind. A fatal error can leave a worker pointing at memory that belonged to an earlier request, and a later request handled by the same worker can read or branch on that freed memory. Both classes, out-of-memory corruption and use-after-free, are well understood and hard to exploit reliably, which is why the disclosure is serious without being an instant catastrophe. What raises the stakes is that the flaws sit before application code, so an attacker needs no vulnerable plugin and no misconfiguration to reach them.
The scale, and what the number means
The headline figure comes from Palo Alto Networks. Its Cortex Xpanse service scans the public internet and reports more than 22.6 million exposed instances that could be vulnerable, based on its telemetry as of 21 October. That number deserves two caveats. It counts exposed instances rather than confirmed vulnerable systems, and it reflects what one vendor’s scanners can see. For comparison, the same company cites recent NetScaler flaws at more than 50,000 exposed instances and a BeyondTrust flaw at over 16,000, so the PHP figure is three orders of magnitude larger, which is what you would expect from a language that runs a large share of the web. The more useful question for a defender is not the global total but reachability: which of the systems you run accept untrusted input from the internet, and of those, which still run an unpatched runtime.
The AI-discovery angle
The disclosure also marks a shift in how vulnerabilities surface. The research came from Wiz, working with PHP, and the company says it used a mix of models to identify and remediate the flaws. Google states that its Gemini model contributed to finding the vulnerability, developing an exploit, detecting attacks and validating the patch, and OpenAI has published an account of coordinating the disclosure as agents uncovered critical vulnerabilities. Read carefully, that is not marketing: three separate organisations describe large language models as participants in vulnerability research, and at least one as a contributor to exploit development. The practical consequence is that the gap between a patch’s release and an attacker’s ability to weaponise it keeps narrowing, because the same tools that help defenders triage also help attackers reverse-engineer the fix.
PHP vulnerabilities: The patch race
That compression is visible in the timeline. The PHP project pre-announced the release on 20 October, which gave vendors a short window, and Palo Alto Networks says its Frontier Virtual Patching capability shipped a signature for both flaws at 10:21 pm Pacific time on 20 October, before public disclosure on the 21st. That is the strongest argument for virtual patching, which blocks exploitation at the network or proxy layer while an organisation tests and rolls out the real fix. It is also an argument for scepticism, because virtual patching is a vendor product and the claim of advance coverage is the vendor’s own. The independent guidance from national agencies is simpler and worth repeating: update to a fixed version, and where that is not possible, isolate internet-facing applications until you can.
What organisations should do
The advice from CERT-EU, the UK’s National Cyber Security Centre and Canada’s cyber centre converges. Identify every PHP installation, including the ones embedded in appliances, container images and commercial products that bundle the runtime, because a content management system or a monitoring tool can carry a vulnerable PHP without your knowing. Prioritise internet-facing systems and anything that processes untrusted input. Update to PHP 8.2.35 or newer, and rebuild and redeploy container images rather than assuming a base-image tag moved. Restart every worker, because a stale worker can keep serving from a patched but un-restarted process. Where you cannot patch, the temporary mitigations matter: disable the upload progress mechanism and fatal-error backtraces, and manage the memory limit carefully, because setting it too low is what triggers one of the flaws. Then hunt for compromise, because the absence of a detected breach is not evidence of one.
The mitigations deserve a word, because CERT-EU is explicit that they reduce exposure to specific attack paths without making an installation safe. Setting the memory limit to unlimited blocks the trigger for the first flaw, but an underlying allocation failure can still reach the vulnerable code path. Disabling the session upload-progress mechanism and fatal-error backtraces blocks the confirmed paths for the second, but not every variant. Setting a low post body size and enforcing request limits at the proxy or web server level help, and CERT-EU warns against using operating-system address-space limits as a substitute, because they can themselves trigger the vulnerable allocation failure. The one measure that closes both flaws is the patch.
Patching PHP
Three priorities follow from the guidance, and they are worth stating plainly. First, inventory: the hard part of this event is not patching PHP, it is finding PHP, because the runtime hides inside appliances, container images, content management systems and commercial products that never advertise their dependencies. The Dutch national cyber centre has published an inventory of products with a PHP dependency, and that list is the fastest way to check. Second, sequencing: internet-facing systems that accept untrusted input come first, and a system that only serves internal users can wait. Third, verification: restart every worker, because a patched runtime in a process that keeps running is not a patched system, and rebuild container images rather than trusting a moving base-image tag.
What it signals
This is what a modern critical-vulnerability event looks like: a flaw in ubiquitous infrastructure, a global coordinated disclosure within 24 hours, proofs of concept in the wild almost immediately, and an attack-surface number in the tens of millions. The AI angle makes it a marker rather than a one-off. If models can help find memory-corruption bugs in a language as heavily scrutinised as PHP, then the rate at which such flaws surface will rise, and the defender’s window between patch and exploit will keep shrinking. The response that works is unglamorous and already known: know what you run, patch what faces the internet first, and keep a virtual-patching layer for the hours when you cannot. The industry has heard this for years. This week it has a reason to listen.