PHP security release September 2026: are you exposed?

If you run PHP 8.2, 8.3, 8.4 or 8.5 in production, check the version serving traffic before you read further. Security releases landed on all four branches — 8.2.34, 8.3.35, 8.4.26 and 8.5.11 — covering advisories published on 2026-09-24. The highest-rated is unbounded recursion in the SOAP server parser (CVE-2026-91765, CVSS 7.5), where an unauthenticated POST of deeply nested XML exhausts the stack and crashes the process. Next is an IPv6 bypass of the FastCGI client allowlist (CVE-2026-91768, CVSS 6.5). The advisories also cover the HTTP stream wrapper, which matters to any code that fetches an http:// URL with a stream context. Upgrading is the entire fix; no ini setting closes the SOAP hole.

What actually broke in the September 2026 PHP security release

Most of these are single-line mistakes inside PHP's own C extensions, which is why they are worth reading even when your framework hides the internals. CVE-2026-93682 (medium, CVSS 5.3) is an out-of-bounds read in the HTTP stream wrapper: a redirect response carrying an empty Location header makes the code read one byte past a heap buffer sized exactly location_len + 1, and that stray byte decides whether the client is redirected to the host root or the current directory. CVE-2026-91766 (medium, CVSS 5.9) is the same wrapper forwarding Authorization, Cookie and Proxy-Authorization headers through a redirect to a different host, a different port, or an HTTPS-to-HTTP downgrade — the class of bug libcurl fixed in 7.58.0 under CVE-2018-1000007. A server that can steer the redirect receives credentials meant for the original origin.

Am I affected? Match the branch, not the framework

You are affected if the PHP binary answering requests is older than the patched build for its branch — the framework version tells you nothing here. The advisory data maps packages to fixed versions directly:

• ext-standard (HTTP stream wrapper): vulnerable below 8.2.34, 8.3.35, 8.4.26 and 8.5.11 respectively
• PHP-FPM (the listen.allowed_clients check): vulnerable below 8.2.34, 8.3.35, 8.4.26 and 8.5.11
• ext-soap (server-side cleanup_xml_node): vulnerable below 8.2.34, 8.3.35, 8.4.26 and 8.5.11
• ext-filter (FILTER_SANITIZE_ENCODED): vulnerable below 8.2.34 and 8.3.35, but fixed earlier at 8.4.25 and 8.5.10

That last one is low severity, CVSS 3.7. The advisory describes a 256-entry lookup table initialised with memset(tmp, 1, sizeof(tmp) - 1), leaving entry 255 to be read from whatever was on the stack, so the byte 0xFF is sometimes passed through raw instead of percent-encoded. Expect inconsistent filter output, not a crash. The published record for that advisory lists no CVE identifier.

What to do in the next 24 hours

Upgrade to the patched build for your branch, restart the process that serves traffic, and then prove the new binary is the one answering requests. On Debian and Ubuntu, apt-get update followed by apt-get install --only-upgrade on the php-fpm, php-cli and mod-php packages for your minor version; on RHEL-family images, dnf upgrade the distro or remi PHP packages. Verification is a separate step, because the upgrade succeeding and the running worker being new are different facts. php -v describes the CLI binary only. Load a phpinfo() page through the real vhost, or compare the FPM master process start time from systemctl status against your deploy timestamp.

Watch for 502s from the upstream after the restart, segmentation faults in the FPM error log, and — if you expose SoapServer at all — request bodies with unusually deep nesting. If you pass credentials into the stream wrapper through stream_context_create(), rotate anything that could have travelled a third-party redirect chain since your last patch. Teams with a live version inventory get through this in an afternoon; if yours lives in a spreadsheet, our architecture notes cover how to keep it nearer the build.

Where AI-assisted review actually helps

The advisories do not say how these bugs were found, and nothing here credits AI — but the workflow around them is where these tools earn their keep. The bugs are the kind a reviewer catches by staring at a constant and asking what type it belongs to: the FastCGI access check compared IPv6 addresses with a hard-coded length of 12 where an exact comparison needs all 16 bytes of struct in6_addr, and the filter table was memset with sizeof(tmp) - 1. Pointing a code model at a diff like that, with surrounding types in context, is a reasonable second pass. It is not a substitute for reading the advisory.

The more reliable use is inventory and verification. Ask a model to map your repos, Dockerfiles and CI images to PHP minor versions, then cross-check its list against the ranges above before trusting it. Let it draft the upgrade PR and the regression test, but read the diff yourself — AI assistants are equally fluent at telling you a version is patched when it is not, and only the binary on the box settles that.

The wider picture: RCEs and a hardening push

The September advisories are the routine end of PHP security work; the same period also produced two critical remote code execution fixes. The PHP Foundation's own write-up from 2026-10-21 describes CVE-2026-109618 and CVE-2026-109619. The first is RCE via out-of-memory corruption — a request reaching memory_limit at exactly the wrong moment leaves partially initialised internal data that PHP later treats as valid. On Apache with mod_php the Foundation states an unauthenticated request can trigger this before any application code runs, with full remote code execution demonstrated on default settings, and confirmed on PHP-FPM through application-level code paths. The second is RCE via stale global state after a fatal error. Check the changelog for the exact build you install rather than assuming one upgrade covers everything.

Where to start

Get php -v and php-fpm -v from every host that terminates PHP, compare each against the ranges above, and patch the ones that fall short before anything else on the sprint. If you would rather hand the audit over, Maysan Labs can take it from there — or start with how we run production servers.