What happened
On October 21, 2026, the PHP project released emergency updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Security firm Wiz Research found them and named them PHP2Shell.
Both flaws are memory-safety bugs inside PHP itself, not in a plugin or theme. One lets a carefully crafted request leave PHP’s internal data half-built when it runs out of memory. The other lets leftover data from one visitor’s request be reused by the next. An attacker can use either one to run their own code on the web server. That means they can change your pages, plant malware, steal customer data or use your server to attack others.
Wiz showed working takeovers against current WordPress, Drupal and Joomla installs. They also showed that even without a full takeover, the bugs can leak passwords, tokens and API keys from the server’s memory.
Why this one is different: most website hacks need an out-of-date plugin or a weak password. PHP2Shell needs neither. Wiz says every PHP version released in the last decade is affected by at least one of the flaws, back to PHP 5.4.
How it unfolded
- Wiz Research finds the first flaw.
- Wiz reports the flaws privately to the PHP security team.
- PHP announces a critical release for the next day. Details leak ahead of the planned disclosure.
- Hosting companies report attacks. Cloudflare reports early attacks and adds firewall rules. Some sites go offline as a precaution.
- PHP releases the fixed versions and tells everyone to update immediately.
Reports on how widely the flaws are being used in real attacks still differ. Some security teams report active exploitation, while others have seen only probing so far. Either way, the details are public, and the advice from PHP is the same: “There are no complete mitigations, updating is the only safe choice.”
Is your website affected?
Your site is likely exposed if it runs on PHP and the server has not been updated since October 21. That includes:
- WordPress, Drupal, Joomla, Magento and most other self-hosted site builders and stores.
- Sites on shared hosting, a VPS or a managed host that has not yet rolled out the update.
- Staging copies, old landing pages and forgotten sub-sites on the same hosting account.
- Anything on PHP 8.1 or older. The PHP project no longer fixes those versions, so they will not get an official patch.
Not sure what your site runs on? That alone is a warning sign. Someone should be able to tell you within minutes.
What to do today
- Ask your host or web person one question: “Is our PHP on 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or a vendor-patched build, and when was it updated?” Get a yes and a date.
- Check every site, not just the main one. Staging copies and old sub-sites on the same account count.
- If you’re on PHP 8.1 or older, plan an upgrade now. Ask your host for a patched backport in the meantime.
- Skip “quick fix” plugins and copy-pasted code snippets. They don’t fix a flaw inside PHP itself.
- If you can’t update today, put a high-risk site in maintenance mode until you can.
- If you see strange errors, such as repeated “500” errors or memory-limit warnings, treat the site as possibly compromised. Change the passwords and API keys it stores.
The bigger lesson
Every website is software, and all software gets security flaws. The question is never if a fix is needed, but who applies it and how fast. For a lot of small businesses, the honest answer is “nobody, until something breaks.” The person who built the site moved on, the hosting login lives in an old email, and updates wait until a customer says the site looks strange.
Flaws like PHP2Shell are exactly why we don’t sell a website and walk away.