Key details

  1. Fixed releases are PHP 8.5.11, 8.4.26, 8.3.35 and 8.2.34.
  2. CVE-2026-91768 is an IPv6 ACL bypass in PHP-FPM listen.allowed_clients caused by comparing 12 of 16 address bytes.
  3. The resulting match boundary is an IPv6 /96 prefix rather than one exact address.
  4. CVE-2026-91769 fixes TLS hostname verification falling back to CN after SAN mismatch.
  5. The release family contains additional security fixes across OpenSSL, SOAP, Phar, HTTP streams and mysqlnd.

What builders should take away

  1. Patch supported PHP branches to 8.5.11, 8.4.26, 8.3.35 or 8.2.34 as applicable.
  2. If PHP-FPM FastCGI is reachable beyond localhost, inspect listen.allowed_clients and do not treat its pre-patch IPv6 check as an exact-address security boundary.
  3. Use firewall or network-layer controls around FastCGI rather than relying on the PHP-FPM ACL as the only isolation layer.
  4. Treat outbound TLS verification fixes as relevant to PHP services that call HTTPS endpoints, not only to public-facing web requests.

What changed

On September 24 PHP shipped security releases 8.5.11, 8.4.26, 8.3.35 and 8.2.34. The coordinated fixes include CVE-2026-91768 in PHP-FPM: the IPv6 branch of the FastCGI client access check compares only the first 12 bytes of a 16-byte IPv6 address, so listen.allowed_clients effectively matches a /96 prefix rather than one exact address. The releases also fix CVE-2026-91769, where TLS hostname verification can fall back to a certificate Common Name after a Subject Alternative Name mismatch, and additional flaws across OpenSSL, SOAP, Phar, HTTP streams, mysqlnd and other components.

Why it matters

PHP remains underneath a large amount of ordinary web infrastructure, and this release is relevant even when application code has not changed. The FPM flaw weakens a network access-control boundary operators may believe is exact; an attacker still needs network reachability and an IPv6 source sharing the permitted /96, so this is not universal internet-facing RCE. The TLS bug matters on outbound connections because a failed SAN match should not be rescued by a weaker CN check. Because fixes landed across all supported branches at once, operators can patch in place rather than making a major-version migration.

The FPM ACL can be broader than its configuration looks

CVE-2026-91768 affects IPv6 handling in PHP-FPM listen.allowed_clients. Only 12 bytes of the 16-byte IPv6 address were compared, turning an intended exact-address allow rule into a /96-prefix match. Exploitation requires the attacker to reach the FastCGI listener from an IPv6 address sharing that prefix.

TLS hostname checking also received security fixes

CVE-2026-91769 fixes hostname verification falling back to the certificate Common Name after a Subject Alternative Name mismatch. The same release family also fixes CVE-2026-91767, a heap overread in wildcard-name matching for crafted server certificates.

This is a coordinated supported-branch patch

PHP published fixed releases for 8.2, 8.3, 8.4 and 8.5 on September 24 and labels them security releases. That gives production users a same-branch remediation path.

What to watch next

  • Whether distributions backport the fixes under older package version strings.
  • Any evidence of exploitation of CVE-2026-91768 or the TLS verification flaws.
  • Operational reports showing common PHP-FPM deployment patterns exposed to the IPv6 ACL condition.

Still unclear

  • CVE-2026-91768 requires network reachability plus an IPv6 source within the same /96 as an allowed address; exposure varies materially by deployment.
  • No evidence reviewed in this pass establishes active exploitation of these PHP vulnerabilities.
  • Distribution packages may carry backported fixes without matching upstream version numbers exactly.

Sources

Direct reading behind this dossier.

3 sources
PHP 8 ChangeLog
PHP primary changelog

Primary details for CVE-2026-91768, CVE-2026-91769 and the other fixes in the supported-branch security releases.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment