PHP 8.5.11, 8.4.26, 8.3.35, 8.2.34: Which Security Fixes Reach You

On 24 September 2026 the PHP project released 8.5.11, 8.4.26, 8.3.35 and 8.2.34, all marked as security releases. The changelogs list 11 GHSA advisories fixed across all four branches, plus one more in 8.3.35 and 8.2.34. Most are memory safety bugs in specific extensions, but three change behaviour that ordinary applications rely on: PHP-FPM's IPv6 client allow list, TLS hostname verification, and what happens to credential headers when an HTTP stream follows a redirect.

What's affected

All supported branches. Fixed versions are 8.5.11, 8.4.26, 8.3.35 and 8.2.34.

The three advisories most likely to matter:

CVE-2026-91768 (GHSA-62xp-839h-2637), PHP-FPM IPv6 ACL bypass, CVSS 6.5. The IPv6 branch of the FastCGI client check in fcgi_is_allowed() compared only the first 12 bytes of a 16-byte address. So listen.allowed_clients effectively matched a /96 prefix, not an exact address. The advisory's proof of concept: a pool with listen.allowed_clients = ::2 accepted a request from ::1. Unix socket and IPv4-only setups are not affected, and neither are deployments where a firewall is the real boundary.

CVE-2026-91769 (GHSA-vvx9-73fr-5jjx), TLS CN fallback, CVSS 4.3. When a certificate's subjectAltName entries didn't match the requested name, PHP's OpenSSL streams fell back to the Common Name. A certificate with CN=victim.test and SAN=DNS:attacker.test was accepted for victim.test. This affects file_get_contents(), fopen() and stream_socket_client() over https:// and tls://. Now, if a certificate has any DNS, URI or SRV-ID SAN and none match, verification fails. The advisory says it matters most for private PKI and internal CAs.

CVE-2026-91766 (GHSA-fpwc-w8rq-cr92), credentials leaked on redirect, CVSS 5.9. When the http:// stream wrapper followed a redirect, it forwarded Authorization, Cookie and Proxy-Authorization headers set through stream_context_create() unchanged, even to a different host or port, or from HTTPS down to HTTP. The fix strips those headers on any cross-origin hop and keeps them stripped on later hops.

The other fixes, all in every branch:

• CVE-2026-91767: heap overflow matching a crafted wildcard CN in a server certificate (OpenSSL)
• CVE-2025-1218: packet overreads in the mysqlnd wire protocol
• CVE-2026-6103: integer overflow in Phar TAR parsing allowing entry injection
• CVE-2026-91765: unbounded recursion in SOAP server cleanup
• CVE-2025-14181: integer overflow to buffer overflow in SOAP HTTP parsing
• CVE-2026-93682: out-of-bounds read following a redirect with an empty Location header
• CVE-2026-92842: out-of-bounds read in convert.* stream filters
• CVE-2026-17545: Windows reserved device names not rejected before file I/O

8.3.35 and 8.2.34 also fix GHSA-ch8v-r6jh-4vvr, where FILTER_SANITIZE_ENCODED did not encode the byte 0xFF.

How to check if you're exposed

Confirm the running version, not the one in your Dockerfile:

php -v
php-fpm -v

FPM over IPv6. Find pools that listen on TCP and rely on an allow list:

grep -rnE "^\s*listen\s*=|listen\.allowed_clients" /etc/php*/ /usr/local/etc/php-fpm* 2>/dev/null

You're in scope if listen uses an IPv6 address and listen.allowed_clients is your access control.

Credentials on redirects. Look for stream contexts that send auth headers:

grep -rnE -A6 "stream_context_create" --include=*.php . | grep -iE "authorization|cookie"

Any call that sets Authorization or Cookie in the header option and leaves follow_location at its default of following redirects was exposed if the remote server could redirect elsewhere.

Private PKI. If your PHP code calls internal services over TLS with a custom cafile, it was relying on hostname verification that had the CN gap.

What to do now

1. Upgrade to 8.5.11, 8.4.26, 8.3.35 or 8.2.34. For containers, pull the new base image and rebuild; a cached php:8.3-fpm layer won't update itself.
2. Restart PHP-FPM after upgrading so workers load the new binary.
3. Move FPM to Unix sockets where web server and FPM share a host. That takes the IPv6 allow list out of the picture.
4. Set follow_location to 0 in stream contexts that carry credentials, or switch those calls to an HTTP client that drops auth headers on cross-origin redirects.
5. Test internal TLS after upgrading. Certificates with SANs that don't include the name you connect to will now fail. Reissue them with correct SANs instead of disabling verification.
6. Rotate tokens used in stream contexts against endpoints you don't control if they could have redirected elsewhere.

Why it matters

A release with 11 advisories invites patch-and-forget, and patching is the right first move. But triage is still worth doing, because two of these bugs changed security decisions without crashing anything. An allow list that silently became a /96 range and a redirect that silently carried a bearer token both look like working code. The only sign is in the logs of the system that received the request.

Also note the deliberate breaking change in the TLS fix. Some internal services will start failing verification because their certificates were only ever valid by CN. That failure is the fix working.

Try it yourself

Write a tiny PHP script that calls file_get_contents() with an Authorization header against a local server that answers with a 302 to a second local server on another port. Run it on your old PHP version and on the patched one, and log the headers the second server receives. You'll see exactly what CVE-2026-91766 changed.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• PHP 8 ChangeLog (8.5.11, 8.4.26, 8.3.35, 8.2.34)
• php.net release announcements
• GHSA-62xp-839h-2637: IPv6 ACL bypass in FastCGI listen.allowed_clients
• GHSA-vvx9-73fr-5jjx: TLS hostname verification falls back to CN after SAN mismatch
• GHSA-fpwc-w8rq-cr92: Cross-origin credential leak in HTTP stream wrapper redirects