PHP2Shell Vulnerability: What Happened and How to Fix It

Short answer: PHP2Shell is a pair of critical flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619, that can let an attacker with no login run code on a web server. Updating WordPress will not fix them. Your PHP runtime must be updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a vendor backport), its workers restarted, and any exposed passwords and API keys rotated.

At Seven Seas Web Design we build and clean up websites for small businesses, and this vulnerability has an awkward feature for owners: it sits in a layer most of them have never had to think about. In one week in October, France pulled its prefecture websites, Finland shut down government web services, and the Port of Rotterdam went dark. Almost none of them had been breached. They chose downtime because they could not be sure of patching in time.

This guide separates what is confirmed from what was retracted, then shows who is responsible for your patch and exactly what to check. If you already suspect your site has been hit, go straight to our guide on how to fix a malware-infected WordPress website. If you want to understand your exposure first, start here.

Key Takeaways

• The flaw sits underneath your CMS. Core, theme and plugin updates do not touch it. Only patching PHP closes it, and a web application firewall only buys time.
• Most of the outages were self-inflicted. Shutdowns across Europe and Japan were largely precautionary, and most organisations reported no compromise.
• Real attacks exist, but they are narrower than the headlines. The best-documented case rooted 25 firewall systems, three of them in a U.S. government-affiliated environment.
• A clean file scan is not an all-clear. These flaws can also leak server memory, so a site that ran unpatched should rotate its passwords and API keys.
• The exposure is still large. Censys data cited by Kaspersky showed 29 million of 46 million scannable servers still vulnerable two weeks after the fix.

---

What Is the PHP2Shell Vulnerability?

PHP2Shell is the name for two memory-safety flaws in the PHP language runtime, each rated CVSS v4.0 9.2 (critical). An attacker needs no account and no password. PHP's own security release notes say the flaws affect all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is rated highest for mod_php, where a request can trigger the attack before any application code runs.

That last detail is why this one is different. Most WordPress security advice focuses on plugins and passwords. This attack can land before WordPress even loads, so your security plugin, your strong passwords and your fully updated site are simply not in the path.

Flaw	Plain-English cause	Status
CVE-2026-109618	A request exhausts PHP's memory during setup. Half-built data is left behind, and cleanup code trusts it.	Fixed 21 October. Exploited in the wild.
CVE-2026-109619	A PHP worker keeps a reference to memory already freed from an earlier request.	Fixed 21 October. Listed by CISA as exploited.
CVE-2026-115560 (related)	A session upload progress risk that needs an unusual combination of configuration and code.	No patch yet. Set session.upload_progress.enabled=0 if your app changes the serialize handler at runtime.
CVE-2026-111497 (related)	A flaw in the Brotli library bundled with PHP's Windows builds, reachable through cURL when automatic decompression is on.	Fixed 26 October in Windows rebuilds marked -1, such as 8.4.27-1.

The bugs are old. iTWire reports they sat in PHP for about 14 years, and Google Cloud lists versions 5.4 through 8.5.11 as affected, according to Newsweek. PHP also runs about 70% of websites whose server-side language can be identified, per W3Techs. Sansec's list of demonstrated targets includes WordPress, Drupal, Joomla, Magento, Laravel and phpMyAdmin.

The Timeline, From Discovery to Worldwide Scramble

The fix took about two months. The attack wave took hours. Researchers found the flaws in August, but details and early attacks got out ahead of the planned release.

Date (2026)	What happened	Source
19 to 24 August	Wiz Research finds the flaws, confirms attacks against Drupal and WordPress, and privately reports them to PHP.	Recorded Future
17 October	Amazon's decoy servers log an exploit attempt, four days before disclosure.	The Next Web
20 October	PHP announces an emergency release. CVE numbers leak online.	iTWire
21 October	Patched PHP ships. Chainguard's early container release sparks a public dispute over the embargo. Governments start pulling sites.	PHP, iTWire
23 October	PHP warns of a third flaw, CVE-2026-115560, with no emergency patch.	The Hacker News
23 to 24 October	The firewall campaign reported by Dream runs. A researcher's honeypots record 35 successful shell executions.	The Record, The Register
26 October	CISA adds both flaws to its Known Exploited Vulnerabilities catalog, with a 29 October deadline for federal civilian agencies.	BleepingComputer
3 November	Singapore's cyber agency warns of active exploitation affecting network and security products.	CSA Singapore

