PHP2Shell Explained: The 14-Year-Old Bug That Pulled Government Websites Offline

The Week the Web Pulled Its Own Plug

On the night of 21 October 2026, cyber.gov.au went dark. The website of Australia's own cyber security agency, the people whose job is to tell everyone else how to stay safe online, switched itself off.

It was not alone. The Netherlands took DigiD and MijnOverheid offline, the logins Dutch citizens use for taxes, healthcare and benefits. Finland pulled every public-facing government web service. France took down every website of its Interior Ministry. Denmark's national school communication platform went offline. The Wikimedia Foundation shut down supporting services. The Internet Archive went briefly dark. Nintendo took services down. In Japan, games with millions of players went into emergency maintenance.

Nobody had been hacked yet, at least not publicly. They were hiding.

The reason has a name: PHP2Shell. It is two flaws, officially CVE-2026-109618 and CVE-2026-109619, in a piece of software most people have never heard of and almost everyone uses every day. Both are rated 9.2 out of 10 for severity. One security firm, watchTowr, rated one of them a perfect 10.

Cloudflare, which sits in front of a large slice of the world's websites, counted tens of thousands of attack attempts within 45 minutes of the news breaking, hundreds of thousands within two hours, and millions by that evening.

Here is what actually happened, in plain English.

---

First: What Is PHP?

PHP is a programming language that builds web pages on the fly.

When you visit a simple website, the server hands you a finished page, like a printed menu. When you visit a site with logins, shopping carts, comments or search, the page has to be built for you, right now, from scratch. Something has to look up your account, check your basket, pull the right products from a database and assemble the page. On a huge share of the internet, that something is PHP.

Think of a restaurant:

• You (your browser) are the diner placing an order.
• The web server is the waiter who takes it to the back.
• PHP is the kitchen that cooks the meal.
• The database is the pantry, where the ingredients live: customer accounts, orders, passwords, payment records.

PHP started in 1994 as a small personal project. Facebook was built on it. Today it runs WordPress, which alone powers roughly 40% of websites, plus Drupal, Joomla, Magento, and the cPanel and Plesk control panels that cheap web hosts hand to small businesses. Wiz, one of the firms that found the bug, put PHP's footprint at 70% of the internet. Wikipedia's entry on the bug puts it at about 69% of websites.

Those numbers count websites, and websites are not the same as servers. A more conservative count from Shodan scans, published by Mallory and analysed by CybelAngel, found about 2.24 million internet-facing machines openly advertising PHP. Either way, the conclusion is the same: if you have used the internet this week, you have used PHP.

---

What PHP2Shell Actually Does

Most website hacks need a way in. A weak password. An outdated plugin. A careless admin. PHP2Shell needs none of that.

The attacker does not need an account. They do not need the site to have any particular plugin. They do not even need the website's own code to run. Datadog's security lab put it bluntly: "PHP processes the malicious request before any application code runs." That means a site's login page, its security plugin and its firewall rules written in PHP are all standing in the wrong room. The break-in happens in the corridor before them.

Here is the first flaw, CVE-2026-109618, translated out of engineering language:

An analogy: imagine a hotel that files every guest's registration card in a cabinet. Someone hands in a card with a name so long the clerk runs out of ink halfway through writing it. The clerk leaves the half-filled card in the drawer. At closing time, the night manager processes every card in the drawer without checking, and the attacker has arranged for the unfinished part of that card to read "unlock the safe."

The second flaw, CVE-2026-109619, is the same family of problem from a different angle. PHP reuses its workers between visitors to save time, a bit like a hotel room being turned over between guests. Some information from one visitor's request is not properly cleared before the next visitor arrives. An attacker who lands on the same worker can pick up that leftover state and use it to run commands. One of the features involved, upload progress tracking, is switched on by default and works even on pages that never use it.

Wiz showed that it could take over the latest official versions of WordPress, Drupal and Joomla this way. It also showed something quieter and arguably worse: even without full takeover, an attacker can read pieces of the server's memory. Server memory is where passwords, login tokens and API keys sit while they are being used.

