The short answer
PHP2Shell is the name given to two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619. PHP fixed them on October 21, 2026 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (source: php.net security advisory, October 21, 2026; php.net release archive). If your website runs on WordPress, WooCommerce, Magento or other PHP software, it is in scope. What you need to do depends on who manages the PHP on your server. As of October 23, 2026, many shared and managed hosts had reported patching PHP for customers on their managed plans. If you run your own VPS, cloud server or self-managed control panel, nobody patches it for you (source: GoDaddy). Everyone should also apply PHP’s recommended setting for a related flaw, CVE-2026-115560, which the October 21 releases don’t fix (as of October 23, 2026) (source: php.net advisory on CVE-2026-115560, October 23, 2026).
In one minute
- What: two flaws in PHP itself, not in your plugins or theme. Under certain conditions, an attacker who isn’t logged in can run code on an unpatched server (source: php.net security advisory, October 21, 2026).
- To do: get the patch confirmed in writing, or apply it. Restart PHP, apply the CVE-2026-115560 setting, and check for signs of trouble since October 17 (source: php.net advisory on CVE-2026-115560, October 23, 2026; BleepingComputer).
- Proof: a version number alone can’t prove you’re patched (source: AlmaLinux).
- Next deadline: PHP 8.2 stops getting security fixes on December 31, 2026 (source: php.net supported versions).
What happened?
| Date (2026) | What happened |
|---|---|
| October 17 | Amazon’s threat intelligence team saw the first exploitation attempts, four days before the fixes were released (source: BleepingComputer). |
| October 20 | PHP pre-announced a critical security release (source: php.net security advisory, October 21, 2026). |
| October 21 | PHP released fixes in 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (source: php.net release archive). The US CISA urged immediate patching (source: CISA). The UK NCSC told organisations to “Update to the latest version of PHP” (source: UK NCSC). |
| October 21–23 | Governments, banks and airlines took some services offline as a precaution while they patched (source: Reuters via Internazionale). Many hosts reported patching their managed plans (source: GoDaddy). |
| October 23 | PHP disclosed a related flaw, CVE-2026-115560, that the October 21 releases don’t fix, and recommended a configuration change in the meantime (source: php.net advisory on CVE-2026-115560, October 23, 2026). |
What is PHP2Shell, in plain English?
Your website software is written in PHP: WordPress, WooCommerce, Magento, a Laravel app or custom code. Underneath it, the PHP engine on your server handles each visitor’s request and runs your site’s code. PHP2Shell is the name security firm Wiz gave to two flaws in that engine (source: php.net security advisory, October 21, 2026).
The problem sits below your website software, so updating WordPress, your plugins or your theme doesn’t fix it. The PHP version underneath is set by your hosting environment, and WordPress auto-updates don’t change it (source: WordPress.org version statistics).
- Severity. PHP’s security team rated both flaws 9.2 out of 10; other organizations score them differently (source: php.net security advisory, October 21, 2026).
- Reach. Nearly every PHP version back to 5.4 is affected. Researchers rate Apache with mod_php as the highest-risk setup (source: Beazley Security Labs). Default configurations are affected (source: Datadog Security Labs).
- Secrets. One of the flaws can leak memory from other visitors’ requests, which may include passwords, session tokens and API keys (source: The Hacker News).
- Difficulty. Experts disagree. The PHP Foundation “did not identify any functional exploits at the time of release/public disclosure.” (source: The PHP Foundation) Proof-of-concept code has circulated since about October 21, though researchers said on October 23 that many published versions don’t work (source: CERT-EU).
Am I affected?
If your site runs on PHP, treat it as in scope until you have evidence otherwise. PHP runs 69.3% of websites whose server-side language can be identified (W3Techs, as of October 23, 2026) (source: W3Techs). So “am I affected?” is the wrong question. The useful one is: has the PHP that serves my site been patched, and who is responsible for it?
| Your setup | Who patches PHP | What to do |
|---|---|---|
| Shared or managed hosting | Your host. As of October 23, 2026, many hosts had reported patching PHP on their managed plans, including GoDaddy, Hostinger, SiteGround, WP Engine and WordPress.com (host notices, October 21–23) (source: GoDaddy). | Ask your host to confirm it in writing. Use our email template. |
| Your own VPS, cloud server, dedicated server or self-managed control panel | You, or whoever runs the server for you. Nobody patches it automatically (source: GoDaddy). | Patch, restart and verify this week (see below). |
| An agency or developer runs it | Ask them. Don’t assume. | Send them the same template. |
| PHP 8.1 or older, on any hosting | No official PHP release fixes it. The fix has to come from your host, your Linux distribution or a paid extended-support provider, or you upgrade (source: Beazley Security Labs). | Ask which fix you’re on, and plan the upgrade. |
Not sure which setup you have? Your hosting account or invoice names the plan. “Shared hosting”, “managed WordPress” and “web hosting” usually mean the host runs PHP. “VPS”, “cloud server”, “instance” and “dedicated server” usually mean you do.
A version number alone can’t settle whether you’re patched (source: AlmaLinux). How to prove your server is patched explains what to collect instead.
What should I do now?
If your host manages PHP
- Ask your host to confirm in writing that the PHP serving your site includes the fixes for both CVEs. Ask when the fix was applied and whether PHP was restarted afterwards. Email template and checklist
- Ask whether they’ve applied PHP’s recommended setting for CVE-2026-115560 at server level (source: php.net advisory on CVE-2026-115560, October 23, 2026).
- Keep the reply. It’s your evidence.
If you run your own server, or someone runs it for you
- Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your Linux distribution’s patched package (source: php.net release archive). A PHP core developer put it plainly: “the only mitigation is patching/upgrading PHP.” (source: The Hacker News)
- Restart PHP. A patched package isn’t actually running until PHP’s worker processes restart (source: AlmaLinux).
- Apply the CVE-2026-115560 setting. Turn off session upload progress (
session.upload_progress.enabled=0) in php.ini, the PHP-FPM pool or the server configuration, then restart PHP. Setting it from application code (ini_set()) or a per-directory.user.inifile doesn’t count (source: php.net advisory on CVE-2026-115560, October 23, 2026). - On PHP 8.1 or older, there’s no official release. Ask your host or distribution for a backported fix, or use a commercial extended-support provider, and plan an upgrade (source: Beazley Security Labs).
- Verify that the PHP actually serving your site is the patched one, not just the PHP on the command line (source: AlmaLinux).
Everyone, this week 6. Check for signs of compromise since October 17, when attempts began (source: BleepingComputer). Amazon’s threat intelligence team advises that defenders “should not assume the public disclosure date is the earliest date of exploitation.” (source: BleepingComputer) Ask your developer or host to look for unfamiliar files, new admin accounts, new scheduled tasks and anything unusual started by the web server. An empty log doesn’t settle it: PHP’s own advisory warns that “absence of an error in logs is not proof of safety.” (source: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)) 7. Rotate secrets if you were exposed. If your server ran unpatched PHP while reachable from the internet, change admin and database passwords and rotate the API keys and tokens stored on it (source: The Hacker News). 8. Don’t rely on a firewall alone. Web application firewalls can block many attempts and buy time, but they don’t replace the patch. Attackers changed their payloads to get past firewall rules within hours (source: Beazley Security Labs). Cloudflare says it switched on PHP2Shell rules for all its plans, including Free, from October 21, but they only protect traffic that passes through Cloudflare (source: Cloudflare).
Should I take my site offline?
Only if you can’t patch or mitigate quickly. The UK NCSC’s advice is conditional: if you can’t apply temporary mitigations in time, “you should consider taking the system offline until it can be fully mitigated.” (source: UK NCSC) CISA advised organizations that can’t update immediately, or that still run PHP 8.1 or earlier, to take PHP-based systems offline until they can be patched or updated (source: CISA).
If you do take the site offline, use a proper maintenance page. Don’t simply switch off PHP handling on the server, which can expose your site’s source code to visitors (source: Beazley Security Labs).
Come back online on evidence: the patch confirmed, PHP restarted, the CVE-2026-115560 setting applied and a compromise check done.
Has anyone actually been hacked?
As of October 23, 2026, security firms and governments had reported widespread exploitation attempts but no publicly confirmed successful compromise, with one exception. Palo Alto Networks’ Unit 42 reported a compromise at one European government entity, which hadn’t been independently corroborated (source: Beazley Security Labs).
The attempts are real: on October 22, WP Engine reported that its firewall blocked more than one million requests tied to these vulnerabilities in 24 hours, with no successful exploit attempts (source: WP Engine). This can change quickly. Check the date on this section.
What comes next: PHP 8.2’s end of life
PHP 8.2 stops receiving security fixes on December 31, 2026 (source: php.net supported versions). PHP2Shell showed what that means in practice: there is no official PHP release that fixes it on 8.1 or older (source: Beazley Security Labs). If you’re on 8.2 or older, plan an upgrade now. Go straight to PHP 8.4 (security fixes until December 31, 2028) or 8.5 (until December 31, 2029) so you only do the work once (source: php.net supported versions). The PHP 8.2 checklist covers the steps. Agencies: start with the agency triage guide.
Sourced facts
Full wording, primary sources and dates: /sources.
| ID | Fact | Primary source | Date |
|---|---|---|---|
| S-01 | Two PHP engine flaws; rated 9.2 by PHP’s security team | php.net | Oct 20–21, 2026 |
| S-02 | Fixed in 8.5.12, 8.4.27, 8.3.36, 8.2.35 | php.net | Oct 21, 2026 |
| S-02b | CVE-2026-115560 unfixed; interim setting | php.net | Oct 23, 2026 · LIVE |
| S-03 | No official fix for 8.1 and older | Beazley | Oct 21–23, 2026 |
| S-04 / S-05 | Scope; mod_php highest risk; defaults affected | Beazley · Datadog | Oct 21–23, 2026 |
| S-04b | Memory leak may expose secrets | The Hacker News | Oct 21, 2026 |
| S-05b | Managed hosts reported patching; self-managed servers are yours to patch | Hostinger · WP Engine | Oct 21–23, 2026 · LIVE |
| S-06 / S-06b / S-06c | WP Engine blocks; Amazon’s first attempts; PoCs | WP Engine · BleepingComputer · CERT-EU | Oct 22–23, 2026 |
| S-07 | No confirmed compromise except one Unit 42 report | Unit 42 | Oct 23, 2026 · LIVE |
| S-09 | Version number can’t prove a patch | AlmaLinux | Oct 21, 2026 |
| S-10 / S-10b / S-10c | Firewalls, maintenance pages, Cloudflare scope | Beazley · Cloudflare | Oct 21–23, 2026 |
| S-11 | Precautionary outages | Reuters | Oct 21–23, 2026 |
| S-12 / S-13b | NCSC and CISA guidance | NCSC · CISA | Oct 21, 2026 |
| S-30 | PHP: 69.3% of sites with a known server-side language | W3Techs | Oct 23, 2026 · LIVE |
| S-32 / S-32b / S-33 | 8.2 ends Dec 31, 2026; 8.4 2028; 8.5 2029; 7.4 ended Nov 2022 | php.net | Checked Oct 23, 2026 |
| S-36 | WordPress updates don’t change PHP | WordPress.org | Oct 23, 2026 |
| Q-02 · Q-09 · Q-10 · Q-11 | Quotes | /sources | Oct 21–22, 2026 |
Frequently asked questions
My host emailed to say we’re patched. Is that enough?
On shared or managed hosting, a written confirmation from your host is usually the strongest evidence available to you, so keep it. Check that it covers your account and both CVEs, gives a date, says PHP was restarted, and mentions the setting for CVE-2026-115560 (source: php.net advisory on CVE-2026-115560, October 23, 2026). If a customer, manager or insurer needs more than that, see How to prove your server is patched.
I’m on PHP 7.4 and my host says it’s been patched. Can I stay there?
For now, possibly, but treat it as a bridge with an end date. No official PHP release fixes 7.4 (source: Beazley Security Labs). PHP 7.4 stopped receiving official security fixes in November 2022 (source: php.net unsupported branches). Some hosts patched old branches, 7.4 included, without changing the version number (source: AlmaLinux). A backport covers the flaws it targets, not the next one. Ask your host in writing how long they’ll keep backporting fixes, and plan the upgrade.
Want a second pair of eyes?
- Patch Verification & Compromise Review. Need it in writing for a manager, customer or insurer? Your developer or host gives us read-only access: a dedicated login that can look but not change anything, shared through a secure link, never by email. We change nothing on your server, and you get a plain-English report: where each fix stands, as of a stated time, plus a check for signs of compromise since October 17. Ask for it