Key Takeaways
- PHP2Shell is a pair of critical PHP flaws that let attackers take over servers without a password, putting roughly 70% of the world’s websites at risk.
- The underlying bug sat undiscovered for over a decade until AI tools made it practical to find and exploit.
- Cloudways patched every supported PHP version, including older ones no longer officially supported, within 48 hours of the public disclosure.
- Patching protects your site going forward, but checking for signs of prior compromise is still worth doing on your own.
On October 21, the PHP Group released emergency patches for two critical security flaws. Together, these two flaws are now known as PHP2Shell.
PHP is a programming language that runs behind the scenes on websites, and it powers a major part of the internet. Well-known platforms like WordPress, Drupal, and Laravel all run on it.
According to Wiz, the cybersecurity firm that helped discover this flaw, PHP runs on roughly 70% of the world’s websites. That includes WordPress, the software that powers a large share of the world’s blogs, online stores, and business websites. Because so much of the internet depends on PHP, a flaw this serious didn’t stay contained to a handful of websites.
The US National Security Agency told government agencies to take systems offline if they couldn’t patch immediately. Japan’s Prime Minister personally asked citizens to check their own websites. Some organizations chose to take their own sites offline as a precaution while they checked for exposure.
Unfortunately, some Cloudways customers experienced disruption too, as part of that same industry-wide response.
What PHP2Shell Actually Does?
PHP2Shell is the name given to two separate flaws that were fixed in the same emergency release.
- The first, CVE-2026-109618, happens when a server runs out of memory partway through handling a request.
Normally, if a server runs low on memory while handling a request, PHP stops and throws away the data it hasn’t finished using.
This bug breaks that process. PHP ends up using the unfinished data anyway, treating it as if it were complete and correct.
An attacker can create that unfinished data in a specific way so that, when PHP executes it, the server runs commands the attacker wrote.
- The second, CVE-2026-109619, works differently but causes the same kind of risk. A server handles many visitors one after another. To save time, it reuses the same internal process for each new visitor rather than starting fresh each time.
This bug means that some data from one visitor’s request can remain in the process after it should have been deleted.
When the next visitor’s request uses that same process, it can accidentally read the old data that was left behind. The server then treats that old data as if it belongs to the new visitor.
An attacker can deliberately cause this to happen. If they do, the result is the same as the first flaw; they can take control of the server. Both flaws are rated 9.2 out of 10 in severity, under a standard industry scale called CVSS.
The bug exists inside PHP’s own code. How a server is configured to run PHP can affect how easy that bug is for an attacker to actually use.
One specific setup is called mod_php, a common way of running PHP. Researchers showed a working attack against a server using this setup, one that worked before the website’s own code even had a chance to run.
Neither flaw required a password, a login, or any action from a website visitor. A server only had to be reachable on the Internet. That’s exactly why this spread so fast, and why the response that followed was so large.
The Global Response to PHP2Shell
Within hours of the public announcement, attacks against PHP2Shell were already measurable at scale.
According to BBC reporting, Cloudflare’s chief technology officer, Matthew Prince, said his company saw thousands of attempts to break in during the ten hours before the vulnerability was publicly disclosed.
“Some stats on #php2shell. In the 10 hours before it was publicly announced, across the @Cloudflare network we saw thousands of attempts to exploit it. That jumped to tens of thousands in the 45 minutes post announcement, hundreds of thousands within 2 hours, and millions now.” Matthew Prince – X.
That number climbed to tens of thousands within 45 minutes of the announcement, then hundreds of thousands within two hours.
Organizations responded by taking real action. Wikimedia, the organization behind Wikipedia, took several of its own systems offline as a precaution while it checked for exposure.
The Finnish government temporarily shut down its public web services, and the Netherlands’ cybersecurity agency pulled its own website too.
In the UK, the government took 32 of its own sites offline as the same kind of precaution. The Edinburgh council’s website also became inaccessible, along with pages for several BBC programs, though neither has confirmed the disruption was actually linked to PHP.
In the early hours of the incident, some of the information circulating wasn’t fully confirmed yet. CERT-EU and Australia’s cybersecurity center both said the flaw could affect every PHP version going back to PHP 5, which launched in 2004.
Both agencies later clarified where that claim actually came from. It was based on early social media reports, not on anything PHP itself had confirmed. At that point, PHP hadn’t yet said which versions were actually vulnerable. This is worth noting because it shows how uncertain the first few hours of an incident like this can be, even official warnings can be based on information that hasn’t been fully verified yet.
Despite the scale of the response, Australia’s Cyber Security Center said in the days immediately following disclosure that it wasn’t aware of any active attacks that had actually succeeded.
Why a Decade-Old Bug Became a Crisis Now?
Neither of these flaws was new. According to the incident’s public record, a PHP core developer actually noticed the underlying memory error behind one of them during a routine audit back in 2024. The bug went unfixed for two years.
The PHP Foundation has since said publicly that its security team considered several possible fixes. Each one came with a tradeoff, i.e., breaking backward compatibility, introducing a new kind of instability, or forcing changes across thousands of third-party extensions.
No one on the team agreed on which tradeoff to accept. At the time, no one had found a way to exploit the bug either, so it wasn’t prioritized.
That changed by August 2026. Security researchers at Calif built a working exploit using advanced AI tools made available through Patch the Planet, a program run by OpenAI that gives security researchers access to its AI models specifically for hunting flaws like this one.
Separately, the cybersecurity firm Wiz identified related issues in PHP on its own. OpenAI later said one of its own researchers had come across the same problem independently, around the same time as the other two.
Salil Kanhere, a cybersecurity researcher at UNSW Sydney, said the underlying bugs weren’t new. What changed was the ability to actually track them down.
Finding a working way to break into a system like this used to require a group of highly specialized human researchers. These were people who would spend months manually reading through code, testing edge cases, and understanding exactly how a program behaves under unusual conditions. That process could take years. But AI has changed that.
Modern AI models can read through enormous amounts of code far faster than a person can. They can test many possible weaknesses automatically. In some cases, they can even write working attack code based on what they find.
Wiz said it used these AI tools to build and adjust working exploits across several different applications. The whole process took just hours, work that a skilled human team would have taken far longer to do.
The software itself didn’t change. What changed was how fast and cheap it became to actually find the bug and turn it into a working attack.
OpenAI wrote about this directly on its Patch the Planet site. The same AI tools that helped find this flaw could also help an attacker build a working exploit, faster than a person could do alone. They also released a free tool called php2shell-checker that anyone can use to check whether their PHP version is affected. It only checks the version number, so it can’t catch every possible case, but it’s a fast first check.
What This Meant for Cloudways Customers
Cloudways customers were not immune to what was happening across the rest of the internet.
Early on, before the official patch was available, we put protective measures in place to quickly reduce risk. Rolling that out across many servers meant some customers experienced a brief interruption.
Separately, on October 21, the Cloudways Platform, Affiliate Portal, and website went offline for scheduled maintenance tied directly to the patching work.
What You Should Check Now
The patch closed the PHP2Shell vulnerabilities. It doesn’t undo anything that may have already happened before the patch went live.
Ken Munro, an ethical hacker, told the BBC that applying this patch works much like a routine software update. The real work is making sure it gets applied everywhere.
The UK’s National Cyber Security Center recommended checking for signs that an attacker already got in before the patch existed, since the patch itself can’t undo something that already happened.
If you’re a website owner, here are some things you need to keep an eye on:
- Admin accounts you don’t recognize
- Files you didn’t add
- Traffic patterns that look unusual
Salil Kanhere, a cybersecurity researcher, warned that smaller organizations face more risk, since they often have fewer people keeping an eye on this kind of thing.
This advice applies to you whether you manage your own server or use a managed platform like Cloudways. On Cloudways, we patch PHP for you automatically, but that only protects you from this point forward. It doesn’t tell you whether something happened before the patch was applied. That part is still worth checking yourself.
How We Responded to PHP2Shell
PHP announced on October 20 that a patch was scheduled for the next day. We started applying interim protections right away, without waiting for the patch itself. They were in place by the morning of October 21.
The official patch arrived at 14:00 UTC on October 21. We expanded our protections to cover every PHP version we support, going back to PHP 5.6. That includes several versions that no longer receive official security updates from the PHP project itself.
By the early hours of October 22, our Autonomous product was fully patched. The rest of our fleet followed over the next several hours, with the full rollout complete by mid-morning the same day. We formally closed the incident on October 23 and continue to monitor for any further developments in the meantime.
A Third, Narrower Issue
Two days after the first disclosure, PHP published a separate notice about a third issue. It was later assigned its own identifier, CVE-2026-115560.
This issue applies only to a site that does two unusual things together, and most sites don’t do either.
First, the site needs to change a specific internal setting while it’s already running, something most websites never do. Second, the same site needs a particular feature turned on, one related to tracking the progress of a file upload.
PHP’s own advisory says this exact combination is unlikely to exist on a real, typical website. The fix for this issue is the same setting already recommended for the second vulnerability, CVE-2026-109619. Because we had already applied that protection across our entire fleet on October 21, our customers were covered before this third issue was even confirmed.
What This Means Going Forward
PHP2Shell isn’t likely to be the last incident like this.
The same AI tools that found this flaw can be pointed at other widely used software as well. Salil Kanhere said more attempts to exploit these specific flaws are likely in the coming weeks, now that the technical details are public.
Daniel Stewart, head of threat intelligence at the risk firm LRQA, made a related point. PHP isn’t only found in websites. It also runs quietly inside the behind-the-scenes equipment that manages internet traffic, devices that rarely get checked during an incident like this one.
This kind of event is likely to happen again, not only for PHP but also for other old software still running on the internet.
That’s why, as a managed hosting provider, we keep watching for this kind of thing year-round. Our security team tracks new disclosures as they come out, and we test and apply fixes across our platform as soon as they’re available, just as we did here.
Final Thoughts
This post reflects what we know as of today. If anything changes, including new developments related to PHP2Shell or anything else affecting our platform, we’ll post it on our status page first.
If you’re a Cloudways customer, the patching described in this post is already complete on our end. The one thing still worth doing is the check we covered earlier, looking for any signs that something happened to your site before the patch was applied.
A lot of people across the hosting and security industry worked hard over the last several days to get this handled. We’re glad it’s resolved, and we’ll keep watching for whatever comes next.
If you have any questions, our support team is available anytime.
Q1: Do I need to do anything on my end?
Patching is handled automatically at the platform level across all supported Cloudways products. You don’t need to install anything yourself.
The one thing still worth doing is checking your own site for signs that something happened before the patch was applied.
Q2: Should I still update my own website software, like WordPress, plugins, or themes?
Yes, that’s still good practice. This patch fixed PHP itself, the language running underneath your site. Keeping your CMS, plugins, and themes updated separately helps close other, unrelated security gaps.
Q3: Will something like this happen again?
The specific flaws in this post are fixed. Similar incidents involving other old software are likely at some point. Our security team tracks new disclosures as part of its regular, ongoing work.
Q4: I’m using an older, unsupported version of PHP. Was I still protected?
Yes. We extended coverage to older, deprecated PHP versions through our Extended Long-Term Support partnerships, including versions that no longer receive official security updates from the PHP project itself.
Q5: Was there any downtime during the patching process?
For some customers, yes, briefly. Applying a fix across a large number of servers at once can cause a short restart or a temporary slowdown. We aimed to keep this as limited as possible.
Q6: How do I know if my specific server was affected or patched?
Our status page has the full, dated record of the rollout. If you have specific questions about your own account, our support team can confirm details directly.
Q7: What if I think my site was already compromised before the patch was applied?
Change your passwords and check your site for admin accounts or files you don’t recognize. Then reach out to our support team directly.
Q8: Is this specific to Cloudways?
No, this was an industry-wide vulnerability in the PHP language itself. It affected any organization running PHP.
Sarim Javaid
Sarim Javaid is a Sr. Content Marketing Manager at Cloudways, where his role involves shaping compelling narratives and strategic content. Skilled at crafting cohesive stories from a flurry of ideas, Sarim's writing is driven by curiosity and a deep fascination with Google's evolving algorithms. Beyond the professional sphere, he's a music and art admirer and an overly-excited person.