What this means for ordinary people: a server running an unpatched PHP is a server a stranger can control. A stranger who controls a shop's server can change what the shop shows you. That includes the checkout page.

---

Fourteen Years in the Code, Two Months on the Clock

The flawed code has been in PHP since version 5.4, released in 2012. A PHP core developer even spotted one of the memory errors during a 2024 audit. The team could not agree on a fix and nobody had found a way to exploit it, so it sat.

Then AI looked at it.

On 1 August 2026, Ryan Austin of the AI red-teaming firm Calif found the first flaw using OpenAI's GPT-5.6 Sol, as part of OpenAI's "Patch the Planet" project. On 19 August, Wiz found it independently using Google's Gemini 4 Argon, GPT-5.6 Sol and its own tool. A fix was quietly prepared for a coordinated release.

Coordination did not hold. Amazon's threat intelligence team logged someone trying to exploit the flaw on 17 October, four days early. Details and proof-of-concept code leaked on 20 October, forcing PHP to release a day ahead of schedule. Patched code from one vendor went out early, which let attackers compare old and new and see exactly where the hole was.

Detectify's Joviane Jardim told The Record that most attackers can build a working exploit in under an hour. watchTowr said some of the exploit tools it saw in the wild were "vibecoded" with AI.

That is the real headline. The same tools that found a 14-year-old bug in two months also shrank the attacker's head start from weeks to minutes. The security firm Sansec predicted mass attacks within 15 minutes of the patch. It was not far off.

---

Who Is Exposed, Region by Region

USA. The US has the largest pool of exposed machines: 228,770 internet-facing PHP hosts on branches with no official patch, according to the Shodan data CybelAngel analysed. The NSA advised websites that cannot update immediately to go offline. The FBI's cyber division urged updates. CISA said on 21 October it had not yet observed exploitation, a statement that conflicts with watchTowr and Cloudflare, who both reported live attacks that day.

Europe. Europe responded the hardest. The Netherlands, Finland, France and Denmark took government services offline before the patch landed. CERT-EU advised isolating internet-facing applications. The UK's NCSC warned specifically about backdoors, meaning attackers who get in now and come back later. In France alone, 25,439 PHP hosts sit on unpatched branches, 54% of the French hosts that report a version.

Middle East (UAE and Saudi Arabia). As of 23 October we have found no specific PHP2Shell advisory from the UAE Cyber Security Council, aeCERT or Saudi Arabia's National Cybersecurity Authority. Gulf Business flagged the risk to organisations across the UAE and wider GCC. Silence from regulators is not safety. Gulf e-commerce, government portals and hospitality sites run on the same WordPress and Magento stacks as everyone else, and attackers scan by IP address, not by passport.

Africa (including South Africa). The starkest number in the entire dataset is African: in Algeria, 100% of versioned PHP hosts were unpatched, almost all running PHP 5.3 on the national carrier's network, a version abandoned years ago. We found no South Africa-specific advisory or exposure figure. South Africa's large market of budget shared hosting and small-business WordPress sites is exactly the profile that patches slowly.

Australasia. Australia took the most visible hit. The ACSC issued its highest-rated critical alert on 21 October, and cyber.gov.au went offline that night along with other federal sites. GovCMS, the Drupal platform behind much of Australia's federal web presence, runs on PHP. Murdoch University's David Parry made the point that matters most for small businesses: site owners "might not even know they are using" PHP. We found no New Zealand-specific advisory as of publication; CERT NZ remains the place to report.

---

The Problem Nobody Can Patch Their Way Out Of

The fix exists. PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October. Update to one of those and both flaws are closed.

The catch is that most of the web is not on those branches.

PHP 8.1 and older are "end of life", meaning the PHP project no longer ships updates for them. For 7.4, 8.0 and 8.1, PHP published bare source-code patches, which help a skilled sysadmin and do nothing for a florist whose website was built in 2019 by a nephew. WordPress.org's own statistics say 35.1% of WordPress sites run an unsupported PHP version.

Every one of those sites now depends on someone noticing, caring and acting. Many never will. That is why this story will not end this month. PHP2Shell will be a reliable way into abandoned and neglected websites for years, the same way the 2014 Heartbleed bug, which Wiz compared this to, kept turning up long after the headlines stopped.

