PHP2Shell, found in a week and fixed in seventy-one days
On 21 October Italy's Interior Ministry took the websites of its prefectures offline. There had been no attack: it was waiting to install a fix. On the same day the German federal government's IT provider and the Belgian foreign ministry also switched off some public websites as a precaution.1
The cause is two flaws in PHP, the language that runs WordPress, Drupal and 69.3% of the websites whose server-side technology is known.2 They have been named PHP2Shell: they let anyone, without a password, make the server run commands. Italy's National Cybersecurity Agency rated them critical, with a score of 9.2 out of 10.3
They were found with AI. On 1 August Ryan Austin, a researcher at Calif invited by OpenAI into its Patch the Planet project, found the first one by reviewing the code together with a language model, and on 11 August he reported it to the PHP developers. Austin stresses that no model finds "all bugs" with simple prompts: what counted was his knowledge of PHP's old flaws.4 On 19 August a Wiz researcher got there independently, using Gemini 4 Argon and GPT-5.6 Sol. According to Wiz, one person needed a single week.5
The fixes came out on 21 October, seventy-one days after the first report. The PHP Foundation explains that the first signs of one of the two problems had surfaced back in 2024, during a code review, and that the fix had then been stuck for months between competing approaches. PHP's security work, it writes, rests on a small group of developers paid by the foundation and a little volunteer help.6
The attacks did not wait. Amazon recorded the first attempt on 17 October, four days before the fix.7 On 20 October the embargo broke and the details spread online. According to what Matthew Prince, who runs Cloudflare, wrote on X, attempts went from a few thousand in the ten hours before the announcement to tens of thousands in the 45 minutes after it, and then to millions.8 On 23 October the ACN added a third, related flaw that also affects versions that have already been updated.3
PHP2Shell, the time to find it and the time to fix it
And some will never get the fix. The updates cover versions 8.2 to 8.5; for 8.1 and earlier, which are no longer supported, CSIRT Italia warns that no official patches will come.3 According to W3Techs, more than one PHP site in three still runs on version 7 or 5.2
PHP websites, by version
PHP2Shell is the most visible case of what has been happening for a few months: with AI a flaw can be found in a few days, fixing it takes months, and attackers get there before the fix. The figures of recent months say it is not an isolated case.
Six thousand flaws reported, five hundred fixed
On 7 April Anthropic launched Project Glasswing. A group of companies that run critical software, including Amazon, Apple, Google, Microsoft and the Linux Foundation, got access to Claude Mythos Preview, a model that is not on sale, to look for flaws in their own systems before anyone else found them. Anthropic put up to 100 million dollars of credits on the table for using the model, plus 4 million in donations to organisations that look after the security of open-source software.9
On 6 October came a new tally. Between April and July the partners found at least 129,000 verified vulnerabilities, and more than 33,000 of them have been rated critical or high severity. Anthropic points out that the count is partial, because it rests on reports from 33 partners. On fixes, though, there is no total: fewer than half the partners said how many flaws they had dealt with, often because the work was still under way.10
For open-source software, written and maintained in public, often by volunteers, Anthropic keeps a ledger. As of 2 October the model had proposed 29,439 possible flaws. Of those, 6,157 had been reported to the maintainers, the people who look after each project, across 591 projects. The ones fixed, as far as the company knows, numbered 516: just over one in twelve.11 The ledger warns that the figure lags, partly because some maintainers fix code without announcing it, and that a published fix is not yet an installed fix.
As early as 22 May the company had written that the limit was no longer finding bugs, but the human capacity to triage them, report them, and design and roll out the fixes. Several maintainers had said they were "severely capacity constrained", and some had asked for reports to be slowed down so they had time to write the patches.12
The window has closed
The problem would be smaller if there were time. Mandiant, the incident response firm that is part of Google, has for years measured "time to exploit": how many days pass, on average, between the release of a fix and the first attack that uses that flaw. In 2018-2019 it was 63 days; in 2023, five.13 In the M-Trends report published on 23 March 2026, covering 2025 cases, the estimate is minus seven: on average the attack comes a week before the fix.14
How much time is left before the attack
| Period | Average time between the fix and the first exploitation |
|---|---|
| 2018-2019 | 63 days after |
| 2020-early 2021 | 44 days after |
| 2021-2022 | 32 days after |
| 2023 | 5 days after (47 counting 15 outliers) |
| 2025 | 7 days before, estimate |
The International Monetary Fund got there by another route. In its October financial stability report it lists cyberattacks among the growing risks for markets, and in the accompanying commentary it writes that in more than 70% of the cases reported this year, software providers had almost no time to fix a flaw before attackers exploited it. In 2021 the share was less than half that, and there were typically close to 300 days for the fix.15
The models that find flaws are the same ones that, in other hands, help exploit them. On 3 September OpenAI wrote that GPT-6 Astra is its first model to reach the "Critical" level of cyber capability in its risk assessment framework: with the right tools and access it finds unknown flaws and builds new ways to exploit them across many well-protected systems, without a person guiding each step.16 How little it costs a criminal to chain these capabilities together I described in the piece on 25-dollar attacks on online shops.
The people who fix are falling behind
On the other side are those who have to install the fixes. Verizon's 2026 Data Breach Investigations Report, released on 20 May, tracked across more than 13,000 organisations the flaws in the KEV catalogue, the list of already-exploited vulnerabilities kept by CISA, the US cybersecurity agency. In 2025 only 26% had been fully fixed, down from 38% the year before. The median time to close them rose from 32 to 43 days.17
Verizon does not blame laziness. In 2025 organisations fixed 63.7 million instances before the flaw even entered the catalogue, 30% more than the year before. But volume grew faster: in Verizon's sample, vulnerability detections went from 68.7 million in 2022 to 527.3 million in 2025, almost eight times as many. The authors describe "a treadmill picking up speed". And these are 2025 figures, from before the new models of the spring.
When a paid team stands behind a project, the chain holds. Mozilla, testing Mythos, found and fixed 271 vulnerabilities in Firefox 150, more than ten times the number found in Firefox 148 with Claude Opus 4.6.12 In open-source projects the weight often falls on volunteers. At the end of October 2025 the maintainers of FFmpeg, the library that reads audio and video in a huge number of programs, received a report from Big Sleep, Google's AI-based tool, about a flaw in the decoder for an old LucasArts format used in the opening frames of a 1995 video game. They fixed it, then asked publicly whether it is fair for trillion-dollar corporations to use AI to hunt for security issues in code other people write as a hobby. Under Google's rules, the flaw becomes public after 90 days, fixed or not.18 I described the same imbalance, in the Linux kernel and in curl, when writing about who checks the code AI writes.
Yet writing a fix is something AI can already do. In the final of DARPA's AI Cyber Challenge, in August 2025, the seven teams' systems found 54 of the 63 flaws deliberately planted in the code and fixed 43 of them, in 45 minutes on average, at an average cost of about 152 dollars per task. They also found 18 real flaws nobody knew about and proposed 11 fixes.19 The bottleneck comes afterwards: someone has to read the fix, test it, approve it and install it on every computer that runs that software.
In Italy, 77,000 flaws in nine months
Italy's National Cybersecurity Agency (ACN) publishes a monthly summary with the number of new vulnerabilities recorded worldwide by the CVE programme, the public catalogue that gives each flaw an identifier. In September 2026 there were 15,074, more than three times the 4,515 of September 2025. In the first nine months of the year there have been more than 77,000. The ACN speaks of "unprecedented growth", arriving as frontier AI models cut the time needed to analyse code, hunt for vulnerabilities and build proofs of exploitation.20
New vulnerabilities recorded worldwide, month by month
In the same month CSIRT Italia, the ACN's operational team, found 8,213 systems and services exposed to risk and sent 10,839 notices to public bodies and companies, some of them under Law 90 of 2024. Exploiting vulnerabilities was the main way into the systems that were hit.20
Law 90 covers central public administrations, regions, metropolitan cities, municipalities with more than 100,000 inhabitants, local health authorities and some public transport companies. When the ACN alerts them to a specific vulnerability, they must apply the indicated remedy "without delay and in any case no later than fifteen days from the notice". Those who fail to do so face a fine of 25,000 to 125,000 euros, unless there are justified technical or organisational reasons reported in time.21 If Mandiant's estimate is right, the attack on average begins before the fix even exists. Fifteen days is a ceiling, and it often comes too late.
Since 11 September the EU's Cyber Resilience Act has required manufacturers of products with digital elements to report vulnerabilities that are already being exploited: an early warning within 24 hours, which reaches the designated national CSIRT and ENISA, a fuller notification within 72 hours and a final report within 14 days of the fix becoming available.22 ENISA opened the single reporting platform for these notifications on the same day.23
What I think
I think Glasswing's figures are half good news. Finding a flaw before criminals do is useful if someone then closes it; otherwise it remains a list of open doors which, under the 90-day rule, sooner or later becomes public.
PHP2Shell adds a detail that matters. Finding the two flaws took one researcher and one week, fixing them took seventy-one days, and one of the two had been glimpsed two years earlier without anyone having the time and the agreement to close it. The bottleneck lies with the few people who keep alive a piece of software used by two websites in three.
In Glasswing's case the money goes mainly to the people who search: up to 100 million dollars in credits for using the model, 4 million for organisations that support open-source security. I give Anthropic credit for one sound choice: it publishes the ledger with the number of fixes, even though that number does not flatter the company. But the ratio between the two sums shows where the imbalance lies.
The rule I would like to see is simple: anyone using AI to find flaws in other people's code brings, together with the report, a proposed and tested fix. DARPA's final shows that, at least in a test setting, it can be done in under an hour. The maintainer still has to check it, but the work left is shorter.
For companies and public bodies I would look above all at one number: how many days it takes to close a flaw that is already being exploited. I would bring it to the board and to the town council, next to the budget, because it is what decides how long a door stays open.
Where to start
Anyone with a WordPress site or an online shop has one thing to do before everything else: ask their hosting provider which PHP version the site runs on. It should be one of those fixed on 21 October (8.2.35, 8.3.36, 8.4.27 or 8.5.12) or a later one, with the measures the ACN recommends for the third flaw. If the site runs on PHP 7 or anything older, the only fix is moving to a supported version.
For a mid-sized company or a local authority I would start with four steps. None of them needs an AI model.
- InventoryKnow what is exposedAn up-to-date list of servers, remote access devices, websites and plugins reachable from the internet. An alert only helps someone who knows they run that product.
- PriorityAlready-exploited flaws firstCISA's KEV catalogue and CSIRT Italia's alerts say which flaws attackers are already using. Those get closed in days; the rest can follow the normal cycle.
- AutomaticUpdate without waitingAutomatic updates wherever possible, for operating systems, browsers and CMSs. Where that is not possible, a fixed maintenance window every week.
- ContractsFix times in writingAsk suppliers how many years of updates they guarantee and within how many days they release a critical fix. If they cannot answer, that is a risk to put in the budget.
The first figure to collect is an internal one: how many days passed, the last time, between a CSIRT Italia alert about a product in use and the installation of the fix. It should be compared with the fifteen days of Law 90 and with the minus seven of Mandiant's estimate.