PHP 8.4 DSA-6514-1: Patch Debian 13 PHP-FPM

pajus 2026-09-27 8 min read

On 2026-09-25 Debian published DSA-6514-1 for the php8.4 source package on Debian 13 (trixie). It fixes 10 CVEs. The advisory groups the impact as denial of service, information disclosure, incorrect validation of TLS certificates and bypass of access control restrictions. The advisory lists the CVEs and the fixed version, and nothing else. This post covers the rest: finding out whether your PHP 8.4 hosts are affected, patching them, and checking that the processes serving requests actually run the new code. That last part is where PHP-FPM and Apache mod_php hosts usually fall short.

Short version: every Debian 13 system with php8.4 packages older than 8.4.26-1~deb13u1 is affected. Upgrading the package is not enough on its own. You also have to restart php8.4-fpm or apache2.

What DSA-6514-1 fixes in PHP 8.4

Upstream PHP released 8.4.26 on 2026-09-24 and published GitHub security advisories (GHSA) for each issue the same day. Debian shipped the fix one day later. The upstream 8.4.26 changelog also lists CVE-2026-17545, but that bug only affects Windows, and it is not part of the DSA.

At the time of writing, NVD had not published its own scores for these CVEs. The CVSS 3.1 scores below come from the upstream PHP GHSA advisories, which makes them CNA scores.

CVE	Component	CVSS 3.1 (PHP GHSA)	Who should care
CVE-2026-91765	SOAP server, unbounded recursion in `cleanup_xml_node()`	7.5	Any app with a `SoapServer` endpoint. A single unauthenticated request can crash a worker.
CVE-2026-91768	PHP-FPM, IPv6 `listen.allowed_clients` only compares a /96 prefix	6.5	FPM pools listening on TCP over IPv6 that use `listen.allowed_clients` as their access control
CVE-2026-91767	OpenSSL streams, heap over-read on a crafted wildcard certificate	6.5	Code that makes outbound TLS connections through PHP streams
CVE-2025-14181	SOAP HTTP client, integer overflow leading to heap overflow	6.5	`SoapClient` talking to a malicious or compromised server
CVE-2026-91766	HTTP stream wrapper sends `Authorization`/`Cookie` headers across origins on redirect	5.9	Code that sends credentials with `file_get_contents()`/`fopen()` and follows redirects
CVE-2026-92842	`convert.*` stream filters, heap over-read	5.9	Only apps that pass attacker-controlled `line-break-chars`
CVE-2026-93682	HTTP wrapper, 1-byte over-read on empty `Location`	5.3	Low practical impact
CVE-2026-91769	OpenSSL streams fall back to CN after a SAN mismatch	4.3	Outbound TLS, mainly with private PKI
CVE-2026-6103	Phar, integer overflow in the TAR size field enables entry injection	4.0	Code that extracts untrusted TAR archives with `PharData`
CVE-2025-1218	mysqlnd packet over-reads	3.1	Only when connecting to an untrusted MySQL/MariaDB server

On a typical self-hosted LAMP/LEMP box running WordPress, Drupal or Nextcloud behind nginx or Apache, the two OpenSSL issues and the redirect credential leak matter most, because they affect any outbound HTTP call. CVE-2026-91768 only matters if your FPM listens on TCP over IPv6. SOAP is only relevant if you installed php8.4-soap and actually use it.

Who is affected: Debian 13 package status

According to the Debian security tracker at the time of writing:

Release	php8.4 version	Status
trixie (13)	8.4.24-1~deb13u1	vulnerable
trixie-security	8.4.26-1~deb13u1	fixed
forky (testing)	8.4.24-1	vulnerable, no fix yet
sid (unstable)	8.4.24-1	vulnerable, no fix yet

The fix covers every binary package built from the php8.4 source, including php8.4-fpm, libapache2-mod-php8.4, php8.4-cli and php8.4-common. php8.4-fpm requires php8.4-common at exactly the same version, so the packages are upgraded together. Debian 12 (bookworm) ships php8.2. The tracker still lists it as vulnerable to all 10 of these CVEs (8.2.32-1~deb12u1 in bookworm and 8.2.33-1~deb12u1 in bookworm-security). That is covered below under what to watch.

How to check your systems

List the installed PHP 8.4 packages and their versions:

dpkg -l 'php8.4*' 'libapache2-mod-php8.4' | grep '^ii'
apt-cache policy php8.4-common

Every line should show 8.4.26-1~deb13u1. If apt-cache policy does not offer that version, check that trixie-security is in your APT sources.

Next, work out which SAPI is serving web traffic and how FPM is exposed:

systemctl is-active php8.4-fpm apache2 nginx
grep -rE '^\s*listen(\.allowed_clients)?\s*=' /etc/php/8.4/fpm/pool.d/
dpkg -l php8.4-soap 2>/dev/null | grep '^ii'

The Debian default is listen = /run/php/php8.4-fpm.sock, and a Unix socket is not affected by CVE-2026-91768. The upstream advisory lists Unix sockets, IPv4-only setups and deployments where a firewall is the real boundary as unaffected. If a pool listens on [::]:9000 or a similar address and relies on listen.allowed_clients, move it to a socket or restrict it with nftables as well.

To find code that uses the affected stream TLS and redirect paths, search your web roots:

