On Oct 21, 2026, the PHP project released emergency fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619. Researchers call the pair PHP2Shell. Both score 9.2 out of 10 for severity.
The flaws are present in the PHP runtime, so a site with secure code is still exposed. An attacker needs no login, and therefore, a crafted request can corrupt server memory and let the attacker run code on your server.
Every common way of serving PHP is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The flaws reach back to PHP 5.4.
As is often seen, attackers moved before many defenders could. For example, Amazon Threat Intelligence recorded an exploitation attempt on Oct 17, four days before the fix. Similarly, Cloudflare reported early attacks and added firewall rules as a stopgap. Government and police sites across the UK and Europe went offline as a precaution.
Who is at risk?
Anyone who runs PHP on a web server is at risk. PHP powers about 70% of websites whose server-side language is known. That includes WordPress, Drupal and Magento sites, plus many hosting control panels. Appliances and applications can also bundle their own PHP, so you may run it without knowing.
The damage goes beyond a defaced page. The US National Security Agency says these flaws often give attackers a direct path to a server’s file system or database. One flaw can also:
- Leak server memory, which can hold secrets such as passwords and API keys.
- Attackers can also use a hacked server to hide their own attacks or mine cryptocurrency at your cost.
If you use shared hosting, you may not know who updates PHP for you. Make sure to ask your host.
What to do today?
Work through these steps in order because every hour counts.
Step 1: Find every PHP you run
List every server, container and application that runs PHP. Start with anything facing the internet and include old test machines. Then check the products you buy. Ask each vendor whether their product bundles PHP and when they will finish patching. The Dutch National Cyber Security Centre has published a list of software with a PHP dependency that you can check against. If you own a small website and manage no servers, ask your developer or host if they have applied the PHP security fixes.
Step 2: Update to a fixed version
The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Updating WordPress or its plugins will not fix this. The update must happen on PHP itself, and WordPress automatic updates do not install it. Check your Linux vendor for patched packages. Some setups install PHP from separate repositories, so do not assume automatic updates cover it. After you update, restart long-running PHP processes. They keep running the old code until you do.
Step 3: Deal with older versions
PHP 8.1 and older no longer get official updates. The PHP security team released minimal source backports for 7.4, 8.0 and 8.1 for teams that build from source or have no long-term support vendor. Some Linux vendors also ship their own backported fixes, so check yours. Treat all of these as a bridge and plan an upgrade to a supported version. Also note that PHP 8.2 security support ends on Dec 31, 2026.
Step 4: If you cannot patch yet
The PHP team says no mitigation fully blocks these flaws. Updating is the only safe choice. If you cannot update right away, the US National Security Agency and the UK National Cyber Security Centre both advice taking the system offline. If that is not possible, put a web application firewall in front of it. Treat the firewall as a short-term bridge. Even Cloudflare’s Chief Technology Officer, Dane Knecht, called its own rules a stopgap.
Step 5: Check for damage and clean up
Assume an attacker may have reached you before the patch. The UK National Cyber Security Centre advises checking for compromise before your upgrade and looking for backdoors an attacker installed. Review your logs for memory-exhaustion errors, repeated HTTP 500 errors and PHP workers that crash or restart without cause. Watch for PHP processes that launch shell commands.
Because the flaws can expose memory, we also recommend that you change passwords, keys and tokens your servers handled. Finally, watch for phishing emails that use this story as bait.
Three checks beyond the patch
Patching closes this hole. These three checks prepare you for the next one.
Know what your applications run on
A well-tested application can still sit on a flawed runtime. PHP2Shell proved it. Many teams test their own code but never list the runtimes, frameworks and libraries underneath. Build that list for every internet-facing application. Without it, you will repeat Step 1 from scratch during every incident.
Know who must act
Say an agency manages your website, a host runs the servers and a vendor maintains the application. When a flaw appears, your customers hold you responsible. For each system, write down who patches it, how fast they must act and who confirms the fix. An annual vendor questionnaire will not give you that answer.
Measure your response time
Attackers tried this flaw four days before the public fix. A critical patch cannot wait for the next maintenance window. Time yourself. How long does it take to find vulnerable systems, protect them and confirm the fix? If the answer is days, set a target and work toward it.
How can CyberNX help
PHP2Shell shows how fast a disclosed flaw becomes an attack. Patch first. Then check for damage and close the gaps in your asset list and vendor chain.
At CyberNX, we work alongside your team to find exposed systems and respond when something looks wrong. Our Security Operations Center can watch your internet-facing PHP systems 24/7 for signs of compromise. Our vulnerability assessment and penetration testing service can confirm what an attacker can reach. Not sure where you stand? Talk to our team, and we will help you check your exposure today.
FAQs
Is my WordPress site affected?
Yes, if its server runs PHP, and most WordPress servers do. The flaws sit in PHP, not in WordPress. Updating WordPress or its plugins will not fix them. Ask your host or developer to confirm that PHP is on a fixed version.
How to check your PHP version?
On a server you manage, run php -v. Many hosting dashboards also show the version. Compare it with the fixed releases in Step 2. The command line can use a different PHP than your website does, so check your web server settings as well.
Is a firewall enough?
No. The PHP team says no mitigation fully blocks these flaws. A firewall buys you time. Patch as soon as you can.
Does patching remove an attacker who is already inside?
No. A backdoor stays after the update. Check for signs of compromise, remove anything unexpected and change the passwords, keys and tokens your servers handled. If you find signs of an intrusion, call an incident response team.
