PHP2Shell is the name given to two critical flaws in PHP, the language that runs WordPress and a large share of business websites. The PHP security team released fixed versions on 21 October 2026, which was 1am on 22 October in Melbourne. Any site still running an older build can be taken over by a single request from someone who never logs in. At xCreative™, the Melbourne studio that designs and builds websites and then hosts and maintains them, we finished upgrading the nearly 100 client websites we look after, from sites we host to sites under our SEO and GEO care, and on every server we manage we have since applied the PHP team’s extra safeguard for a related flaw announced on 23 October.
Below: what the flaws are, how the week played out, what we did day by day, and the checks any business owner can run today, whoever looks after their site.
What PHP2Shell is and why it is rated critical
The two flaws are CVE-2026-109618 and CVE-2026-109619. Both are scored 9.2 out of 10 under CVSS version 4. The first comes from the way PHP handles running out of memory partway through a request. The second lets data from one visitor’s request linger after it should have been cleared, where a later request can use it. Either one can let an attacker run their own code on the server.
The detail that matters for owners: the bug is in PHP itself, not in WordPress or a plugin. The official PHP advisory says every installation that serves web pages is affected, whatever the setup, and that risk is highest on servers running PHP inside Apache, where an attack can fire before any website code has loaded. Updating WordPress, a theme or a security plugin does nothing here. The fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The PHP team’s own wording is that there is no complete workaround and updating is the only safe choice.
How the week unfolded
The PHP team gave advance notice on 20 October and released the fixed versions on 21 October at 14:00 UTC, with full technical details following. The Australian Cyber Security Centre issued a critical alert the same day, saying it was not then aware of successful exploitation within Australia. In the United States, CISA told organisations to patch immediately.
Attackers did not wait. Cloudflare put firewall rules in place before the flaws were public and reported attackers changing their payloads to slip past them. The Register reported that Amazon’s threat team saw an exploit attempt as early as 17 October. Then on 23 October the PHP team flagged a third, narrower problem, CVE-2026-115560, with no patch yet, and advised switching off a PHP feature called session upload progress until the next release.
What we did for our clients
We treated it as an emergency the morning the patch appeared. The work split in two, because our clients’ servers were not all built the same way.
- 22 October: half of the servers we manage take PHP straight from the operating system’s security updates. We upgraded each one to the fixed release and restarted PHP. Then we confirmed the version number, found both CVE numbers in the package notes, and loaded the home page and login page.
- 22 to 24 October: the other half ran a packaged server stack whose PHP cannot be updated through the operating system, and whose maker has stopped issuing updates for it. Rather than wait, we moved each of those sites to a new server running the fixed PHP, compared every page against the old server before switching, and kept the old copy as a fallback.
- Alongside the patching: we checked every server for files that should not be there and removed migration plugins that had been left active after earlier host moves, because tools like that are a common way in.
- 24 October: after the 23 October notice, we switched off session upload progress on every server and confirmed the live setting on each website, not just in a config file.
Every site was tested after its change. None of this needed clients to log in, approve plugin updates or book anything. That is the point of a website maintenance plan: when the internet has a bad week, the people holding your server keys are already working on it.
What to check if someone else looks after your site
If your website is not with us, these checks take about ten minutes.
- Find the exact PHP version. In WordPress, go to Tools, then Site Health, then Info, then Server. You need the full number. 8.3 tells you nothing; 8.3.36 or later is fixed, and so is 8.2.35 or later on the 8.2 branch. Some hosts apply the fix to their own PHP builds, so if your number looks older, ask them before you panic.
- Ask your host in writing whether PHP on your plan is patched for CVE-2026-109618 and CVE-2026-109619, and when it was done. On shared or managed hosting, they are the only ones who can fix it.
- If you run your own server, nobody will patch it for you. PHP has to be updated and restarted, and the restart is the step people miss.
- If your site is on Shopify, Squarespace or Wix, the platform runs the servers and this one is theirs to fix. Your own job is keeping admin accounts locked down.
There is a search cost too. Google lists hacked content and malware in Search Console’s security issues report, and its guide to preventing abuse on your site covers malware and deceptive pages. A compromised site can lose visitors’ trust and its place in search results at the same time.
Security is part of design, hosting, SEO and GEO
We do not see security as a separate product. It runs through every service we offer.
Design and development. A site built to be maintained is easier to patch. When we build on WordPress or run an online store, we keep plugins few and well supported, so an emergency update is a routine job rather than a rebuild.
Hosting and maintenance. We keep the sites in our care patched and backed up, with monitoring running around the clock, and we tell clients plainly what we did. This week that meant moving servers within days, not waiting for a quiet month.
SEO and GEO. Search engines and AI assistants only recommend sites they trust. A site injected with spam pages or flagged as hacked loses that trust quickly, and getting it back takes longer than the clean-up. Our SEO, GEO and AI search work starts with a site that is secure and fast, because everything else sits on top of it.
If you are unsure whether your site has been patched, or you would like one team to look after your site from design through to search, talk to our Melbourne studio. If you are moving your site to us from another developer, our handover checklist lists the accounts and files to secure first.
Frequently asked questions
My WordPress is fully up to date. Am I safe from PHP2Shell?
Not necessarily. PHP2Shell is a flaw in PHP, the software underneath WordPress, so WordPress updates do not touch it. Check the PHP version in Site Health and confirm with your host that it is 8.2.35, 8.3.36, 8.4.27, 8.5.12 or a patched build from your provider.
Can a security plugin or firewall protect my site instead of updating?
Only partly. Some attacks run before WordPress or any plugin loads, so a plugin cannot see them. Firewalls like Cloudflare’s block known attack patterns, but attackers have already changed theirs. The PHP security team says updating PHP is the only complete fix.
Do I need to do anything about the 23 October PHP notice?
If your host or developer has switched off session upload progress, you are covered until PHP’s next release fixes CVE-2026-115560 properly. The PHP team describes it as an unlikely attack path, but turning the feature off costs almost nothing. On every server we manage, it is already done.
Related reading: Checking your website PHP version after PHP2Shell: who patches what
