Ondřej Surý's sury.org repository has repackaged four PHP security releases for Debian and Ubuntu users: 8.5.8, 8.4.26, 8.3.35, and 8.2.34. Three shipped on 24 September 2026, while 8.5.8 had already gone out on 2 July, so it has been sitting in the repos for a couple of months. All four are tagged as security releases, with many flaws facing the network and 8.4.26 carrying at least eleven assigned CVEs. Debian and Ubuntu admins can patch their systems through a standard apt upgrade.

Sury.org Ships PHP Security Updates for Four Active Branches

Debian and Ubuntu users can now patch a batch of security flaws across four active PHP release lines.

PHP rarely makes headlines. It runs quietly in the background of more than half the web. That invisibility is precisely why security matters here. When a flaw lets someone execute arbitrary code or leak credentials, the blast radius is enormous. So it's worth a moment's attention when four of PHP's most recent release lines get patched at once.

That's what Ondřej Surý just did. He's been packaging PHP for Debian since PHP 5, having earned his Debian Developer hat way back in 2000. His sury.org repository is the de facto source for PHP on Debian and Ubuntu, and its packages track upstream so closely that the distro's own repos are basically built on his work.

Through that channel, thousands of production systems receive PHP updates without anyone hand-rolling install scripts. The newest batch covers PHP 8.5.8, 8.4.26, 8.3.35 and 8.2.34. Three shipped on 24 September 2026. The 8.5.8 release had already gone out back on 2 July, so it's been sitting in the repos for a couple of months. All four are tagged as security releases by the PHP team, which means every one of them warrants treating as urgent.

What's in the patch

PHP keeps several release lines running simultaneously, each at a different point in its lifecycle. 8.5 is the newest, 8.4 is the current mainstream line, 8.3 has moved into maintenance mode, and 8.2 has reached security-only status. That last detail is the reason 8.2.34 ships at all: the branch no longer gets new features, but backported fixes keep the door shut on known holes.

The four tell three different stories. 8.5.8 is a security release that also bundles general bug fixes, which is standard for an active line. 8.4.26 is a big "full" release, the security patches plus a wide spread of other corrections across many extensions. Meanwhile 8.3.35 and 8.2.34 are pure security-only drops, carrying just the vulnerability fixes and nothing else.

The common thread is that a lot of these holes face the network. Several are out-of-bounds memory reads or buffer overflows that fire when PHP processes untrusted input. That's the classic recipe for remote code execution. A few strike server infrastructure directly, and the FPM IPv6 ACL bypass is worth a beat. It lets clients reach FastCGI services that were supposed to be locked down, which on a misconfigured box can be worse than the average internet-facing bug.

There's also the OpenSSL side. Both 8.5 and 8.4 took hits over TLS hostname verification. The wildcard certificate CN match can overflow the heap, and after a SAN mismatch PHP falls back to comparing the common name. Put together, those reopen man-in-the-middle territory in a way you probably don't want.

For 8.5.8 specifically, the headline is a memory corruption flaw in the OpenSSL extension. Calling openssl_encrypt() with the AES-WRAP-PAD padding scheme can corrupt the Zend memory manager, tracked as CVE-2026-14355. For what it's worth, that's an obscure padding scheme most PHP apps never call directly, mostly reserved for wrapping key material. But if your code does hit that path, the corruption is real and can either crash the process or do something far worse depending on how the code path gets exercised.

8.4.26 carries the most. By the PHP team's count it addresses at least eleven assigned CVEs. If you're keeping score, here's what showed up:

• FPM: IPv6 ACL bypass (CVE-2026-91768)
• MySQLnd: packet overreads in the wire protocol (CVE-2025-1218)
• OpenSSL: TLS hostname CN fallback (CVE-2026-91769) and a heap overflow in wildcard CN matching (CVE-2026-91767)
• Phar: integer overflow allowing TAR entry injection (CVE-2026-6103)
• SOAP: unbounded recursion (CVE-2026-91765) and a buffer overflow in HTTP parsing (CVE-2025-14181)
• Standard stream wrappers: out-of-bounds reads plus a cross-origin credential leak in redirects

Two fixes ride along without CVE numbers: a buffer overflow in hash_pbkdf2() triggered by a large output length, and an SNMP issue where setSecurity() frees a non-malloced address. 8.3.35 and 8.2.34 mirror the September vulnerability set without the extra bug fixes. That's the expected behavior for branches past their prime.

How to apply it

On sury.org it's a standard apt workflow. You need a source pointing at https://packages.sury.org/php/ and the official keyring imported, which per the project's own README.txt looks like this:

# As root (or with sudo)
apt-get update
apt-get -y install lsb-release ca-certificates curl
curl -sSLo /tmp/debsuryorg-archive-keyring.deb \
    https://packages.sury.org/debsuryorg-archive-keyring.deb
dpkg -i /tmp/debsuryorg-archive-keyring.deb
sh -c 'echo "deb [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg] \
    https://packages.sury.org/php/ $(lsb_release -sc) main" > \
    /etc/apt/sources.list.d/php.list'
apt-get update

Once that's in place, upgrading is a single command:

apt-get update
apt-get install --only-upgrade php            # or a specific SAPI, e.g. php-fpm, php-cli

For Ubuntu PPA users on ppa:ondrej/php, it's simpler still, since those repos already track upstream. A plain php -v after the upgrade confirms what you're actually running.

Here's the thing worth repeating: all four branches carry different sets of CVEs, but you should upgrade regardless. If you're still on 8.2 and haven't touched it in a while, this is your nudge.

For anyone running PHP on Debian or Ubuntu through sury.org, the takeaway is straightforward. The patched 8.5.8, 8.4.26, 8.3.35 and 8.2.34 packages are live right now. Given how many of these fixes face the network, upgrading isn't optional.