PHP 8.5.11 security release: what production teams should check

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. Together they fix eleven advisories on every supported branch, one rated high (an unauthenticated crash of any SoapServer endpoint) and the rest medium or low, covering TLS certificate checks, credential leaks on HTTP redirects, a PHP-FPM access-control bypass over IPv6, Phar archives and mysqlnd. This article lists exactly what was fixed, with the CVE and GitHub advisory identifiers from php.net, how to tell which ones affect your servers, how to check whether you are patched when your PHP comes from a distribution or a Docker image, and the three fixes that can change behaviour in production.

Checked with: the php.net ChangeLog and release announcements, the php/php-src GitHub security advisories, the Debian and Ubuntu security trackers and Docker Hub, in the first week of October 2026. The check script and redirect test below ran on an unpatched PHP 8.5.7 CLI on macOS.

Which versions to install

All four supported branches were released on the same day (PHP 8 ChangeLog; branch support dates from php.net supported versions):

PHP 8.1 and older receive nothing from php.net. If you are on 8.2, this is one of its last releases; plan the move now, using our PHP 8.2 end-of-life checklist. Laravel teams moving to 8.5 can follow our Laravel and PHP 8.5 compatibility test plan; this article does not repeat it.

What was fixed: the security advisories

Severities and scores come from each advisory in the php-src security advisories, all published on 24 September 2026. Every advisory below lists the same fixed versions: 8.2.34, 8.3.35, 8.4.26 and 8.5.11.

8.3.35 and 8.2.34 also include GHSA-ch8v-r6jh-4vvr (low, no CVE): FILTER_SANITIZE_ENCODED did not reliably encode the byte 0xFF. It was fixed publicly in 8.4.25 and 8.5.10 in August and backported now. The two CVE identifiers from 2025 are not typos: they were reserved earlier and published with these releases. Besides the advisories, 8.5.11 carries the usual bug fixes, among them several use-after-free fixes in DOM and Intl and an OPcache tracing JIT crash.

Triage: which fixes matter for your servers

Patch everything, but patch the exposed hosts first:

• Public SOAP endpoints are the clear priority. CVE-2026-91765 needs no authentication: a single nested request crashes the worker, and repeated requests take a pool down. The fix caps XML depth at 2,048 levels.
• Applications that call other services over HTTPS with PHP streams (file_get_contents('https://...'), SoapClient, stream_socket_client) are exposed to the two OpenSSL issues when talking to a hostile or compromised server. cURL-based clients such as Guzzle's default handler use libcurl's own TLS checks instead.
• Code that sends credentials through the http:// wrapper with follow_location could leak them to whatever host a redirect points at. We confirmed this on 8.5.7, shown below.
• PHP-FPM listening on an IPv6 TCP address with listen.allowed_clients accepted any client sharing the first 96 bits of an allowed address. Unix sockets and IPv4 were not affected.
• Upload features that open user TAR files with PharData, and Windows servers that build paths from user input.

Check what you are running

This script compares the running version with the patched release for its branch and lists which affected extensions are loaded. Run it with the same binary and configuration as production; PHP-FPM can use a different build from the CLI, so also call it once through FPM if in doubt. Exit code 1 means "older than the upstream fix", which for distribution packages means "check the vendor advisory", because Debian and Ubuntu backport fixes without changing the upstream version number.

<?php
declare(strict_types=1);

/**
 * Checks a PHP runtime against the 24 September 2026 security releases
 * (8.5.11, 8.4.26, 8.3.35, 8.2.34). Run it with the same binary and ini
 * files as production: `php php-sept-2026-check.php` for CLI, or call it
 * once through PHP-FPM if the FPM build differs from the CLI build.
 */
const PATCHED = ['8.5' => '8.5.11', '8.4' => '8.4.26', '8.3' => '8.3.35', '8.2' => '8.2.34'];

$branch = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;
$exit = 0;

printf("PHP %s (%s SAPI, %s)\n", PHP_VERSION, PHP_SAPI, PHP_OS_FAMILY);

if (!isset(PATCHED[$branch])) {
    echo "  ! Branch {$branch} receives no security fixes from php.net: upgrade to a supported branch.\n";
    $exit = 2;
} elseif (version_compare(PHP_VERSION, PATCHED[$branch], '<')) {
    printf("  ! Upstream version is older than %s. A distribution package may still carry backported fixes:\n", PATCHED[$branch]);
    echo "    check your vendor's advisory before deciding (Debian DSA/DLA, Ubuntu USN, Red Hat RHSA).\n";
    $exit = 1;
} else {
    printf("  ok: at or above %s\n", PATCHED[$branch]);
}

// Which advisories touch code that is loaded in this runtime?
$exposure = [
    'soap'    => 'CVE-2026-91765 (SoapServer recursion, CVSS 7.5) and CVE-2025-14181 (SOAP client HTTP overflow)',
    'openssl' => 'CVE-2026-91769 (CN fallback after SAN mismatch) and CVE-2026-91767 (wildcard CN overflow)',
    'phar'    => 'CVE-2026-6103 (TAR size overflow lets PharData expose injected entries)',
    'mysqlnd' => 'CVE-2025-1218 (packet overreads from a malicious MySQL server)',
];
foreach ($exposure as $ext => $what) {
    printf("  %-8s %s  %s\n", $ext, extension_loaded($ext) ? 'loaded ' : 'absent ', $what);
}
echo "  core     always   CVE-2026-91766 / CVE-2026-93682 (http:// wrapper redirects), CVE-2026-92842 (convert.* filters)\n";
if (PHP_OS_FAMILY === 'Windows') {
    echo "  windows  yes      CVE-2026-17545 (reserved device names such as CON or NUL in paths)\n";
}
if (PHP_SAPI === 'fpm-fcgi' || PHP_SAPI === 'cli') { // the CLI cannot see FPM pool config
    echo "  fpm      review   CVE-2026-91768: review listen.allowed_clients entries that use IPv6 addresses\n";
}
exit($exit);

