The week the sites went dark
In the week of 19 October 2026, governments and companies in many countries took working websites offline on purpose, because two flaws in a programming language called PHP had been found and the fix had only just been released.[1]
The BBC reported that international governments and agencies urged websites to address two critical flaws in PHP, that multiple cyber-security agencies urged organisations unable to apply fixes in time to consider taking their sites down, and that bodies including the Finnish government and Edinburgh council took pages offline.[1] The part that made it unusual is how the flaws were found. The BBC says they were discovered by AI, and that Wiz, one of the finders, called them the “most severe vulnerabilities ever discovered” by the technology.[1]
2
critical flaws
CVE-2026-109618 and -109619
9.2
CVSS 4.0 score
PHP Foundation’s rating
~70%
of websites run PHP
Wiz, W3Techs; BBC could not verify
5.4+
versions affected
Wiz; CERT-EU says PHP 5 on
Scores and shares are as stated by the PHP Foundation, Wiz, W3Techs (via iTWire) and CERT-EU (via the BBC). The sources do not agree on how far back the affected versions go.
This article follows the AI thread through the story: what AI could do before, what it did here, what it is doing for defenders and attackers now, and what its makers and critics say comes next. It also asks how bad the damage really was, because “taken offline” and “hacked” are not the same thing.
- 17 Oct
Amazon’s honeypots log a PHP2Shell exploit attempt from an anonymised address, four days before disclosure.
- 20 Oct, ~15:00 UTC
The two CVE IDs start circulating online, with some wrong details. PHP moves its release forward a day.
- 21 Oct, 14:00 UTC
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released. OpenAI, Wiz and the PHP project publish. Agencies in many countries issue alerts.
- 21–22 Oct
Government and other sites go offline in several countries. Wikimedia takes down some systems.
- 22 Oct
Cloudflare reports exploit attempts in the millions. Australia’s agency says patches are out.
- 23 Oct
PHP reserves a third CVE for an unlikely configuration and publishes an informational advisory. No publicly confirmed compromise yet, per The Register.
Times are UTC where the sources give them. Dates are from the PHP Foundation, Amazon, iTWire, the BBC and The Register.
What PHP2Shell is
PHP is the language that runs on a web server and builds each page you see. iTWire, citing W3Techs, says it runs roughly 70% of websites whose server-side language can be identified, including WordPress, Drupal, Joomla and MediaWiki.[2] The two flaws are CVE-2026-109618 and CVE-2026-109619. The PHP project calls them critical, and says both can allow unauthenticated remote code execution, meaning a stranger can run commands on your server without logging in.[3]
The PHP project says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the risk highest for mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs.[3]
RCE via out-of-memory corruption
RCE via stale global state
Paraphrased from the PHP Foundation’s post and the php.net advisory. Both sit in memory management and error handling, which nearly every request touches.
Wiz says the flaws are in PHP itself, so that even a simple “Hello World” application on an affected version can be vulnerable, and that attackers could also read process memory containing passwords, tokens and API keys without needing code execution.[4] iTWire adds why the database behind a site is not safe either: PHP holds the keys, since a site’s config file often stores the database login, so an attacker who runs code through PHP can usually reach the data.[2]
- 1
A visitor sends a crafted request to a PHP web server.
- 2
The flaw lets that request corrupt the PHP process’s memory.
- 3
The attacker can run code as the web server, or read memory.
- 4
Memory can hold passwords, tokens and API keys. A site’s own config often holds its database login.
- 5
From there an attacker can usually reach the data behind the site.
Illustration: our ordering of what Wiz and iTWire describe. The database software itself is not touched by these CVEs, according to iTWire.
Fixes shipped in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive updates from the project, though its security team provided minimal source backports for 7.4, 8.0 and 8.1, and the project says only an update is a complete solution.[3]
Before AI: how bugs like this hide
Memory bugs like these are notoriously complex, Wiz says, and hard to find and harder to use.[4] For years the main tools were human code audits and fuzzing, which throws huge amounts of random input at a program and watches for crashes. Google’s Project Zero said in 2024 that fuzzing was not catching variants of previously patched bugs, while for attackers manual variant analysis was a cost-effective approach.[5]
On 1 November 2024, Project Zero and Google DeepMind described a Gemini 1.5 Pro-based agent called Big Sleep finding an exploitable stack buffer underflow in SQLite, which was fixed before any official release. They wrote: “We believe this is the first public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software.”[5] The team said it saw a “promising path towards finally turning the tables and achieving an asymmetric advantage for defenders.”[5]
PHP’s own story shows the human limits. The PHP Foundation says that in 2024 an external audit by Quarkslab, funded through the Sovereign Tech Agency and organised through OSTIF, led a PHP developer to find “the first signs” of the out-of-memory problem behind CVE-2026-109618.[6] No concrete way to exploit it was found, other issues with clearer impact overshadowed it, and the several possible fixes each had trade-offs, such as compatibility breaks, new denial-of-service potential or changes to many third-party extensions.[6] The Foundation calls the resulting delay “a structural failure”, caused by its security team’s decision process and lack of resources.[6]
How AI found PHP2Shell
OpenAI says Calif identified a critical flaw using GPT-5.6 Sol as part of its Patch the Planet initiative, and that Wiz independently discovered and reported both vulnerabilities.[7] The PHP Foundation says Calif began an audit of PHP on 30 July 2026, and that on 11 August a Calif researcher reported an unconditional remote code execution with the same root cause as the 2024 finding, which OpenAI independently reported the same day.[6] Wiz says it discovered its first PHP vulnerability on 19 August using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol, confirmed unauthenticated code execution against Drupal on 20 August and WordPress on 21 August, and reported to the PHP security team on 24 August.[4]
- Calif
Security firm, in OpenAI’s Patch the Planet
A Calif researcher used GPT-5.6 Sol and reported a critical RCE on 11 August 2026, per the PHP Foundation and OpenAI.
- Wiz
Cloud-security firm, independently
Used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol. It says it found the first bug on 19 August and reported on 24 August.
- OpenAI
An internal researcher, around the same time
The BBC reports OpenAI saying a researcher inside the company also found the issue around the same time as the other firms.
- PHP team
Maintainers, who wrote and shipped the fix
PHP’s maintainers led the fixes and the release, per OpenAI. The Foundation says a person makes every call and works on every patch.
Dates differ between sources: Wiz says 19 August for its discovery, and the Foundation lists reports from Calif and OpenAI on 11 August.
Wiz is blunt about what AI changed. It says the vulnerable code had been present for more than a decade, but that turning the flaws into working exploits needed chaining several bugs and accounting for how PHP allocates and reuses memory across requests. Its claim: “With frontier AI models and the right tools, a single researcher completed in a week what previously would have taken a world-class team months of work.”[4]
The BBC quotes Wiz: “Frontier models were critical to making this process practical, enabling us to develop and adapt working exploits across multiple applications in hours.”[1] Wiz says it demonstrated unauthenticated remote code execution on the latest container images of WordPress, Drupal and Joomla.[4]
| Before frontier AI | With it | |
|---|---|---|
| Finding the flaw | A 2024 human audit found only “the first signs” of the memory problem; no working exploit was known. | Calif, with GPT-5.6 Sol, reported an unconditional RCE on 11 August 2026. |
| Turning it into an exploit | Wiz says it needed “an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve”. | Wiz says frontier models let it build and adapt working exploits across several applications in hours. |
| Adapting it to each target | Each version, setting and memory layout needed fresh analysis, testing and debugging. | Wiz says LLMs can help adapt an exploit to different PHP versions, configurations and memory layouts. |
| Checking the fix | Maintainers test patches by hand and with their own tools. | OpenAI says its process includes adversarial testing with frontier models to look for ways around the patch. |
Quotes and claims are Wiz’s, the PHP Foundation’s and OpenAI’s. None was independently tested, and Wiz sells security products.
Google DeepMind’s Raluca Ada Popa is quoted on Wiz’s post as saying Gemini 4 Argon helped defenders bridge that gap, and Wiz credits Argon with finding the vulnerability, building exploits, creating attack detection and validating the patch.[4]
How AI helps defenders now
The PHP Foundation says AI helped on its side too. Earlier in 2026 it worked with Alpha-Omega to scan PHP with Anthropic’s Claude Mythos, and has since added other tools including OpenAI’s Daybreak Red for validating reports and exploits.[6] The growth of AI-assisted research also means far more reports: the team has published 15 CVEs since 1 July and worked through more than 100 reports that were invalid, duplicates or not reproducible.[6] AI helps validate reports and group those with a shared root cause, but, the Foundation says, “a person makes every call and works on every patch”.[6]
OpenAI says that over two months it led a coalition of maintainers, researchers and security providers on the PHP response, and its proposed framework includes adversarial testing with frontier models to look for ways around a patch and related variants.[7] It says it worked with infrastructure providers on protections, and engaged parts of the US government, including the White House’s Super Intelligence Force, the Office of the National Cyber Director and CISA.[7] Wiz thanks Automattic, Akamai, AWS, Cloudflare, Fastly, Google, Imperva, Microsoft, Vercel and others for preparing guidance and mitigations for customers who could not patch at once.[4]
The attackers’ clock
OpenAI says that, to its knowledge, frontier AI found these vulnerabilities before attackers did.[7] Amazon’s evidence is more complicated. Its MadPot honeypots logged a PHP2Shell exploit attempt on 17 October 2026 from an address linked to a commercial anonymisation network, four days before disclosure, and Amazon says it remains unclear how the actor acquired exploit information.[8] On 21 October the earliest proof-of-concept exploits it saw appeared around 02:00 UTC, some 12 hours before the 14:00 UTC release, and more attempts followed from different infrastructure, which Amazon says suggests multiple actors.[8]
The Register, relaying Cloudflare’s chief executive Matthew Prince, reported thousands of exploitation attempts in the 10 hours before public announcement, tens of thousands within 45 minutes of disclosure, hundreds of thousands within two hours, and millions since.[9] Cloudflare also said attackers were tweaking payloads to get past its web application firewall, apparently using feedback from blocked requests.[9] The Register does not say whether any of this used AI, and neither do we claim it.
- 10 hours before disclosurethousands
- 45 minutes after disclosuretens of thousands
- 2 hours after disclosurehundreds of thousands
- Sincemillions
Exploit attempts that Cloudflare reported, as relayed by The Register. Bar lengths are our illustration of the order of magnitude, not measured values. Attempts are not successful compromises.
Security firm Hadrian said PHP2Shell was being “exploited in the wild at scale”.[9] iTWire, citing Palo Alto Networks’ Unit 42, reports more than 22 million exposed PHP instances worldwide and more than 200 proof-of-concept exploits across repositories within hours.[2]
Wiz states why AI matters here: “With AI this is no longer a barrier. LLMs can help adapt an exploit to different PHP versions, configurations and memory layouts.”[4] OpenAI says the same capabilities that find vulnerabilities can help attackers rapidly develop offensive tools and exploits.[7] Keeper Security’s Shane Barney, quoted by iTWire, sums it up: “The result is a shrinking window between vulnerability disclosure and potential exploitation.”[2]
Impact: governments, Wikipedia and more
Australia’s Signals Directorate and its cyber centre issued a critical alert on 21 October saying all PHP versions from PHP 5 onwards may be affected, according to iTWire, and that night cyber.gov.au and other federal sites went dark.[2] A spokesperson for Home Affairs Minister Tony Burke told the ABC that the National Office of Cyber Security was aware of “disruptions to several Australian websites” and that “some websites are temporarily unavailable as work is undertaken to mitigate risks arising from this vulnerability.”[2] iTWire notes that GovCMS, a Drupal platform behind a large part of Australia’s federal web presence, runs on PHP.[2]
In Europe, the BBC reports Finland temporarily shut down the government’s public web services, and the Netherlands’ cyber-security agency took its own website offline, as did the country’s health institute RIVM, while the lower house of parliament became inaccessible.[1] iTWire lists government sites in France, Finland, Denmark and the Netherlands, along with the Port of Rotterdam, 4chan and Something Awful.[2]
- Australia
cyber.gov.au and other federal sites
iTWire reports they went dark on the night of 21 October. A spokesperson for the Home Affairs Minister cited “disruptions to several Australian websites”.
- Finland
Government public web services
The BBC reports Finland temporarily shut down the government’s public web services.
- Netherlands
The cyber-security agency’s own site, RIVM, the Tweede Kamer
The BBC reports the agency took its own website offline, and that the health institute and the lower house of parliament became inaccessible.
- Wikimedia
A number of systems, taken down “as a precautionary measure”
Some people could not reach parts of Wikipedia on Wednesday, the BBC reports.
- Others
France, Denmark, the Port of Rotterdam, 4chan, Something Awful
Listed by iTWire. The BBC says Edinburgh council and some BBC programme sites were also inaccessible, with no confirmed link to PHP.
A partial list from two outlets. Reasons for each outage were mostly not given by the sites themselves.
Wikipedia runs on MediaWiki, which Wiz lists among the PHP platforms.[4] The Wikimedia Foundation said it was addressing the vulnerabilities and that “We have taken down a number of other systems as a precautionary measure until they can be safely patched.” The BBC reports that some people could not reach parts of Wikipedia on Wednesday.[1] The Foundation did not say which systems, and we could not confirm that Wikipedia as a whole went down.
The US National Security Agency advised organisations on X to take their systems offline if they could not update, writing that “These vulnerabilities often provide a direct path to the server’s file system or database”, and the White House said federal agencies were working with leading AI labs to speed up a fix, the BBC reports.[1] Japan’s Prime Minister, Sanae Takaichi, urged people on X to check whether their public websites ran on PHP.[1]
How bad was the damage? Mostly this was precaution. The Register reported on 23 October that, despite mass exploitation attempts, no successful compromises attributed to PHP2Shell had been publicly confirmed, and quoted the PHP Foundation’s executive director, Elizabeth Barron: “We have no evidence of successful exploitation of the two vulnerabilities from Wednesday prior to disclosure, and we currently have no evidence of any exploitation of these vulnerabilities on patched PHP versions.”[10]
Most outages were precautions
A confirmed compromise count
This can change. Exploit attempts are reported in the millions, and evidence of a past breach may take time to surface.
Experts quoted by iTWire drew a wider lesson. Murdoch University’s David Parry said site owners might not even know they use PHP, and that unlike a commercial product there is no customer list for a seller to contact.[2] Swinburne’s Dimitrios Salampasis asked whether governments and businesses have sufficient visibility of their technology.[2]
A disclosure under pressure
The coordinated release was meant for 22 October at 14:00 UTC. The PHP Foundation says the two CVE IDs began circulating on Tuesday 20 October at about 15:00 UTC, with a wrong release time and a wrong score of 10.0, so PHP published a pre-announcement at 19:30 UTC and moved the release forward a day.[6] It adds that Calif then mistakenly published a video of its proof of concept, and that Chainguard published built images containing the fix at 07:41 UTC on 21 October, more than six hours before the release.[6]
- 1
Tuesday 20 October, about 15:00 UTC: the two CVE IDs circulate online, with a wrong release time and a wrong score of 10.0.
- 2
19:30 UTC: PHP publishes its pre-announcement and moves the release from 22 to 21 October.
- 3
About 20:00 UTC: Calif publishes, then deletes, a video of its proof of concept. Copies spread.
- 4
21 October, 07:41 UTC: Chainguard publishes built images containing the fix, per the Foundation.
- 5
14:00 UTC: the coordinated release.
The PHP Foundation’s account. Chainguard’s chief executive told iTWire he made the call “when exploits hit in the wild”; Amazon’s earlier sighting is on 17 October.
The Foundation said Chainguard “unilaterally broke the embargo”, according to iTWire. Chainguard’s chief executive, Dan Lorenc, apologised for the extra stress on maintainers but defended the decision: “I made the call to get these out early when exploits hit in the wild.”[2] Amazon’s 17 October sighting shows at least one actor was already trying before that.[8]
The story did not end on 21 October. The PHP Foundation told The Register it has reserved CVE-2026-115560 for a third remote-code-execution flaw, which it says “requires a very unlikely combination of configuration and specific PHP application code”, and will handle in its next regular release with a configuration setting as the interim mitigation.[10]
What AI changes next
The people who found PHP2Shell expect more of it. OpenAI says these bugs are among several significant vulnerabilities it has already found and is working to fix, and expects similar findings to “increase sharply in the coming months”.[7] iTWire quotes OpenAI president Greg Brockman: “We expect to find many more such issues over upcoming months.”[2]
People, fuzzers, and one early AI win
AI finds the bug and builds the exploit
More findings, shorter windows
Each column summarises claims from the sources named in the text. “Next” is what named parties expect, not something we can show.
OpenAI proposes a five-stage framework for such cases: validate and fix upstream, give affected organisations time to act, coordinate with government partners, prepare updates across products, then publish guidance and support deployment.[7] It also asks the security community hard questions, including when, if ever, governments or other operators should use a vulnerability to patch systems they own or are authorised to manage after losing administrative access.[7]
Wiz argues for making this routine. It describes the opportunity as systematically finding flaws in existing software and catching new ones before they reach production.[4] The PHP Foundation, for its part, says tools find bugs faster than ever for defenders and attackers alike and that the number of reports will keep growing, but that tools cannot decide the right fix for a long-standing design decision, weigh compatibility trade-offs or review the patch.[6]
Find and fix before attackers do
The same tools, faster
A repeatable response
Maintainers are the bottleneck
Forecasts by named parties, not facts. OpenAI and Wiz both sell AI or security products.
Reaction is split. Tufts University’s Shaanan Cohney, quoted by iTWire, says the “window between announcement and exploit discovery has collapsed”, so the vulnerability disclosure process needs rethinking.[2] Swinburne’s Belinda Barnet is more critical of the makers of AI: “It’s like a massive weapons manufacturer offering us safer helmets.”[2] La Trobe’s Shalinka Jayatilleke offers a practical line: AI investment “must be matched by investment in maintenance, human expertise and incident preparedness.”[2]
- Alarm
Wiz: “most severe vulnerabilities ever discovered” by AI
As the BBC quotes it. Tenable’s Satnam Narang, via iTWire, called it among the most consequential events since Log4Shell.
- Caution
The PHP Foundation: the third bug is unlikely
Executive director Elizabeth Barron said it needs a “very unlikely combination” of settings and code, so no emergency fix.
- Critique
Dr Belinda Barnet, Swinburne University
Quoted by iTWire: “It’s like a massive weapons manufacturer offering us safer helmets.”
- Capacity
Dr Shalinka Jayatilleke, La Trobe University
Via iTWire: AI investment “must be matched by investment in maintenance, human expertise and incident preparedness.”
Opinions of named people, as reported. We do not endorse any of them.
What to do
If you run PHP anywhere, the PHP project’s advice is simple: update, because only an update is a complete solution.[3] iTWire relays more from the industry. Qualys’s Saeed Abbasi advises inventorying hidden PHP in containers, cloud images, hosting panels and vendor appliances, then restarting web workers and containers so the fix takes effect, and Securonix’s Chris Jacob advises hunting for suspicious POST or multipart requests, memory exhaustion and repeated worker crashes, and rotating all database credentials and API secrets if code execution is suspected.[2]
- 1
Find every PHP in your estate: servers, containers, cloud images, hosting panels and appliances that bundle it.
- 2
Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor’s patched package, then restart web workers and containers.
- 3
On PHP 8.1 or older, move to a supported version, or use a vendor backport.
- 4
If you cannot update now, apply the PHP project’s listed mitigations and treat them as partial.
- 5
Keep logs. Look for odd multipart POSTs, memory-limit errors, repeated worker crashes and processes started by PHP.
- 6
If code execution is suspected, isolate and rebuild the system, then rotate database credentials and API secrets.
Assembled from the php.net advisory and the advice of Qualys and Securonix as relayed by iTWire. Follow your own security team and vendor.
If you are only a visitor, iTWire reports Malwarebytes saying you do not need to install anything on your own devices, though you should expect some sites to be down for a while and be wary of unexpected redirects and fake update prompts.[2]
What nobody knows yet
Several big questions are open. There is no confirmed count of compromised sites, no explanation of how the actor in Amazon’s data knew about the flaws four days early, and no agreed answer on how far back the vulnerable versions go, since Wiz says PHP 5.4 and CERT-EU, quoted by the BBC, says PHP 5.[4][1] The BBC also says it could not verify the 70% figure.[1]
- Harm
How many sites were actually compromised
No confirmed count in the sources, as of 23 October.
- Origin
Who tried the exploit four days early, and how they knew
Amazon says it remains unclear how the actor acquired exploit information.
- Scale
The real share of the web affected
“Roughly 70%” is Wiz’s figure; the BBC says it could not verify it.
- Versions
How far back the flaws go
Wiz says to PHP 5.4; CERT-EU, via the BBC, says PHP 5 onwards.
- AI role
How much the AI contributed versus the people
The firms describe large gains; none has published a controlled comparison.
What we could not find in the sources on 24 October 2026.
The message
PHP2Shell is a case in which, by the finders’ own account, AI helped both to find flaws in the code behind much of the web and to make them practical to exploit, and the world’s response was to switch sites off. The outages look mostly precautionary so far, and the defenders appear to have got there first, but the sources agree on one uncomfortable point: the gap between a bug being known and being used is shrinking. The slowest part of the system is still people deciding, fixing and patching.
AI-assisted researchers found these flaws before anyone is known to have been harmed; the next ones will be found faster, so the real test is how quickly everyone patches.
Quick quiz
Tap a question to check your answer.
Q1What are the two flaws called, and what do they allow?
CVE-2026-109618 and CVE-2026-109619, together called PHP2Shell. The PHP project says both can allow unauthenticated remote code execution.
Q2Which PHP versions fix them?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive updates, though minimal source backports were published for 7.4, 8.0 and 8.1.
Q3Who found them, and which AI models were used?
Calif, with GPT-5.6 Sol, in OpenAI’s Patch the Planet, and Wiz independently, with Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol.
Q4Were the sites that went offline hacked?
The sources describe most shutdowns as precautions. The Register reported on 23 October that no successful compromises had been publicly confirmed.
Q5What did Google’s Project Zero report in November 2024?
That its Big Sleep agent found an exploitable bug in SQLite, which it believed was the first public example of an AI agent finding such a flaw in widely used software.
References
The sources behind this article: original papers, official announcements and documentation. Each link was opened and checked on ; documentation without a fixed date is cited as it read that day.
- [1]
Gerken, T., Cress, L. and Tidy, J. (21 October 2026). Websites taken down worldwide as critical cyber-security update issued. BBC News.
Reporting · Supports: Governments and agencies urging sites offline, Finland, the Netherlands, Edinburgh council, the Wikimedia Foundation’s statement, the NSA and White House responses, Wiz and OpenAI quotes, and the BBC’s caveat on the 70% figure
- [2]
Zaharov-Reutt, A. (23 October 2026). PHP2Shell: the 14-year-old bugs that pulled cyber.gov.au and government sites worldwide offline. iTWire.
Reporting · Supports: Australia’s alert and outages, sites in France, Finland, Denmark and the Netherlands, the database explanation, the Chainguard exchange, Greg Brockman’s quote, Unit 42’s counts and many expert comments
- [3]
The PHP project (21 October 2026). Security advisory: Critical remote code execution vulnerabilities, update now. php.net (opened in a browser, 24 October 2026).
Announcement · Supports: The two CVEs, who is at risk, fixed versions, backports for 7.4, 8.0 and 8.1, and the interim mitigations
- [4]
Tzadik, S., Tamari, S., Ohfeld, N. and Schwartz, T. (Wiz Research) (21 October 2026). PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet. Wiz Blog (opened in a browser, 24 October 2026).
Announcement · Supports: Wiz’s discovery timeline, the AI tools used, its “single researcher in a week” claim, the exploit demonstrations and the AI inflection argument
- [5]
Big Sleep team (Google Project Zero and Google DeepMind) (1 November 2024). From Naptime to Big Sleep: Using Large Language Models To Catch Vulnerabilities In Real-World Code. Project Zero.
Announcement · Supports: The 2024 SQLite finding, the “first public example” claim, and the view that fuzzing misses variants
- [6]
The PHP Foundation (21 October 2026). Today’s PHP Security Release, and How We’re Strengthening PHP Security. The PHP Foundation.
Announcement · Supports: The 2024 audit and stalled fix, the reports from Calif and OpenAI, AI tools used by the team, report volumes, and the leak and embargo timeline
- [7]
OpenAI (21 October 2026). Patch the Planet: global response coordination as agents uncover critical vulnerabilities. OpenAI (opened in a browser, 24 October 2026).
Announcement · Supports: Calif’s use of GPT-5.6 Sol, the coalition, government engagement, the five-stage framework, and the expectation of more findings
- [8]
Moses, CJ (Amazon Threat Intelligence) (21 October 2026). Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. AWS Security Blog.
Announcement · Supports: The 17 October honeypot attempt and the proof-of-concept exploits seen on release day
- [9]
Page, C. (22 October 2026). Hackers pile on PHP2Shell as AWS reveals attacks began before disclosure. The Register.
Reporting · Supports: Cloudflare’s exploit-attempt counts, payload tweaking, Hadrian’s warning
- [10]
Lyons, J. (23 October 2026). There’s a third PHP2Shell bug, but it won’t get an emergency fix. The Register.
Reporting · Supports: CVE-2026-115560, the PHP Foundation’s statement on no confirmed exploitation, and the absence of publicly confirmed compromises as of 23 October
How this article was made
Researched and drafted with the help of AI assistants, checked against the sources above, and published by Mrinal Singh Raja as general information, not professional advice. Facts come from the sources listed and may change, so please check them before relying on them. Spotted a mistake? Tell us and we will correct it. Our editorial standards explain how AI is used here.
PHP is made by the PHP project and supported by the PHP Foundation. GPT-5.6 Sol is made by OpenAI, Gemini 4 Argon by Google, and Wiz Atlas by Wiz; Calif, Cloudflare, Amazon, Chainguard, Wikimedia and the other organisations named are independent of MSRX, and this article is not affiliated with or endorsed by any of them. We read the pages and reports listed on 24 October 2026; nothing was entered or submitted. Quotes are word for word from the linked sources. Facts were checked on 24 October 2026 and may change as the incident develops. Screenshots are of public pages and belong to their owners. We did not test any exploit and publish no exploit detail.