CVE-2026-12184: PHP-FPM DoS Patch Guide (8.3.32 / 8.4.21 / 8.5.6)

Two PHP security advisories published on July 2, 2026 fix a high-severity denial-of-service flaw and a moderate-severity memory corruption bug. CVE-2026-12184 crashes an entire PHP-FPM worker pool when an outbound HTTPS connection from your own PHP code fails TLS validation, and it needs no crafted exploit code to trigger. CVE-2026-14355 corrupts the Zend memory manager heap when application code encrypts data with an AES-WRAP-PAD cipher, because PHP sizes the output buffer without accounting for RFC 5649 padding. Neither advisory reports confirmed exploitation in the wild, so this is a patch-now advisory rather than an active 0-day, but the trigger condition for CVE-2026-12184 is common enough in ordinary production traffic that delaying the update carries real risk.

What CVE-2026-12184 actually breaks

PHP's HTTP stream wrapper opens outbound HTTPS connections whenever your code calls file_get_contents(), fopen(), or stream_context_create() against an https:// URL, along with any HTTP client library built on PHP streams. Internally, the function php_stream_url_wrap_http_ex calls php_stream_xport_crypto_setup and php_stream_xport_crypto_enable to negotiate TLS with the remote server.

When that negotiation fails, for example because the remote server presents an expired certificate or a certificate for the wrong hostname, PHP closes the underlying stream and resets it to NULL. The peer name cleanup code that runs immediately after does not check for that condition. It unconditionally tries to reset the peer name on a stream that no longer exists.

CVE-2026-12184 crashes PHP-FPM when an outbound HTTPS request made by your own code fails TLS validation. It does not require an attacker to send PHP a malicious request at all.

Why this is remotely triggerable without custom exploit code

The PHP security team notes that this was demonstrated as triggerable without specially crafted code, using nothing more than a remote server that fails the TLS handshake in the expected way. Any endpoint your application calls over HTTPS is a potential trigger the moment its certificate expires, gets misconfigured, or is swapped for one that does not match the hostname you are connecting to. Since the affected code path closes the entire stream and the cleanup routine then dereferences it, the crash takes down the PHP-FPM worker process and, per the advisory, the whole pool along with it, not just the single request that failed.

This is scored CVSS v4 8.2 (High), with an attack vector of network, no privileges required, and no user interaction required. The impact is availability only. There is no confidentiality or integrity loss described in the advisory.

The other bug: CVE-2026-14355 in the OpenSSL extension

CVE-2026-14355 lives in a much narrower code path: the AES key-wrap-with-padding cipher family (algorithm names ending in -wrap-pad, such as aes-256-wrap-pad) available through openssl_encrypt(). PHP allocates the output buffer for this operation based on the plaintext length alone. RFC 5649 key wrap with padding rounds the plaintext up to the next 8-byte boundary and prepends an 8-byte authentication value, so the real ciphertext length is roundup(len, 8) + 8, not a function of the raw plaintext length. The buffer PHP allocates is too small for what OpenSSL's EVP_EncryptUpdate and EVP_EncryptFinal actually write.

OpenSSL writes the full wrapped output past the end of that undersized allocation, corrupting adjacent Zend memory manager heap metadata. Here is the detail that matters for debugging: the corruption does not crash the process at the moment it happens. It surfaces later, as a zend_mm_heap corrupted abort, when the allocator inspects bookkeeping data that was already damaged by an earlier request. If you go looking for the cause at the point where the crash log shows it, you will be looking in the wrong request.

This one is scored CVSS v3.1 4.8 (Moderate), with high attack complexity, because an attacker needs your application to actually be using an AES-WRAP-PAD cipher, which most PHP code never touches directly. It shows up more often inside libraries handling CMS or PKCS7 message encryption, some JWE (JSON Web Encryption) implementations, and XML/SAML encryption stacks that use AES key wrap under the hood.

Affected versions and patched releases

PHP branch	CVE-2026-12184 affected	CVE-2026-12184 patched	CVE-2026-14355 affected	CVE-2026-14355 patched
8.2.x	Not listed as affected	n/a	< 8.2.32	8.2.32
8.3.x	< 8.3.32	8.3.32	< 8.3.32	8.3.32
8.4.x	< 8.4.21	8.4.21	< 8.4.23	8.4.23
8.5.x	< 8.5.6	8.5.6	< 8.5.8	8.5.8

Note that PHP 8.3.x needs the same 8.3.32 build to close both issues, but 8.4.x and 8.5.x need different point releases for each CVE. Confirm you are on the higher of the two patched versions for your branch, not just one of them.

Check whether your stack is exposed

Start with the installed version:

php -v

Compare the output against the table above for your branch. A version below both patched thresholds for your branch means you are exposed to both issues; below just one means you are exposed to that one.

If PHP-FPM has already been crashing, distinguish this specific failure mode from an ordinary out-of-memory kill. A CVE-2026-12184 crash shows the PHP-FPM master log reporting the worker exited on signal 11 (SIGSEGV), the process's own fault, correlated with an outbound HTTPS call. An OOM kill instead shows signal 9 (SIGKILL), issued by the kernel, not by PHP itself:

journalctl -u php8.3-fpm --since "24 hours ago" | grep -i "sig\|core dump"
grep -i "signal 11\|SIGSEGV" /var/log/php8.3-fpm.log 2>/dev/null

Repeated SIGSEGV entries timed near webhook deliveries, remote API calls, or scheduled feed fetches point at CVE-2026-12184. A SIGKILL pattern points at memory limits instead, which is a separate tuning problem.

For the OpenSSL bug, check whether your codebase calls a wrap-pad cipher at all, since the exposure only exists if it does:

grep -rniE "wrap-pad|WRAP_PAD" /var/www --include=*.php

No matches means CVE-2026-14355 is not a live risk in your own application code, though a third-party library or Composer dependency could still call it indirectly, so check vendor/ as well if the first pass comes back empty.

If a PHP-FPM crash shows up to visitors as a blank page or a gateway error rather than a clear PHP error, our NGINX 502 Bad Gateway guide walks through tracing that failure back to the php-fpm layer specifically.

Patch now: version-specific upgrade commands

On Debian or Ubuntu systems tracking the Ondřej Surý PPA:

apt update
apt list --upgradable | grep -i php
apt install --only-upgrade php8.3-fpm php8.3-common php8.3-opcache
php-fpm8.3 -t
systemctl reload php8.3-fpm

Run php-fpm8.3 -t before reloading. It validates the pool configuration without touching running workers, and a bad config caught here is a five-second fix instead of a downed pool. Use reload rather than restart where your version supports it: reload finishes in-flight requests on old workers while starting new ones with the patched binary, and restart drops connections immediately.

On RHEL-family systems tracking the Remi repository:

dnf update --enablerepo=remi-php84 php php-fpm php-openssl
php-fpm84 -t
systemctl restart php84-php-fpm

Verify the fix actually landed on the process serving traffic, not just the CLI binary, since these are separate packages on most distributions:

php -v
systemctl status php8.3-fpm --no-pager

Good output shows the patched build number from the table above and an active (running) status with no unexpected restarts in the log beyond the one you just triggered. If the patched package has not reached your distribution's repository yet, that is a real gap; watch the repository and prioritize the update the moment it lands rather than waiting for a routine maintenance cycle.

If you manage PHP versions through a control panel instead of a package manager directly, use the panel's own switcher. cPanel's MultiPHP Manager and DirectAdmin's PHP Selector both control which PHP-FPM handler version serves each domain, and pulling a patched build outside that mapping can leave a panel-managed server running a mismatched handler for some domains after a raw apt or dnf upgrade.

Is this actually a 0-day

A 0-day means attackers are exploiting a flaw before a patch exists. That is not this situation. PHP's security team published fixed releases in the same advisories that disclosed both bugs, so there was no unpatched exposure window for anyone who updates promptly. Neither advisory reports evidence of exploitation before the fix shipped.

What makes CVE-2026-12184 feel urgent is the trigger condition, not exploitation status. Any TLS failure on an outbound connection your PHP code initiates, including an ordinary expired certificate at a vendor you integrate with, can now take down your entire PHP-FPM pool. That is a low bar, and it does not require an attacker to compromise your infrastructure at all. They only need influence over, or the misfortune to run, a TLS endpoint your application happens to call.

Decision rule: patch immediately or schedule maintenance

Patch CVE-2026-12184 in the same window you read this if your application makes outbound HTTPS calls to endpoints you do not fully control: third-party webhooks, partner API syncs, remote feed or image fetches, payment gateway callbacks. A single vendor's expired certificate is now a full pool outage trigger, not just a failed request.

CVE-2026-14355 can generally wait for your next scheduled maintenance window if your grep for wrap-pad ciphers came back empty, since exploiting it requires your stack to actively choose that specific algorithm, which most PHP applications never do. Patch it in the same pass regardless, since the same point releases fix both bugs on the 8.3.x branch, and separately on 8.4.x and 8.5.x.

If you are running a self-hosted app on a VPS and want a broader look at php-fpm pool tuning issues unrelated to this specific CVE pair, see our walkthrough of fixing PHP-FPM, Redis locking, and reverse proxy mistakes on a Nextcloud VPS deployment.

When to bring in managed help

Patching PHP-FPM safely means testing the configuration before reload, watching the error log through the update, and confirming the fix landed on the process actually serving traffic. If you would rather have this monitored and applied by a hosting team instead of doing it during an on-call window, ServerSpan's Linux server administration service covers PHP version patching, php-fpm pool configuration, and log review as ongoing server management. Servers provisioned through ServerSpan VPS hosting come with full root access, so you can apply the commands above yourself the moment a patched package reaches your distribution's repository.

This is not the first default-enabled service or runtime issue to turn into a same-day patch advisory this year. See our breakdown of the CUPS RCE chain to root for another recent case where an overlooked default on a Linux VPS became a full compromise path.