When word of two critical PHP flaws began circulating late on October 20, attackers moved almost immediately. Cloudflare saw "tens of thousands" of exploit attempts within 45 minutes of the news getting out, according to Fortune, citing Cloudflare co-founder and CEO Matthew Prince. That rose to hundreds of thousands within two hours and to millions by the evening of October 21. Amazon Web Services said it had seen some exploitation attempts in the days before the vulnerability was officially disclosed, which suggests the details may have leaked before the announcement.
One detail in that timeline matters more than any other. Those first 45 minutes came before the patch was out. The PHP project had posted only an advance notice that a fix was coming, scheduled for October 21 at 14:00 UTC. So the honest version of the title question is harder than it sounds. It is not only about how fast you can install a fix. It is about what your team can do in the hours when no fix exists yet.
What php2shell actually is
The two flaws, CVE-2026-109618 and CVE-2026-109619, are known together as php2shell. PHP's own advisory says they can allow unauthenticated remote code execution and that every PHP installation serving web requests is at risk. Because the bugs sit in the PHP runtime and not in any one application, Cloudflare points out that updating website code or plugins alone does not fix them. Someone has to update PHP itself, or ask the hosting provider to do it.
The scale is large. Palo Alto Networks' initial analysis found 22.6 million potentially vulnerable instances, Fortune reported. Some government agencies in the Netherlands and Finland took websites offline as a precaution.
AI is part of this story on both sides. Calif, OpenAI and Wiz all used AI tools to find the flaws, one of which Brockman said had been sitting in PHP for 14 years. OpenAI warned that the same capabilities "can also help attackers rapidly develop offensive tools and exploits."
The attackers were fast. They were not yet very good.
It is worth being precise here, because the headline numbers can be misleading. An exploit attempt is not a breach. Wiz, which has been watching its own honeypots, reported on October 27 that it had seen a limited number of exploitation attempts and none that completed the attack chain. Wiz found that one public exploit kit was stopped by a server's ordinary 8 MB upload size limit. Another got further but could not get the memory information it needed to finish. Wiz's view is that turning a lab exploit into something reliable across different setups is hard, but it also expects those barriers to diminish over time. And Wiz notes that some scanners did successfully exploit an independent researcher's honeypot, which likely contributed to CISA adding php2shell to its Known Exploited Vulnerabilities list.
My read is that this is a warning, not a reprieve. The fast, high-volume attempts are the cheap first wave. The competent second wave comes later, and nobody can tell you exactly when. In the meantime, the first wave tells you something important: someone is already testing your door at scale within the first hour.
What fast defenders actually did
The groups that came through well did not rely on a fast patch alone. Cloudflare says it had firewall protections in place about nine hours ahead of public disclosure, covering its free and paid customers by default. PHP gave operators a day's notice and told them to prepare. Linux distributions received the patches in advance. The advisory also listed temporary configuration changes, such as lowering upload size limits, while being clear that these reduce exposure but do not make an installation safe.
That gives you a three-layer model to measure your own process against:
- Minutes: can you put a filter in front of exposed systems, or take a service offline, without a week of approvals?
- Hours: can you apply vendor-recommended configuration changes across every affected server, including the ones nobody remembers owning?
- Days: can you test and deploy the real patch, then confirm it actually landed?
Each layer depends on something that has to exist before the crisis. You need an accurate list of what runs PHP and where, a named person with authority to make the call to pull a public site, and pre-approved emergency change rules. If any of these gets built during the incident, the 45 minutes are already gone.
So how long would your team take?
The best benchmark available is not flattering. Wiz telemetry shows that one week after public disclosure, fewer than 53% of initially affected organizations remain vulnerable. That is real progress. It also means close to half of the organizations Wiz could see were still exposed seven days into a vulnerability that attackers had started probing within the first hour.
If you have not tested your process, my honest answer to the title question is that your team would probably take days. That is roughly how long the typical affected organization in that data took, and attackers had started on the first day. Days was an acceptable answer when the gap between disclosure and a working attack was measured in weeks. With AI helping people find buried flaws and build exploits quickly, that gap is shrinking, and php2shell shows attempts can begin before disclosure is even official.
The goal I would set is this. Have a protective control in place within the first hour of credible news, even if that means taking a site offline. Apply vendor mitigations to all internet-facing systems the same day. Get the real patch onto critical exposed systems within 24 to 48 hours, and verify it. Few organizations can do all of that today. The ones that can will not have improvised it. They will have rehearsed it, and the next disclosure is a good time to find out which group you are in.
Sources
- AI tools discovered the PHP vulnerability that could take down 70% of the internet. Now, the race is on to patch it before AI-powered hackers attack (Fortune, 2026-10-21)
- News Archive - 2026 (Security advisory: Critical remote code execution vulnerabilities, update now) (PHP.net, 2026-10-21)
- Cloudflare deploys protections against php2shell vulnerability (Cloudflare, 2026-10-21)
- PHP2Shell: Exploitation Attempts and Remediation Trends (Wiz, 2026-10-27)
