PHP2Shell: Why Every Organisation Running a PHP Website Should Act This Week
Two critical PHP flaws disclosed on 21 October let attackers take over web servers without logging in. Attacks are already under way, and much of the web runs PHP, including most WordPress sites.
On 21 October the PHP project released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now known as PHP2Shell. Both are rated 9.2 out of 10. An attacker doesn’t need a password or an account. A crafted web request can be enough to run their own code on the server.
That matters because PHP sits underneath a large share of the web. WordPress, Joomla, Drupal, Moodle, Magento and Laravel applications all run on it. In Ghana and across West Africa it is behind a great many corporate websites, e-commerce shops, school portals and government sites, often on shared hosting the organisation doesn’t manage itself.
This is not theoretical
Exploitation started before most people had heard of it. Amazon’s threat intelligence team recorded an attempt on 17 October, four days before the public disclosure, and has since described the attacks as broad. watchTowr and Cloudflare reported attacks on disclosure day itself. Exploit code is now circulating publicly. The UK’s NCSC and the US CISA have both told organisations to patch immediately.
If you run PHP, assume someone is already scanning for you.
What to do now
Find out which PHP version you are on. The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Anything older is vulnerable. PHP 8.1 and earlier (including 7.x and 5.x) is out of support and will not get a fix at all. If you are on one of those, upgrading is the only way out.
If a hosting provider runs your site, ask them in writing. Many shared and managed hosts are patching quickly, but don’t assume. Ask for the PHP version your site is on and the date it was updated.
Don’t forget the forgotten sites. Old marketing sites, staging copies and the previous version of a website that was replaced but never switched off are the ones that get missed. If it still answers on the internet, it counts.
Check appliances too. Firewalls, NAS units and other devices often use PHP for their web admin pages. Watch for vendor advisories and keep those admin pages off the public internet.
Treat config workarounds as a stopgap. Turning off session.upload_progress.enabled reduces the risk, but researchers have shown it doesn’t fully close the hole. Updating PHP is the real fix.
Look back from 17 October. If a system was exposed and unpatched, review its logs from that date, not just from the disclosure. Look for new admin accounts, unfamiliar files in web directories and unexpected outbound connections.
How we approached it
When the advisory landed we checked every system we run for PHP the same day, and found none in our own business platforms. That check took hours, not weeks, because we already knew what we run. A short, complete inventory beats a long patching list every time.
GDS Africa can help you find where PHP runs across your estate, confirm what your providers have patched and look for signs of compromise. If you’re not sure where you stand, get in touch.