Attack speed explains the fear. Cloudflare CEO Matthew Prince described thousands of attempts in the 10 hours before the announcement, tens of thousands in the next 45 minutes, hundreds of thousands within two hours, and then millions, as The Next Web reported. Those are attempts, not successful breaches, and that distinction matters throughout this story.

Which Governments Took Websites Offline?

Public bodies in about ten countries took some sites or services offline, and others warned of disruption. Most described it as a precaution rather than a response to a breach. The most detailed picture comes from Reuters, published by The Korea Times.

Country	Who was affected	What they said or did
Germany	Federal IT provider ITZBund	Deactivated several sites. A ministry spokesperson called it "purely preventive."
France	Interior Ministry, prefecture websites	Temporarily offline pending a patch.
Netherlands	Overheid.nl, health institute RIVM sites, Port of Rotterdam, hospitals, major political parties	Many followed the National Cyber Security Centre's lead.
Finland	State IT centre Valtori	Shut government public web services as a precaution, with no exploitation attempts reported.
Belgium	Foreign ministry	Took its sites offline. The national cyber centre recorded no attacks on Belgian websites.
Czech Republic	Government website	Offline on the cyber watchdog's advice while patches were applied.
Japan	Ministry of Finance, Meteorological Agency, National Tax Agency	Partial or temporary suspension of online services.
United Kingdom	City of Edinburgh and other municipalities, plus some BBC portals	Web services temporarily taken down.
Denmark	National school communication platform	Affected, per Newsweek.
Australia	cyber.gov.au and other federal sites	iTWire reports Home Affairs called some sites "temporarily unavailable."
Canada	Government of Canada	Warned some sites might be unavailable, with no sign of compromise.
United States	Federal agencies	The NSA advised being ready to update, or taking systems offline if updating was not feasible. Newsweek found no evidence at the time of federal sites being compromised or pulled.

The private sector moved too. Wikimedia and the Internet Archive took systems down for patching. In Japan, Mizuho, MUFG group companies, Shizuoka Bank, ANA and East Japan Railway suspended some services, and France's Orange suspended access to some sites and apps.

One thing worth saying plainly: a site being offline in that table does not mean it was hacked. These organisations paid in downtime to avoid an unknown risk. Germany's BSI, for example, reported seeing attacks but no successful use of the flaws at that stage.

The U.S. Government-Affiliated Breach, Step by Step

The most serious reported case targeted firewalls, not ordinary websites. Israeli security firm Dream reported that an actor it suspects is China-linked rooted 25 servers across the U.S., Japan, Taiwan and South Korea, including three systems in a U.S. government-affiliated environment. The details below come from The Hacker News' account of Dream's research. Dream's attribution rests on targeting and tooling, so treat it as an assessment rather than a proven fact.

1. Find. The attacker used the FOFA search engine to locate about 19,000 firewalls with exposed management interfaces.
2. Filter. A custom scanner narrowed these to 240 targets running a build the exploit could handle, in four countries.
3. Chain. A batch script combined PHP2Shell with Fragnesia (CVE-2026-46300), a Linux flaw that raises access to root, then planted a web shell.
4. Pivot. On one government-affiliated system, the attacker opened a reverse SSH tunnel and compromised an internal firewall management server.
5. Expand. The attacker went after Active Directory, decrypting a service account password, listing users and spraying passwords. Whether this produced valid accounts is unclear.

Dream found evidence that AI helped build the tooling, including Claude Code in the attack infrastructure and the aiscan offensive platform configured with DeepSeek and Kimi models. Dream later named the affected vendor as Palo Alto Networks, and The Record reports that Unit 42 independently verified the findings. Palo Alto's own advisory confirms active exploitation against management interfaces exposed to the internet.

This is a warning for small offices as well as agencies, because PHP often hides inside the boxes that guard your network. Singapore's CSA lists affected products from Palo Alto, Cisco, Citrix, F5 and Siemens, and says that list is not exhaustive. If your IT provider manages a firewall or remote-access appliance, ask them about it today.

