On 21 October 2026, the PHP project shipped emergency security updates for two critical flaws known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Both allow unauthenticated remote code execution, which means an attacker could run commands on a web server without ever logging in. Each carries a CVSS v4.0 score of 9.2, and details leaked online ahead of the planned disclosure, forcing the release forward. For any business running PHP, this is a website security event that deserves attention today, not next quarter.
Who Is Affected
The flaws sit in PHP core, so every installation that serves web requests is exposed, whether it runs PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. Fixes are available in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older branches have reached end of life and received no official release, so those sites must move to a supported version or rely on a vendor backport. Security firm watchTowr reported exploitation in the wild by 21 October, while CISA said it had not observed exploitation that same day. The UK's NCSC advised organisations to consider taking offline any system that cannot be patched immediately, and Cloudflare deployed temporary firewall rules as a stopgap.
Why Smaller Sites Feel It First
Many business sites sit on cheap shared hosting, or leave behind forgotten staging copies, campaign pages and microsites that nobody updates. These are exactly the environments attackers scan for. A successful breach rarely ends with a defaced homepage: it can mean stolen customer data, planted malware and spam links that damage search rankings for months. HKCERT's Q1 2026 report links website defacement to unpatched vulnerabilities, weak passwords and poor configuration, which is a reminder that basic hygiene still decides most outcomes. If the worst happens, our hacked website response guide explains the first steps.
What to Do This Week
Start by inventorying every PHP environment you run, including production, staging, admin panels and hosting control panels. Confirm the exact PHP version with your host, then upgrade to a patched release or ask for a vendor backport. Take a fresh backup before and after the change, and review server logs for unusual child processes spawned by PHP workers. The PHP team has also published an advisory about a configuration-dependent flaw (CVE-2026-115560) and suggested disabling session.upload_progress as a temporary measure, so check php.net for the latest status. Regular security scans and a written audit checklist make this kind of response far faster next time. For a broader view, see our FAQ on how important website security really is.
Patching is the first layer, not the only one. Placing a web application firewall or CDN in front of your site buys time while updates are tested, and DDoS protection and uptime monitoring help you notice when something is wrong. Limit what PHP can do on the server as well: disable unused extensions, tighten file permissions and keep admin areas behind strong authentication. Our cybersecurity best practices and the cybersecurity guide show what good looks like before the next advisory lands. Finally, agree who owns patching. When a critical advisory appears on a Wednesday afternoon, the businesses that cope best are those where one named person, or one trusted support partner, already has access, a staging copy and the authority to act the same day.
