If Your Site Runs PHP, Patch It Now: Outsiders Can Run Code Without a Login

Two critical PHP flaws found with AI assistance have been linked to outages at major websites, exposing how a shared software fault can put many services at risk. ^[1][2][5]

Wikipedia, 4chan and DeviantArt experienced major problems, according to The Verge, which also said some Dutch and Finnish government agencies took websites offline as a precaution. Computer Weekly reported shutdowns or disruptions affecting additional public agencies and websites in the Netherlands, France, Denmark and the UK. ^[1][5]

PHP runs website code on servers, handling work such as assembling pages and connecting to databases before a visitor's browser receives the result. Software including WordPress and MediaWiki, which powers Wikipedia, relies on it. A fault at that level can reach across otherwise separate websites. ^[2][5]

The PHP team released fixes on October 21 and says all installations serving web requests are at risk. The vulnerabilities can allow an outsider to execute code without logging in, with the highest risk affecting Apache servers using mod_php, the module that lets the Apache web server run PHP code directly. ^[3][6]

The incident is developing. How many services failed directly because of the flaws, rather than closing as a precaution, has not been established. Nor has the extent of real-world exploitation, the proportion of servers patched or the precise contribution AI made to the research. ^[1][2][5][6]

A fault beneath the website

The two bugs concern how PHP manages memory when something goes fatally wrong during a request. One involves an out-of-memory error that can leave internal request data only partly prepared. The other leaves internal state referring to memory that has already been freed. ^[6]

A server worker, the process handling requests, may then pick up another request before that state has been properly reset. It can end up using stale information from the earlier work. The PHP advisory identifies these failures as routes to remote code execution, meaning an attacker can make the server run code of the attacker's choosing. ^[6]

This is why the response extends beyond the teams that maintain individual websites. PHP is the language runtime beneath their applications, the software that carries out the applications' instructions. Repairing a website's own code cannot remove a flaw in that shared foundation. ^[2][5]

Security firm Wiz says its researchers demonstrated code execution without authentication against WordPress, Drupal and Joomla, three widely used systems for managing websites. It also says it demonstrated disclosure of memory from PHP processes. According to Wiz, those demonstrations depended on flaws in PHP itself, rather than separate bugs in the applications. ^[2]

That puts a site operator in an awkward position: an application can be maintained and still sit on a vulnerable runtime. The relevant repair has to reach the server software underneath it.

The PHP security team gave advance notice on October 20, assigning both vulnerabilities a severity score of 9.2 out of 10 under version four of the Common Vulnerability Scoring System. Its security releases followed the next day. ^[4][6]

AI helped turn old bugs into working exploits

According to The Verge, the AI security group Calif found one flaw using OpenAI's GPT-5.6 Sol. Wiz independently found and reported the vulnerabilities, using its Wiz Atlas system alongside Gemini 4 Argon and GPT-5.6 Sol, according to the firm's account. ^[1][2]

The striking detail is the age of the underlying defects. Wiz says they had been present for more than a decade. New tools helped researchers find a dangerous use for old mistakes. ^[2]

Finding faulty memory handling and turning it into a reliable exploit are different jobs. A crash shows that software has failed. A working exploit must make that failure do something useful to the attacker. Wiz says its researchers had to link bugs together and adapt their work to the way each target arranged memory. ^[2]

The firm says AI reduced the effort needed to develop and adjust those exploits across different setups. That is its assessment as a participant in the research, rather than an independently measured productivity result. ^[2]

The practical significance lies in that adjustment work. If tools reduce the effort required to turn a difficult bug into a working exploit, defenders have less reason to count on technical complexity buying them time. The same assistance that helps researchers demonstrate a flaw can make an urgent patch more urgent.

The fix has to reach real servers

The PHP project's repaired releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Its guidance is direct: updating is the only complete solution. Measures that reduce exposure to particular attack paths do not make an installation safe. ^[6]

For operators on older software, obtaining that fix may involve another organisation. PHP 8.1 and earlier no longer receive updates from the PHP project, though software distributors and long-term support vendors may supply fixes adapted for those older releases. ^[6]

Computer Weekly reported that some administrators were waiting for vendor fixes and that some organisations took systems offline while responding. That leaves an immediate trade-off between keeping a service available and reducing its exposure while repairs arrive. ^[5]

A security release starts the repair process. Hosting providers, distributors and site operators still have to carry it through to the machines answering visitors' requests. For those unable to update immediately, the PHP team's warning remains that interim protections are incomplete. The next operational task is to obtain the appropriate fixed release and deploy it. ^[6]