PHP2Shell: critical PHP flaws prompt national security advisory

The PHP development team released emergency patches on 21 October 2026 for two critical flaws in the core of the PHP interpreter. Tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, both carry a CVSS v4.0 score of 9.2. Under the right conditions an attacker needs no username or password: a crafted request to the web server can be enough to run code on the host.

The weakness sits in PHP's error handling rather than in any application code. The longjmp() calls used for out-of-memory and fatal-error conditions leave request and global memory either uninitialised or pointing at freed regions. Later requests can read or branch on that memory, which opens the door to arbitrary code execution. The PHP Group stated that every PHP installation serving web requests is at risk, and listed PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed among the affected deployment types.

Why it matters

In its 23 October threat brief, Palo Alto Networks Unit 42 reported that Cortex Xpanse had identified more than 22.6 million internet-exposed PHP instances that were potentially vulnerable. Unit 42 also noted that proof-of-concept code is circulating, and described an intrusion at a European government body in which attackers reached password hashes and multi-factor authentication secrets within two hours of initial exploitation. CISA issued its own call for immediate patching on 21 October.

The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier are out of support and will receive no official fix, so those installations need to be moved to a supported branch instead.

What this means in Turkey and for smaller businesses

Turkey's Cyber Security Presidency issued a national advisory on 22 October, asking public institutions, critical infrastructure operators and private companies to review the PHP infrastructure they run and apply updates without delay. It also reported that checks on the e-Devlet gateway, which serves more than 69 million users, found nothing affecting service security, and that public digital services continued without interruption.

For smaller companies the picture is messier. Corporate websites, WordPress and similar content management systems, customer portals, phpMyAdmin, control panels such as Plesk and cPanel, and bespoke quoting or ERP tools written years ago all run on PHP. Most organisations cannot say offhand which PHP version each of these uses. On shared hosting the version is often chosen by the customer, so a provider patching its own platform does not automatically cover your account.

What we recommend at Kamer Bilişim

• Start with an inventory. List every system running PHP, including on-premise servers, virtual machines, hosting accounts and control panels. Confirm the active version from your hosting panel or with php -v on the server, and do not overlook PHP bundled inside vendor software.
• Move to a patched release and restart the service. Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or confirm the backported package with your distribution vendor. If you do not restart PHP-FPM or the web server afterwards, the old build stays loaded in memory and the fix has no effect.
• Take unsupported versions off the public internet. Where applications remain on PHP 8.1 or earlier, place them behind a VPN or WAF, or close them off entirely until they can be migrated. After patching, review web and PHP logs retrospectively for web shells, unfamiliar files in the web root and unexpected scheduled tasks — a patch does not undo an intrusion that already happened.

Whether your office is on the Anatolian side of Istanbul or you prefer to work with us remotely, we can map the PHP versions across your servers and hosting accounts, run the update plan with you and review the logs afterwards. Reach us through our contact page.

Source: Unit 42 (Palo Alto Networks), Turkish Cyber Security Presidency, PHP Group security advisory, CISA, Huntress