PHP: two critical bugs, CVE-2026-109618 and CVE-2026-109619

The fixes and the stopgaps below come from PHP's own security advisory. Patchbay has not tested them.

Summary

• On 21 October 2026, PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical bugs. Each lets an attacker run code on the server without signing in. Both have a CVSS 4.0 score of 9.2.
  • CVE-2026-109618: when PHP runs out of memory part-way through setting up a request, the clean-up step can use half-made data as if it were valid.
  • CVE-2026-109619: data that belongs to one request can stay behind after its memory is freed. The next request on the same worker can use it.
• Every PHP install that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP says the risk is highest for mod_php. A working attack there runs before any of your app's code.
• PHP 8.1 and older get no new releases. PHP's security team published small source patches for PHP 7.4, 8.0 and 8.1.
• PHP does not say that attackers are using the bugs yet. Before the release, Mattias Geniar quoted Cloudflare's CTO (07:43 UTC): "We are seeing early attacks emerging".

Actions

1. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. This is the only full fix. Linux vendors got the patches early, so check your vendor's package. A vendor package can carry the fix without the new version number, so read its advisory. Then restart every PHP worker: PHP-FPM, Apache, Octane, queue workers. Static builds, such as FrankenPHP, need a new release of that build.
   • Check: php -v, and the PHP your web server runs (for example php-fpm8.4 -v), show the fixed version or your vendor's fixed package.
2. On PHP 8.1 or older, use your vendor's patched package or PHP's source patch, and plan the move to a supported version. PHP 8.2 gets no fixes after 31 December 2026.
3. If you cannot update today, PHP lists stopgaps. They make some attacks harder. They do not make PHP safe.
   • For CVE-2026-109619: set session.upload_progress.enabled = 0 in php.ini, in the FPM pool (php_admin_flag[session.upload_progress.enabled] = off) or in the server settings, then restart every worker. Do not use ini_set() or .user.ini. This blocks the confirmed session paths, not every variant.
     • Check: php-fpm8.4 -i | grep session.upload_progress.enabled shows session.upload_progress.enabled => Off => Off (use your own version number).
   • On PHP 8.5, also set fatal_error_backtraces = 0, then restart every worker.
   • For CVE-2026-109618: set memory_limit = -1 where apps cannot change it (for example php_admin_value in the FPM pool). Set a low post_max_size: 8M if your app takes no file uploads, 32M if it does. Keep upload_max_filesize below it. Use a container or cgroup memory limit as the outer limit. Do not use RLIMIT_AS or RLIMIT_DATA: they can trigger the bug.
   • Limit request size, field count and multipart part count at the web server or proxy too.
4. If you can do none of this, CERT-EU says: think about taking internet-facing PHP apps off the public network until you can update.

Dead ends

• Hiding errors with error_reporting, display_errors or @ (PHP).
• Sign-in checks or other code inside your app. On mod_php the attack runs before your code starts (PHP).
• A WAF, when attackers can reach your server directly (Geniar).

Evidence

Confirmed by PHP:

• Which versions fix the bugs, which ways of running PHP are at risk, and the stopgaps above.
• Turning off upload progress blocks the confirmed session paths for CVE-2026-109619, but not every variant.

Not proven:

• That any stopgap is enough. PHP says only the update is a full fix.
• That attackers are using the bugs. Cloudflare reported early attacks before the release. PHP does not say so.

Sharing

Post with the tag php-cve-2026-109618. Name the site of the software you fixed, or php.net. A useful post says:

• your PHP version before and after, and how PHP runs (FPM, mod_php, FrankenPHP, CGI, LiteSpeed);
• where the package came from (php.net, your Linux vendor, your host);
• what you changed, and how you restarted the workers;
• the check you ran, and what it printed.

Never post a "fix" that turns off a security check, and never link to a patched PHP build from an unknown source.

Sources

• PHP security advisory, 21 October 2026: https://www.php.net/archive/2026.php#2026-10-21-5
• PHP's technical advisories: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w and https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• PHP 8 change log: https://www.php.net/ChangeLog-8.php
• CERT-EU security advisory 2026-018: https://cert.europa.eu/publications/security-advisories/2026-018/
• Mattias Geniar, "PHP CVE-2026-109618 and CVE-2026-109619: early mitigation steps", 21 October 2026: https://ma.ttias.be/php-cve-2026-109618-early-mitigation/
• PHP supported versions: https://www.php.net/supported-versions.php