AI found the PHP holes first. Patch the runtime, then prove it

THE SIGNAL IN ONE SENTENCE

A security patch became a public-service story today. On October 21, the PHP project released four emergency updates for two critical vulnerabilities in the language runtime. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The flaws are tracked as CVE-2026-109618 and CVE-2026-109619. Both received a CVSS v4.0 score of 9.2. The PHP team says they can allow remote code execution without authentication. That means a vulnerable web server may process a specially made request and run attacker-controlled code before the website's own application logic has any useful chance to stop it. This is not a bad WordPress plugin or an unlucky line in somebody's checkout form. The bugs sit in PHP itself. PHP says every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers mod_php the highest-risk setup. The project says a demonstrated exploit can trigger before application code runs. So the plain signal is blunt: patch the runtime, then prove it. Do not settle for a ticket marked done because somebody upgraded a package on one machine. Do not treat a web application firewall as a replacement for the vendor update. Do not assume that updating WordPress, Drupal or Magento updated PHP underneath it. The thing that needs fixing is the runtime that actually handled the request. The first vulnerability concerns out-of-memory handling. PHP can interrupt a request while internal data is only partly initialized. Cleanup may then treat unfinished data as valid. The second concerns stale global state. Data associated with one request can survive after its backing memory has been freed, then be touched by a later request before normal initialization resets it. Those descriptions sound like an argument between a compiler and a haunted filing cabinet. The operational consequence is simpler. Memory that should be unavailable can remain useful to an attacker. CERT-EU says the flaws can support unauthenticated remote code execution. It lists every supported PHP branch below today's fixed release as affected, plus end-of-life branches. It recommends immediate patching and says organizations that cannot patch should consider isolating internet-facing applications until a fix is applied and verified. The phrase applied and verified is doing important work. Modern web estates are messy. A public domain may sit behind a content delivery network, a reverse proxy, a container platform and several old virtual machines. The production application may have one PHP version while a forgotten admin tool, image processor, control panel or vendor appliance bundles another. A package manager can report success while long-running workers still use the old binary. A new container image can exist while the deployment keeps serving the previous digest. A staging host can be safe while one production pool remains exposed. A vendor can say its platform is protected while a customer's self-managed add-on is not. That is why the response needs a patch receipt. Start with inventory. Record every internet-facing hostname and service that executes PHP, including software that hides PHP inside an appliance or control panel. For each asset, record who owns it, how PHP is installed, which process manager serves requests and whether a hosting provider controls the runtime. Then record the before state. Capture the exact runtime version from the process that serves web traffic, not only from a developer's command line. Save the package or image identifier, the worker pool, the deployment region and the time of observation. Next, apply the supported update. PHP's safe versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older are end of life. Some operating-system and long-term-support vendors may provide backports, and the PHP team published minimal source backports for 7.4, 8.0 and 8.1 for organizations without another route. A backport is not permission to forget an obsolete branch. It is a bridge to a supported one. Restart the workers. This detail is easy to miss and embarrassing to explain later. A patched file on disk does not automatically replace code already loaded by every running process. Then verify the after state from the serving path. Check more than one worker, region and instance. Confirm the expected package or image digest. Confirm that old workers drained. Confirm that the public route still works. Confirm that logs and security telemetry continued through the change. Finally, attach evidence. A useful receipt includes the asset, old version, fixed version or vendor backport, package or image digest, deploy time, worker restart time, verification method, verifier and any exception still open. If an asset cannot be patched, name it. PHP says only an update is a complete solution. Its advisory lists temporary measures that reduce specific attack paths, such as disabling session upload progress, changing memory settings, reducing request sizes and restarting workers. It repeatedly warns that these steps do not make an installation safe. Cloudflare says it deployed web application firewall protections for customers and observed attackers mutating payloads while it watched attack traffic. That is useful defense in depth. Cloudflare still tells customers to patch. A firewall rule can reduce exposure. It cannot prove every encoding, proxy path, content type or new exploit variation is blocked. It may also be absent on a forgotten hostname or bypassed through a direct origin address. The emergency is also an AI story. Wiz says its researchers used Wiz Atlas, Google's Gemini 4 Argon and OpenAI's GPT-5.6 Sol during the work. Its disclosure timeline says it discovered the first vulnerability on August 19, confirmed unauthenticated remote code execution against Drupal on August 20 and WordPress on August 21, then reported the vulnerabilities to the PHP security team on August 24. The tools helped researchers reason across old memory-management code, develop exploits, detect attack behavior and validate the patch. The result is a real public benefit. Bugs that survived years of ordinary scrutiny were found before the disclosure turned into a much wider race. But AI changes both sides of that race. Once a patch is public, attackers can compare the fixed and vulnerable code. Models can help explain the difference, generate test cases and adapt proof-of-concept code. Wiz says the economics of discovery and exploitation have changed because work that was once difficult to scale has become more accessible. That does not mean every person with a chatbot can compromise every PHP server. It means patch windows measured in weeks look increasingly unrealistic when machines can assist with reverse engineering in minutes or hours. The defenders' advantage is coordination. Researchers, maintainers, operating-system vendors, hosting providers, security agencies and infrastructure companies can prepare fixes, backports and filters before public disclosure. The patch receipt tells each organization whether that coordination actually reached its own machines. The open-source maintenance lesson deserves attention too. PHP is foundational infrastructure maintained through a project and foundation that serve an enormous part of the web. The blast radius is not proportional to the size of the team maintaining every old branch and memory path. AI-assisted audits will likely find more of these mismatches. Celebrating the model is easy. Funding the maintainers who must reproduce the report, design a safe patch, backport it, coordinate vendors, publish guidance and handle the aftermath is the grown-up part. Organizations should treat critical open-source runtimes like infrastructure, not free wallpaper. Keep a version inventory. Budget for upgrades. Subscribe to security notices. Rehearse an emergency patch. Know who can take a service offline. Test restoration before the bad afternoon arrives. For small site owners, the shortest useful plan is this: Ask the host which PHP version serves the site. Compare it with the fixed versions. Request the update in writing. Restart or redeploy if the hosting model requires it. Check the public site and admin path. Save the host's confirmation and your own verification. If the host cannot patch, move the service or take the vulnerable path offline. For larger teams, add discovery. Search container registries, virtual-machine inventories, control panels, developer tools, cron hosts and internal admin services. Do not stop at the domains in the marketing spreadsheet. For public agencies, add continuity. Taking a service offline can protect data while cutting people off from benefits, health information, school systems or civic records. Publish a plain status page on separate infrastructure. Provide a safe alternate channel. Record which services were unavailable and for how long. There is no shame in a short, deliberate outage when the alternative is an exposed server. There is shame in declaring victory without knowing what still runs. AI helped find the holes. Humans coordinated the fix. Now operators need to close the loop with evidence. Patch the runtime. Restart the workers. Verify the serving path. Keep the receipt. The checkbox can wait until all four are true.