---

If You Just Use Websites: What to Do

You do not need to update anything on your phone or laptop. PHP runs on the website's server, not your device. Ignore any pop-up, email or "security alert" telling you to download a PHP fix. That is a scam riding the news.

Here is what is actually worth doing:

1. A site being offline is not proof it was hacked. Many organisations went dark on purpose. Malwarebytes put it plainly: "temporary downtime alone doesn't mean a website has been breached."
2. Be suspicious of familiar sites acting strangely. A hijacked site keeps its good reputation, which is exactly why attackers want it. Watch for unexpected redirects, surprise downloads, repeated login prompts, a checkout page that looks different, or a "verify your card" step you have never seen there. If something feels off, leave.
3. Change passwords on sites that announce a breach. Over the coming weeks, expect breach notices from companies that patched too late. When you get one, change that password and anywhere else you reused it. A password manager makes this a five-minute job instead of an afternoon.
4. Turn on two-factor authentication for email, banking and shopping accounts. A stolen password is far less useful without the second step.
5. Watch your card statements for the next two months. If a shop's checkout was tampered with, the first sign is usually a small test charge. Use a virtual or single-use card for unfamiliar shops if your bank offers one.
6. Check a site before you pay. Run unfamiliar shop domains through RiskScope before entering card details. It will not see inside a server, but it does flag threat-database listings, which is where hijacked sites tend to show up first.

---

If You Own or Run a Website: What to Do Now

If you run a business website and are not sure what it runs on, assume PHP. If it is WordPress, WooCommerce, Joomla, Drupal or Magento, or if your host gives you cPanel or Plesk, it is PHP.

1. Find out your PHP version. In cPanel or Plesk, look for "Select PHP Version" or "PHP Settings". In WordPress, go to Tools, then Site Health, then Info, then Server. If you have server access, run:

php -v

Check every PHP install you have, not just the main site: staging copies, old microsites, containers, and appliances or software that quietly bundle their own PHP.

2. Update to a fixed version. You are safe on 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. On a managed host, check your host's status page or ask support directly whether your server is patched against CVE-2026-109618 and CVE-2026-109619. If you are on PHP 8.1 or older, move to a supported branch or confirm in writing that your vendor has backported the fix. After updating, restart PHP so no old workers are still running, and rebuild any container images.

3. Do not install "PHP2Shell fix" plugins or paste code snippets from forums. Patchstack, a WordPress security firm, warned against exactly this. The bug lives below WordPress, where no plugin can reach it, and fake security plugins are a classic malware trick.

4. If you cannot update today, take the site offline or into maintenance mode. That is what the NSA, Patchstack and half the governments of Europe did. A day of downtime is cheaper than a breach notice.

5. Interim settings, if your technical person needs them. PHP published temporary mitigations. They reduce exposure; they do not make a server safe:

; CVE-2026-109618: set at server level so applications cannot override,
; alongside a low post_max_size and a container memory limit
memory_limit = -1
; CVE-2026-109619
session.upload_progress.enabled = 0
; PHP 8.5 only
fatal_error_backtraces = 0

These must load before PHP handles requests, so restart every worker afterwards.

6. Look for signs you were already hit. Exploitation attempts date back to 17 October. Patching closes the door. It does not remove anyone who already walked through it. Warning signs include:

• Error log lines like Allowed memory size of ... bytes exhausted ending in in Unknown on line 0. The "Unknown on line 0" part means the failure happened before any of your site's code ran.
• Sudden bursts of HTTP 500 errors, PHP workers crashing or restarting for no clear reason, or segmentation fault messages.
• Unusually large or garbled PHPSESSID cookies in your logs.
• New admin users you did not create, files you do not recognise, or changed checkout or payment pages.

None of these on its own proves a breach. Together, or alongside oversized form submissions in your access logs, they are a reason to act.

7. If you think you were compromised, treat it as a breach. Restore from a clean backup taken before 17 October, then patch before you bring it back online. Change every password and key the server could see: database passwords, admin accounts, email credentials, payment gateway and API keys. Wiz showed attackers can read server memory without full takeover, so rotate these even if the site looks untouched. If you use the UpdraftCentral dashboard for WordPress, delete its keys: Patchstack reports an attacker using stolen keys to plant backdoors on connected sites in a separate campaign running alongside PHP2Shell.