To see the redirect credential leak for yourself, start two PHP built-in servers, one that redirects to the other and one that reports the Authorization header it received, then run this against them. On our unpatched 8.5.7 the token reached the second origin. On a patched build the header should be stripped; we could not run a patched 8.5.11 binary in our environment, so verify that on your own staging host.

<?php
// Does this PHP forward Authorization to a different origin after a redirect?
$ctx = stream_context_create(['http' => [
    'header' => "Authorization: Bearer test-token-not-a-secret\r\n",
    'follow_location' => 1,
]]);
echo PHP_VERSION, ': ', file_get_contents('http://127.0.0.1:4780/', false, $ctx);

# On the PHP-FPM host: which pools listen on IPv6 TCP with an allow list?
grep -RnE '^\s*listen(\.allowed_clients)?\s*=' /etc/php/*/fpm/pool.d/ /usr/local/etc/php-fpm.d/ 2>/dev/null
# Which binary and version does FPM actually run?
php-fpm8.4 -v 2>/dev/null || php-fpm -v

Upgrading: distribution packages, Docker images and source builds

Debian. At the time of writing the Debian security tracker listed the fixes as DSA-6514-1 for trixie (php8.4 8.4.26-1~deb13u1) and DLA-4819-1 for bookworm, now in long-term support (php8.2 8.2.34-1~deb12u1). Update and restart FPM:

sudo apt update
apt-cache policy php8.4-fpm          # Candidate should be 8.4.26-1~deb13u1 or later
sudo apt install --only-upgrade 'php8.4*'
sudo systemctl restart php8.4-fpm    # the old code stays in memory until FPM restarts

Ubuntu. Ubuntu backports fixes into its own version numbers. When we checked the Ubuntu CVE page in early October, php8.3 on 24.04 LTS and php8.5 on 26.04 LTS were still listed as vulnerable, meaning no update had been published yet. Until a USN appears, consider the upstream builds from a maintained repository, put a WAF rule or authentication in front of SOAP endpoints, and track the CVE page.

Red Hat, Rocky, AlmaLinux and other distributions: follow the vendor advisory for each CVE above; the package version will not match the upstream number.

Official Docker images. Docker Hub has php:8.5.11-* and php:8.4.26-* tags for the Debian (trixie, bookworm) and Alpine variants. Pin the patch version, rebuild, and confirm inside the image:

# Pin the patch release rather than a floating tag, so a rebuild is a deliberate change
FROM php:8.5.11-fpm-trixie

docker build --pull -t my-app:php-8.5.11 .
docker run --rm my-app:php-8.5.11 php -r 'echo PHP_VERSION, PHP_EOL;'   # expect 8.5.11

A floating tag such as php:8.5-fpm only helps if you rebuild: running containers keep the old binary. Also rebuild images derived from distribution base images, since apt upgrade in a running container is lost on the next deploy.

Source builds: the tarballs and SHA-256 checksums are on the php.net downloads page; verify the checksum before building.

Rolling a security release across several servers, images and PHP versions, with a restart window and a rollback plan, is routine maintenance work that is easy to postpone. If you would rather hand it off, our application maintenance and support service covers patching, verification and monitoring.

Fixes that can change behaviour

• Stricter certificate name checks. A certificate whose SAN list does not include the host name is now rejected even if its CN matches, with "Peer certificate subjectAltName did not match expected name". Internal services with badly issued certificates will start failing; certificates with no SAN at all keep the CN fallback. Test calls to internal hosts in staging.
• Credentials dropped on cross-origin redirects. If an integration relied on Authorization being forwarded from one host to another via a redirect, it will now get 401 from the second host. Call the final URL directly.
• SOAP depth limit. Documents nested deeper than 2,048 levels are rejected. Legitimate SOAP traffic is nowhere near that, but generated test fixtures sometimes are.
• Windows device names. Paths containing CON, NUL, COM1 and similar components now fail with an invalid name error instead of opening a device.

Production checklist

1. Inventory every PHP runtime: servers, FPM pools, containers, CI images, cron hosts and queue workers.
2. Patch internet-facing SOAP servers first, then everything that makes outbound HTTPS calls.
3. Install the fixed package or rebuild the image with a pinned patch tag.
4. Restart PHP-FPM, Apache with mod_php, long-running workers (Laravel Horizon, queue workers, Swoole, RoadRunner, FrankenPHP) so the new binary is actually loaded.
5. Run the check script through the real SAPI and record the result.
6. Watch error logs for TLS name mismatches and 401s from integrations for a few days.

Common mistakes

• Upgrading the package but not restarting PHP-FPM or long-running workers.
• Checking php -v on the CLI when FPM runs a different build or version.
• Treating a distribution version such as 8.3.6-0ubuntu0.24.04.x as unpatched (or patched) by comparing it with 8.3.35; read the vendor's changelog instead.
• Assuming Docker images patch themselves; they change only when you rebuild.
• Leaving PHP 8.1 or older in place because "it is internal"; no fixes will arrive for it.

When not to rush

A patch release is low risk, but it is not zero risk. If you run none of the affected features (no SOAP, no outbound HTTPS through PHP streams, FPM on a Unix socket, Linux only), a normal maintenance window this week is reasonable rather than an emergency change tonight; test the TLS behaviour change first if you call internal HTTPS services. If you run a public SOAP endpoint, do not wait.

Need PHP security releases applied across servers and containers without surprises? Cloudsoft Zone provides application maintenance and support for PHP and Laravel applications, including patching, verification and post-release monitoring.