PHP Security Roundup Sept/Oct 2026: Critical RCE Fixes

If you administer Linux servers, the last two months were unusually loud on the PHP front: four security releases in September, an unscheduled emergency update in October, and end-of-life milestones that make version planning urgent. Here is what happened and what to do about it — every item below is drawn from php.net announcements and the linked advisories.

24 September 2026: security releases for 8.2, 8.3, 8.4 and 8.5

PHP shipped 8.5.11, 8.4.26, 8.3.35 and 8.2.34 (https://www.php.net/archive/2026.php#2026-09-24-5) as dedicated security releases for all maintained branches. The GitHub security advisories bundled in that cycle cover roughly a dozen CVEs, three of which deserve your attention:

• CVE-2026-91768 (GHSA-62xp-839h-2637 (https://github.com/php/php-src/security/advisories/GHSA-62xp-839h-2637)): an IPv6 ACL bypass in PHP-FPM's listen.allowed_clients. The FastCGI access check compared only 12 of 16 address bytes, so an attacker sharing a /96 prefix with an allowed client could reach the FPM endpoint. Unix-socket and IPv4-only deployments are not affected.
• CVE-2026-91769: TLS hostname verification in the OpenSSL extension could fall back to the certificate Common Name after a SAN mismatch — relevant mainly for connections against private PKIs and internal CAs.
• CVE-2026-91766: the HTTP stream wrapper forwarded Authorization/Cookie headers on cross-origin redirects.

The same cycle also fixed issues in SOAP, Phar, mysqlnd and the standard streams (a full cross-CVE table is maintained by third parties such as PatchMyPHP (https://patchmyphp.com/php-vulnerabilities/)). Bottom line for that release: upgrade and restart your FPM workers, and check php -v on every SAPI, not just the CLI.

21 October 2026: emergency release for two critical RCEs

Ten days ago the situation escalated. After an unusual advance notice (https://news-web.php.net/php.announce/509) — itself a sign of severity — PHP published 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (https://www.php.net/archive/2026.php#2026-10-21-5) on 21 October 2026 at 14:00 UTC, fixing two critical vulnerabilities rated 9.2 (CVSS v4.0) in the pre-announcement:

• CVE-2026-109618 — "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w (https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)): out-of-memory handling can interrupt PHP while internal request data is only partially initialized; request cleanup may then treat the invalid data as valid.
• CVE-2026-109619 — "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp (https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)): request-owned state can survive a memory-free and be reused by the next request on the same worker.

Both can allow unauthenticated remote code execution before any application code runs. php.net considers the risk highest for Apache with mod_php, where a demonstrated exploit exists, but PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also in scope. The official advisory (https://www.php.net/archive/2026.php#2026-10-21-5) is explicit: there are no complete mitigations — updating is the only safe choice. Linux vendors received patches in advance, so distribution packages were largely ready the same day.

If you cannot patch immediately

Only the update is a complete fix, but the advisory lists interim risk reductions worth applying while you work on deployment slots:

• Set memory_limit=-1 in a way applications cannot override (php_admin_value in the FPM pool or Apache config), and keep post_max_size low (8M without uploads, 32M with), with upload_max_filesize below it.
• Enforce request-size, field-count and nesting limits at the web server or proxy level; use cgroup/container limits as the availability boundary. Do not substitute RLIMIT_AS or RLIMIT_DATA — they trigger the vulnerable allocation path.
• Set session.upload_progress.enabled=0 and restart every worker. On PHP 8.5, additionally fatal_error_backtraces=0.
• Keep it disabled: on 23 October PHP added an informational advisory (https://www.php.net/archive/2026.php#2026-10-23-1) for CVE-2026-115560, an unlikely session-serialize-handler/upload_progress RCE combination, with the full fix due in the next regular bugfix release.

Older branches and the 8.2 deadline

PHP 8.1 and older receive no updates from the php.net project; only minimal source backports for 7.4, 8.0 and 8.1 were provided as a stopgap for self-compilers. Plan deliberately: per the supported versions table (https://www.php.net/supported-versions.php), PHP 8.2 security support ends on 31 December 2026 — two months out. Any 8.2 inventory should have an upgrade path to 8.3 or newer scheduled now, not after the fireworks. PHP 8.6.0 is still in release candidates (RC4 includes these fixes; RC5 is planned for 5 November 2026) and must not run in production.

Windows hosts

On 26 October, rebuilt Windows packages (https://www.php.net/archive/2026.php#2026-10-26-1) (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1) were released, bundling Brotli 1.2.1 to fix CVE-2026-111497, an out-of-bounds write in Brotli decompression. If you run PHP on Windows, check you got the -1 rebuilds, not the original binaries.

Action checklist for server administrators

• Inventory every PHP SAPI in your estate (php -v in CLI, FPM and mod_php contexts) — the NCSC guidance (https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php) for CVE-2026-109618/109619 stresses discovery, not just upgrade.
• Update to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (or your vendor's backported package) and restart all workers.
• If patching is delayed, apply the mitigations above — and treat internet-facing servers with extra urgency.
• On systems that were exposed for a while, look for evidence of compromise before declaring the job done.

Final thoughts

Two unauthenticated RCEs in the PHP core are the kind of event where hours matter, and where distribution packages, FPM pool configs and update discipline decide whether your fleet is safe. That is precisely the day-to-day work of Linux-Server-Admin.com s.r.o. (https://linux-server-admin.com): we manage Linux servers and PHP stacks, coordinate emergency patching with the affected application owners, and keep a tested update path ready — quietly, in maintenance windows, before the alerts pile up. If you would rather not navigate the next emergency release alone, our teams in Prague are one message away.

Sources

• php.net 2026 news archive and the 21 October security advisory: https://www.php.net/archive/2026.php
• GHSA-w8hw-w9fx-j79w / GHSA-6wmf-4rv5-p3rp: https://github.com/php/php-src/security/advisories
• NVD entries: https://nvd.nist.gov/vuln/detail/CVE-2026-109618 and https://nvd.nist.gov/vuln/detail/CVE-2026-109619
• PHP supported versions: https://www.php.net/supported-versions.php
• UK NCSC guidance: https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
• CERT/CC VU#763488: https://www.kb.cert.org/vuls/id/763488