The PHP project released security updates for four supported branches on October 21, a day after asking users to prepare for two critical vulnerabilities. Its public records now identify fixed releases for PHP 8.2, 8.3, 8.4 and 8.5, giving server operators an update route for the flaws known as PHP2Shell. The PHP 8.3 release announcement identifies both vulnerabilities; Canonical's October 21 notice connects their CVE identifiers to the PHP2Shell name.
PHP runs application code on web servers, including code used by content and commerce systems. The security notices concern that underlying software. Website operators therefore need to work with whoever supplies and runs their PHP installation, whether that is an internal administrator, a Linux distributor or a hosting provider.
Reporting cutoff: October 22, 2026. The chronology below uses dated public PHP messages. Mailing-list timestamps are shown in UTC and describe the announcements, not an independent measurement of when every download mirror received each file.
A Tuesday warning followed by Wednesday releases
At 19:34 UTC on October 20, Jakub Zelenka sent a message to PHP's public php.general list announcing a security release scheduled for October 21 at 14:00 UTC. The message, signed by the PHP security team, described two vulnerabilities rated critical under version 4.0 of the Common Vulnerability Scoring System, with scores of 9.2 out of 10.
In that October 20 message, Zelenka said the team could release earlier if details of either vulnerability become public
, or if it saw evidence of active exploitation. The announcement did not say either condition had occurred.
The next day's branch announcements supplied the specific releases. The first two mailing-list records were timestamped shortly after the scheduled 14:00 UTC release time. Announcements for PHP 8.5 and 8.4 followed later that afternoon.
| Branch | Fixed release | Message timestamp, UTC |
|---|---|---|
| PHP 8.2 | 8.2.35 | 14:00:28 |
| PHP 8.3 | 8.3.36 | 14:00:57 |
| PHP 8.5 | 8.5.12 | 14:10:11 |
| PHP 8.4 | 8.4.27 | 14:32:54 |
Each announcement identifies fixes for CVE-2026-109618 and CVE-2026-109619. CVE identifiers let administrators match a flaw across different suppliers' notices even when those suppliers use different package names and version numbers.
The first PHP advisory describes invalid internal data left during a memory-allocation failure. PHP may then use that data while cleaning up a request. The second advisory describes references to request data that remain after its memory has been freed, allowing a later request on the same worker to encounter it. Both flaws can allow an attacker to run code without first signing in.
PHP's October 21 security notice names web-serving installations including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. It identifies the highest demonstrated risk in mod_php, where an unauthenticated request can trigger an attack before application code runs.
Suppliers determine how the fix reaches a site
The PHP project said Linux distributors and long-term-support vendors had received patches before the public release. It directed users to their suppliers for updated packages. For older PHP branches, it also provided limited source-code fixes for 7.4, 8.0 and 8.1. Those source changes help maintainers produce patched builds; they do not restore those branches to regular upstream support. These routes appear in PHP's release-day notice.
Canonical published an October 21 announcement listing Ubuntu package fixes, including builds based on older PHP versions. Its notice also said applications using the interpreter could require a restart after installation and specifically required an Apache restart for mod_php. Automatic installation of a security package can therefore leave an application restart outstanding.
For a site operator, the practical consequence is a need to connect three records: the supplier's fixed package or build, the PHP service handling that site's requests and confirmation that affected workers have been replaced or restarted. The public release announcements alone do not establish the state of an individual website.
PHP also published temporary configuration measures for systems that could not update immediately. Its notice says those measures reduce selected attack paths and that an update is the complete solution. The official advisory sets out those limits.
PHP 8.2 users face another deadline in December
PHP 8.2 has a current fix for both vulnerabilities in 8.2.35. Its remaining upstream support is short: the PHP support schedule ends security support for that branch on December 31, 2026. It lists security support through December 2027 for 8.3, December 2028 for 8.4 and December 2029 for 8.5.
That schedule gives teams maintaining PHP 8.2 sites two decisions: deploy a build fixing the current flaws and plan a supported runtime for the period after December. Moving an application to a newer branch may require compatibility checks. A distributor or specialist vendor can have its own maintenance terms, so operators need to establish which support promise covers their installed package.
Primary records
- October 20: upcoming critical PHP security release.
- October 21 branch announcements: PHP 8.2.35, PHP 8.3.36, PHP 8.5.12 and PHP 8.4.27.
- PHP's release-day security notice and support schedule.
- PHP advisories: CVE-2026-109618 and CVE-2026-109619.
- Canonical's October 21 PHP2Shell update announcement.