grep -rnE 'stream_socket_client|follow_location|ssl://|tls://' /var/www --include='*.php' | head -n 50

What the TLS bugs mean for outbound HTTPS

CVE-2026-91769 and CVE-2026-91767 are in PHP's OpenSSL stream layer (ext/openssl/xp_ssl.c). The advisories name file_get_contents(), fopen() and stream_socket_client() using the default verification settings.

CVE-2026-91769: if no subjectAltName entry matches, PHP falls back to the certificate's Common Name. RFC 6125 says the CN must be ignored once SAN entries are present. An attacker who holds a trusted certificate whose CN names your target host (with different SANs) can impersonate that host. Upstream expects this mostly in private PKI setups.
CVE-2026-91767: a malicious server presents a wildcard name longer than the requested hostname, and the resulting underflow makes memchr() read past the buffer. Upstream says the result is a crash and that heap content is not exposed to the attacker. The Debian tracker describes it more broadly. I follow the upstream advisory here.

Requests made through the curl extension use libcurl's own certificate checks, which these advisories do not describe. In practice this means webhook senders, feed fetchers, update checkers and "fetch this URL" features built on plain stream functions were checking certificates less strictly than you thought. Once you have patched, it is worth reviewing whether any of them sent tokens across a redirect (CVE-2026-91766).

How to patch and verify PHP 8.4 on Debian 13

Warning: the upgrade and the restarts below briefly interrupt PHP request handling, and in-flight requests may be dropped. Do this in a maintenance window, or one node at a time behind a load balancer.

apt update
apt list --upgradable 2>/dev/null | grep php8.4
apt upgrade

PHP-FPM (nginx or Apache with proxy_fcgi)

After the upgrade, the FPM master and its workers still run the old binary, which has now been deleted from disk. Restart the service and check /proc:

systemctl restart php8.4-fpm
systemctl is-active php8.4-fpm
for pid in $(pgrep php-fpm8.4); do printf '%s %s\n' "$pid" "$(readlink /proc/"$pid"/exe)"; done

Run the loop as root so it can read the www-data workers. Before the restart, a stale process looks like this (example):

1187 /usr/sbin/php-fpm8.4 (deleted)

After the restart, no line should end in (deleted). Running php-fpm8.4 -v only tells you about the binary on disk, not the processes that are running, so do not use it as proof that the fix is live.

Apache with mod_php

libapache2-mod-php8.4 is loaded into the Apache processes themselves and only works with the prefork MPM. Restart Apache itself. Restarting FPM does nothing here:

apache2ctl configtest
systemctl restart apache2
grep -sl 'libphp8.4.so (deleted)' /proc/[0-9]*/maps

The grep should print nothing. Any PID it does list is still mapping the old module.

Catch everything else that is stale

CLI workers, queue runners and cron daemons can also hold the old PHP. Use needrestart in list mode, or checkrestart from debian-goodies:

needrestart -r l
checkrestart

Long-running php processes such as Nextcloud background workers, Laravel queues and Symfony Messenger consumers must be restarted through their own systemd units or supervisor. If those units are not sandboxed yet, this is a good time to do it; see sandboxing systemd services on Debian 13 with systemd-analyze.

Drupal and other CMS checks

For Drupal, keep in mind that drush runs under the CLI binary, not FPM:

drush status --field=php-version
drush status --field=php-bin

This confirms that the CLI is at 8.4.26, which covers cron and deploy scripts. For the web SAPI, open Reports → Status report (/admin/reports/status) and check the PHP version reported there. It is served by FPM or mod_php, so it shows what the web side actually runs. Other CMSs such as WordPress (Site Health) and Nextcloud (admin overview) have similar pages. If you use a throwaway <?php echo PHP_VERSION; file instead, delete it right after checking.

Rollback note

If the update breaks an application, you can go back to 8.4.24-1~deb13u1, which is still in trixie main. Downgrade every installed php8.4-* package to that exact version in one apt install pkg=version ... command, because of the strict version dependencies, and then restart as described above. A rollback brings all 10 CVEs back. Treat it as a short stopgap, pin with apt-mark hold only while you fix the application, and remove the hold afterwards.

What to watch next

php8.2 on Debian 12: the tracker lists bookworm's php8.2 as vulnerable to all 10 of these CVEs, and upstream fixed them in 8.2.34. Watch for a separate DSA.
forky/sid are still on 8.4.24-1 without a fix. Testing boxes stay exposed until it migrates.
NVD scoring may differ from the GHSA scores once published.
Recheck FPM exposure and the general web stack using the checklist in web server security basics for self-hosters.

Takeaways

Target version on Debian 13: 8.4.26-1~deb13u1 for all php8.4-* packages.
FPM hosts: systemctl restart php8.4-fpm, then make sure no /proc/PID/exe ends in (deleted).
mod_php hosts: restart apache2 and grep /proc/*/maps for the deleted libphp8.4.so.
Run needrestart -r l for queue workers and daemons.
drush status shows the CLI. The Drupal Status report shows the web SAPI. Check both.
Outbound HTTPS through PHP streams had weaker certificate checks. Review code that sends tokens and follows redirects.
Move IPv6 TCP FPM pools to a Unix socket or put them behind a firewall.