Confirmed vs Retracted: What to Actually Believe

Exploitation is real, mass compromise is not confirmed, and at least two early claims were walked back. Many articles on this topic blur those lines, so here is the scorecard as of 4 November 2026.

Claim	Status	Evidence
Exploited in the wild	Confirmed	CISA's catalog, Adel Karimi's honeypots, and at least six successful exploitations per GreyNoise (The Record).
Firewall appliances attacked	Confirmed	Palo Alto Networks' advisory and CSA Singapore's alert.
Large attack volume	Confirmed, as attempts	Delft University tracked over 50,000 exploit requests from 600+ IPs in 70 countries, with 171 addresses sending exploit code or droppers (The Register).
U.S. government-affiliated breach	Reported by a vendor	Dream's report, independently verified by Unit 42. CISA declined to comment and has named no victims.
North Korea-linked scanning	Moderate confidence	CYFIRMA describes low-volume scanning of 216 hosts, including government and financial targets.
European government agency breached through PHP2Shell	Retracted	Unit 42 said it was "unable to confirm" the initial access link.
Sophos' early exploitation assessment	Retracted	Sophos concluded the activity was scanning and failed attempts.
Mass compromise of PHP servers	Not confirmed	Kaspersky says exploits must match the exact build, memory settings and request handling.

Do not read "hard to exploit" as "safe to ignore." Attackers only need one reliable recipe for a common setup, and Dream's case shows a skilled actor can build one for a specific product. The gap is also wide open: 29 million of 46 million scannable servers were still vulnerable in the Censys data Kaspersky cited two weeks after release.

Who Is Responsible for Your Patch?

Whoever controls the PHP runtime is responsible for the patch, and that is often not the person who manages the website. This is where small businesses get caught: the owner assumes the web designer did it, the designer assumes the host did it, and nobody checks.

Your setup	Who patches PHP	Your move today
WordPress.com, WordPress VIP, WP Cloud, Pressable	Automattic	Automattic said these platforms were already protected and customers need not act.
Shared or managed hosting	Your host	Get written confirmation, using the questions below.
VPS or cloud server (self-managed)	You or your developer	Update PHP and restart workers. This also covers phpMyAdmin, webmail and other PHP apps on the server.
Docker or containers	You, using a patched base image	Rebuild and redeploy. Pulling a new image does nothing until running containers are replaced.
Custom PHP app or ecommerce store	Your developer or host	Confirm the runtime, then test checkout and payment flows after the update.
Firewall, VPN or network appliance	The vendor, applied by your IT team	Apply vendor firmware and block public access to the management interface.

Copy and send this to your host:

"Regarding CVE-2026-109618 and CVE-2026-109619: (1) Is a patched PHP build live on my account, including any older PHP versions I can select? (2) On what date were PHP workers restarted? (3) Is my site running under mod_php, PHP-FPM or LiteSpeed?"

A vague "we take security seriously" is not an answer. Ask again until you get a date. And if your site was built by someone who has since vanished, that gap is its own risk, which we covered in 7 red flags when hiring a web designer in Chicago.

How to Protect Your Site From PHP2Shell: 6 Steps

Patch first, verify second, then hunt and clean up. Steps 2 to 5 need server access, so hand them to your developer or host if terminals are not your thing.

Step 1: Find your PHP version and server type

In WordPress, go to Tools → Site Health → Info → Server. It shows your PHP version and SAPI, which tells you whether you are on mod_php (apache2handler) or PHP-FPM (fpm-fcgi).

Step 2: Do not trust the version number alone

This trips up even experienced admins. Hosts and Linux distributions often backport fixes, so an older-looking version can be patched, and Hostinger tells its managed customers to check for a build date of 21 October 2026 or later. Check the package changelog too:

# Debian or Ubuntu (change the package name to match your version)
apt changelog php8.3-fpm | grep -E "CVE-2026-10961[89]"

# RHEL, Rocky or AlmaLinux
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"

Keep in mind that php -v reports the command-line PHP, which may differ from the PHP serving your website.

Step 3: Update PHP and restart every worker

Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor backport. Then restart, because a running worker keeps the old code in memory. Test on a staging copy first if you can, but do not let testing turn into a week of delay.

# Example for Ubuntu with PHP-FPM
sudo apt update && sudo apt install --only-upgrade php8.3-fpm
sudo systemctl restart php8.3-fpm

# Example for Apache with mod_php
sudo systemctl restart apache2

Worth knowing before you pick a version: PHP 8.2 reaches end of life on 31 December 2026. Upgrading to 8.2 today buys you about eight weeks. If you are moving anyway, go to 8.3 or newer and check theme and plugin compatibility first.

Step 4: Use temporary mitigations only if you truly cannot patch today

PHP is blunt that these measures reduce exposure but "do not make an installation safe." Its advisory lists setting memory_limit=-1 where applications cannot override it, limiting request size, and setting session.upload_progress.enabled=0, all applied in php.ini or the FPM pool and followed by a worker restart. Do not rely on ini_set() or .user.ini. Removing a memory limit also has its own stability cost, so treat this as hours or days, not a solution.

A WAF helps during this window, but Cloudflare says it does not replace patching. Attackers are mutating their requests, and anyone who can reach your origin server directly skips the WAF entirely.

Step 5: Hunt for signs of compromise

Search back to at least 17 October, the earliest reported attempt. Recorded Future warns that application logs may show little because the attack happens below the application layer, so read your web server logs as well.

# POST requests that returned HTTP 500 (Apache or Nginx combined log format)
awk '$6 ~ /POST/ && $9 == 500' /var/log/apache2/access.log

# PHP memory errors and worker crashes
grep -Ei "allowed memory size|out of memory|segfault" /var/log/apache2/error.log

# PHP files created or changed since 17 October
find /var/www -type f -name "*.php" -newermt "2026-10-17"

# Active SSH sessions (question any remote address you do not recognise)
ss -tnp | grep ssh

A hit is a lead rather than proof, since legitimate updates also change files. In WordPress, also check for unknown admin users and new scheduled tasks, and look up your domain in Google's Safe Browsing status tool. A browser warning does lasting damage to credibility, which is part of why customers stop trusting a website.

Step 6: Rotate secrets if you ran unpatched

Do this even if everything above looks clean. PHP2Shell can leak server memory, which iTWire notes may hold passwords, session tokens and API keys, and a read of memory leaves no file for a scanner to find. Rotate in this order:

1. Database password and WordPress salts in wp-config.php, which also logs everyone out
2. Payment gateway, email (SMTP) and other API keys
3. Admin, hosting and SFTP passwords

If you find evidence of a breach: isolate the system and preserve your web server and PHP logs before you clean anything. If customer data may be involved, get legal advice on notification duties. U.S. businesses can report incidents to the FBI at ic3.gov.

Five Mistakes That Leave Sites Exposed

Each of these feels like progress and leaves the actual hole open.

1. Updating WordPress and calling it done. Core and plugin updates are good hygiene, but they do not touch the PHP runtime.
2. Patching without restarting. Workers that are still running keep serving the old code until they are restarted.
3. Treating a WAF as the fix. It filters known request patterns, and attackers are actively changing theirs.
4. Stopping at the first clean scan. A malware scan looks for files. It cannot tell you whether secrets were read from memory.
5. Forgetting the other PHP on the server. phpMyAdmin, webmail, an old staging site and a forgotten subdomain can all sit on the same exposed runtime.

Three Lessons Most Coverage Missed

1. Your real risk may be the version you forgot about

Among PHP services showing a readable version, Modat found about 79% on an unsupported branch, with PHP 7.4 alone at 878,761 services, according to Recorded Future. PHP published source backports for 7.4, 8.0 and 8.1, but it no longer ships updates for those versions, so most owners depend on a vendor to apply them. A years-old PHP version usually signals other deferred work, the kind we describe in why a strong backend defines your website's success. If the site cannot run on a supported version at all, that is one of the clearer signs your website needs a redesign.

2. Going offline is a business decision you should make before the emergency

The NSA's guidance came down to update or go offline. Governments could absorb a few quiet days, but a shop or a lead-generating site loses money every hour it is dark. So decide now: who has the authority to pull the site, how quickly can your host patch, and what will customers see? A branded maintenance page and a phone number beat an error screen. We break down the wider damage in the real cost of a bad website for your business.

