On October 21, 2026, PHP released security versions with fixes for two remote code execution flaws. We explain who is affected and what to do.
On October 21, 2026, the PHP project released security versions for all of its supported branches: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical vulnerabilities that, according to the official announcement, can allow remote code execution on the server.
The two vulnerabilities
- CVE-2026-109618 (advisory GHSA-w8hw-w9fx-j79w): remote code execution through memory corruption when the server runs out of memory. Handling that error can interrupt PHP while the request's internal data is only partially initialized.
- CVE-2026-109619 (advisory GHSA-6wmf-4rv5-p3rp): remote code execution through stale global state. Internal information from a request can survive after the memory backing it has been freed.
The announcement makes clear that there are no complete mitigations: updating is the only full fix.
Who is affected?
Any site or application running a PHP version earlier than the fixed ones: WordPress or Joomla sites, online stores, custom systems built with Laravel, CRMs, ERPs and hosting control panels. Branches 8.1 and earlier no longer receive fixes from the PHP project, so they remain exposed unless the hosting provider applies its own patch.
What to do now
- Identify the PHP version of each site or server (in the hosting control panel or with the
php -vcommand). - Update to the fixed version of your branch: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or later.
- Restart PHP-FPM, Apache and any long-running PHP process so the update takes effect.
- If you use PHP 8.1 or earlier, plan the migration to a supported branch. Keep in mind that PHP 8.2 reaches end of support on December 31, 2026.
- Review the server logs for unusual memory errors or anomalous activity over the last few days.
October 22 update: attacks are already underway (PHP2Shell)
Researchers have named these flaws PHP2Shell. The firm watchTowr reported real-world attacks against both vulnerabilities since October 21, and Recorded Future documented that technical details leaked before the coordinated release. Branches 7.4, 8.0 and 8.1 have no official fixed release (the project published minimal source-code-only patches), and PHP 7.3 and earlier, including PHP 5, remain unfixed.
If you have already updated, review the logs from October 20 onward for unknown PHP files (web shells), new scheduled tasks, very large requests with many attached files and PHP process crashes. Sources: watchTowr's analysis of PHP2Shell and Recorded Future's timeline.
October 26 update: confirmed attacks and a third flaw
A researcher published evidence of real remote code execution on honeypots running Apache, mod_php and PHP 8.4.26: 35 web shells on three servers, consistent with CVE-2026-109618. On October 26, CISA added both flaws to its catalog of exploited vulnerabilities. In addition, on October 23 the PHP project reported a third flaw, CVE-2026-115560, which has no patch yet and can only be exploited under an unusual combination: an application that uses ini_set() to change the session format right before starting the session, while upload progress tracking is enabled. Until a fix is released, PHP recommends setting the session.upload_progress.enabled option to 0; before doing so, confirm that your application does not use file upload progress bars. Sources: PHP's informational advisory on session upload progress, CISA alert on the PHP flaws and the researcher's honeypot report.
October 30 update: Fragnesia and the unpatched flaw
On October 28, CISA confirmed that attackers chain PHP2Shell with Fragnesia (CVE-2026-46300), a Linux kernel flaw, to go from the web service user to root, with full control of the server. That is why, besides PHP, you need to update the kernel and reboot the server; we explain it in Fragnesia: the Linux flaw that worsens PHP attacks. The third flaw, CVE-2026-115560, remains unpatched as of October 30: the PHP team will include it in its next regular release, so keep session.upload_progress.enabled set to 0 if you applied that measure.
October 31 update: official sources
We checked this article against the PHP and CISA advisories and the honeypot researcher's original report. We replaced the media sources with those documents and removed an opinion that was only published on social media.
How we handle it at Pronetsys
We apply critical patches within the timeframes set by our Information Security Policy. If your site or server is on a maintenance plan with us, the update is part of the service. If you don't know which PHP version your site uses, write to us and we'll check it with you.
Source: PHP.net