8. Know your notification duties. If customer data was exposed, you may be legally required to tell people. Under the EU and UK GDPR, the regulator must normally be told within 72 hours. Australia's Notifiable Data Breaches scheme, South Africa's POPIA, and the personal data protection laws in the UAE and Saudi Arabia all carry their own duties. Get advice early; a late notice is usually worse than the breach.

---

How to Stop the Next One

PHP2Shell will not be the last bug of this kind. AI is now finding old flaws faster than the humans who maintain this software can fix them, and the same AI is helping attackers weaponise them. Plan for more, and plan for less warning.

For website owners:

• Never run software past its end-of-life date. PHP 8.2 stops getting security fixes on 31 December 2026. If you are on it today, schedule your move to 8.4 or 8.5 now, not in December.
• Turn on automatic security updates, or pay a managed host whose job is to do it for you. The businesses that came through this week calmly were the ones whose host patched overnight.
• Keep an inventory. You cannot patch a site you forgot exists. List every website, staging copy and tool that runs on your domain.
• Keep offline backups you have actually tested restoring. A backup you have never restored is a hope, not a backup.
• Put a web application firewall in front of your site. Cloudflare pushed emergency rules within hours. It is a stopgap, not a fix, and only works if your server refuses traffic that does not come through it, but it buys time.
• Delete what you do not use. Old landing pages, abandoned blogs and test installs are where attackers get in, because nobody is watching them.

For everyone else:

• Use a password manager and unique passwords, so one hacked site cannot unlock the rest of your life.
• Use two-factor authentication on anything with money or email attached.
• Pay with protection. Credit cards, virtual cards and payment services that hide your card number limit the damage if a checkout page is tampered with.
• Treat trust as something a site earns every visit, not once. A site you have used for years can be hijacked overnight. Strange behaviour beats familiarity.

---

Report It

If you were defrauded through a website, or you run a site that was compromised, report it:

• USA: FTC and the FBI's IC3
• UK: Action Fraud and the NCSC
• EU: your national CERT or cybercrime unit (Finland: NCSC-FI), and your data protection authority if personal data was exposed
• UAE: eCrime, the UAE Cybercrime Combating Centre
• Saudi Arabia: Saudi CERT
• South Africa: SABRIC, the SAPS Commercial Crime Unit, and the Information Regulator for data breaches
• Australia: ReportCyber and Scamwatch
• New Zealand: CERT NZ

---

The Uncomfortable Version

The governments that switched their websites off this week were mocked in some corners for overreacting. They were right. The agency whose website went dark was the one doing its job.

The sites that should worry you are the ones that stayed up without patching: the small shop, the local clinic's booking page, the club website nobody has touched in five years. They are still online. They still take payments. And as of this week, anyone with an hour and an AI model can learn how to walk into their kitchen.

You cannot patch someone else's server. You can choose where you type your card number.

---

Shopping somewhere new this week? Check the domain on RiskScope first. It is free and takes ten seconds.

---

Related Reading

• Protect Yourself From Online Shopping Scams: the checks that still work when a legitimate site has been hijacked
• The AI Job Interview Is the Product: another 2026 breach that started with a software flaw nobody outside engineering had heard of
• What Is RiskScope?: how our risk scores work and what they can and cannot see

---

Sources: Datadog Security Labs: PHP2Shell detection, analysis and remediation, Patchstack: PHP vulnerable to critical RCE, attacks ongoing, Fortune: AI helped discover the PHP vulnerability, The Record: Hundreds of websites taken offline, iTWire: the 14-year-old bugs that pulled cyber.gov.au offline, CybelAngel: 2.24 million internet-facing PHP hosts, Malwarebytes: Why websites are going offline, The Hacker News: exploitation 4 days before disclosure, NSA advisory, watchTowr PHP2Shell FAQ, Gulf Business: Critical PHP flaws put millions of websites at risk, Wikipedia: PHP2Shell