3. AI is shrinking the time you have

Wiz used multiple AI models in finding these flaws, per Newsweek, and attackers used AI to help build tooling in Dream's case. iTWire quotes OpenAI's Greg Brockman saying, "We expect to find many more such issues over upcoming months." Our view is simple: "patch when we get around to it" no longer works for internet-facing software. Every business site needs a named owner for the server layer and a target of patching critical flaws within a day. The same logic applies if you are weighing up using AI to build your website: someone still has to own what runs underneath it.

How Seven Seas Web Design Can Help

If you would rather have a developer look at this than read log files, that is what we are here for. We have been building websites for small businesses since 2014, working with companies across Gurnee, Waukegan, Libertyville and the wider Chicago area, and clients nationwide.

Our WordPress malware removal service starts with a free malware check. Cleanups are done by hand by one developer from start to finish: full backup, file-by-file review against clean originals, database cleanup, removal of backdoors and rogue admins, closing the entry point, and resetting passwords and security keys. You also get Google Safe Browsing and Search Console review requests, a written report with the root cause, and 30 days of free reinfection cover. No fix, no fee.

If a hack has already filled your site with spam pages, our SEO services in Chicago can help rebuild what it cost you in search. If the honest answer is that your old site cannot run on a supported PHP version, our Chicago web design team can rebuild it properly, and our guide to small business website costs in Chicago breaks down the numbers.

Frequently Asked Questions

What is PHP2Shell?

PHP2Shell is the name for two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619, each rated CVSS 9.2. They can let an attacker with no login run code on a server or read its memory. Fixes shipped on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Does updating WordPress fix PHP2Shell?

No. The flaws sit in PHP, underneath WordPress. Updating core, themes or plugins does not close them. The PHP runtime on your server has to be patched and its workers restarted.

Were government websites hacked by PHP2Shell?

Most government sites that went dark were taken offline on purpose as a precaution, and most agencies reported no compromise. The clearest reported government-linked breach is Dream's account of three systems in a U.S. government-affiliated environment. A separate claim about a European government agency was retracted.

Is a firewall or WAF enough to stop PHP2Shell?

No. A WAF can buy time, but Cloudflare itself says it does not replace patching, attackers are changing their requests, and traffic that reaches your server directly bypasses the WAF.

I am on shared hosting. Do I need to do anything?

Your host should patch the server, but you should confirm it in writing. Ask whether the patched PHP build is live on your account, when workers were restarted, and whether old PHP versions on the server received a backported fix.

Is PHP 8.1 or older safe if my host says it is patched?

It can be, because some distributions and vendors ship backported fixes, but the PHP project no longer updates those versions. Treat a backport as a stopgap and plan an upgrade. PHP 8.2 itself reaches end of life on 31 December 2026, so aim for 8.3 or newer.

How do I know if my site was already compromised?

Review logs back to at least 17 October 2026 for POST requests returning HTTP 500 and PHP memory errors, and look for unexpected PHP files, new admin users and changed scheduled tasks. Clean results do not prove a memory leak did not happen, so rotate secrets if the site ran unpatched.

Can a PHP2Shell compromise hurt my Google rankings?

It can. A compromised site can pick up spam pages, redirects or a Safe Browsing warning, all of which damage search visibility and customer trust. Check your domain in Google Search Console and clean up quickly if anything looks wrong.

Can Seven Seas Web Design help with PHP2Shell?

Yes. Seven Seas Web Design offers a free malware check and manual WordPress malware removal with a written root-cause report. Call (630) 202-8781 or email info@sevenseaswebdesign.com.

Check Your PHP Today, Then Let Us Check the Rest

PHP2Shell did not break the internet, but it did show how fast a hidden layer can become everyone's emergency. Confirm who owns your PHP patch, verify the build, check your logs back to 17 October, and rotate secrets if you ran exposed. The sites that get hurt from here will mostly be the ones nobody was watching.

Once you are patched, keep it that way. Explore our web design and digital marketing services, or read our website launch checklist for the steps worth building in from day one.