PHP DoS Flaws (CVE-2026-12184 & CVE-2026-14355)

On 6–7 July 2026 the PHP project published security releases across every currently-supported PHP line: PHP 8.2.32, 8.3.32, 8.4.23 and 8.5.8. Together they fix two flaws — CVE-2026-12184, a denial-of-service bug in PHP's HTTP stream wrapper, and CVE-2026-14355, a memory-corruption bug in PHP's OpenSSL extension. All PHP users on affected lines are advised to upgrade.

It has been a busy fortnight for infrastructure patching — the same two weeks also saw three Linux kernel root flaws patched, including GhostLock (CVE-2026-43499), which we've covered separately. This article is about the PHP layer, because the PHP flaws are the ones with a direct, specific consequence for Magento stores: an unpatched PHP build can be crashed from outside, and a crashed PHP means a store that isn't taking orders.

Neither flaw is remote code execution. Nobody steals your customer database with these bugs. But for an ecommerce business, "denial of service" is not an abstract severity label — a checkout that is down is revenue that is gone, and CVE-2026-12184 makes taking a checkout down remarkably cheap.

The bug lives in PHP's HTTP stream wrapper — the machinery PHP uses whenever code opens an HTTPS URL as a stream. When PHP makes an outbound HTTPS connection and the TLS setup fails — the remote server presents an expired certificate, say, or a hostname mismatch — the internal stream object is closed and reset. So far, so normal. The flaw is that a cleanup routine still runs afterwards, assuming the stream is valid. It performs unsafe operations on what is now a null reference, and the PHP process crashes.

Read that chain of events from the attacker's side and the problem becomes obvious: a remote server can crash the PHP that connects to it just by presenting a broken TLS configuration. There is no payload to craft, no authentication to bypass, and the crash is trivially repeatable — every new connection to the misconfigured endpoint is another crash.

The PHP-FPM angle is what turns a crash into an outage. Almost every production Magento store runs PHP under PHP-FPM, which manages a pool of worker processes. A single worker crashing is survivable — FPM respawns it. But a crash that can be triggered on demand, repeatedly, can take down worker after worker faster than the pool recovers. Under sustained triggering, the PHP-FPM crash cascade takes down the whole worker pool, and the result is a full site outage: no product pages, no basket, no checkout.

The second flaw fixed in the same release cycle is CVE-2026-14355, a memory-corruption bug in PHP's OpenSSL extension linked to the AES-WRAP-PAD encryption algorithm. The root cause is incorrect buffer size calculations during encryption operations, which can corrupt memory.

AES-WRAP-PAD is not widely used, so most Magento stores are unlikely to hit this code path in day-to-day operation — but it is present in some implementations, and memory corruption in a cryptographic code path is exactly the category of bug you patch on principle rather than waiting to find out whether your particular extension stack exercises it. It ships in the same fixed releases as CVE-2026-12184, so patching one patches both.

CVE-2026-12184 only bites when your PHP makes outbound HTTPS connections. A static brochure site barely makes any. A Magento store makes them constantly:

• →Payment gateways — every order confirmation, capture and refund is an outbound HTTPS call
• →Shipping rate APIs — live rate lookups fire on basket and checkout pages
• →Marketplace and feed integrations — product feeds, stock syncs and order pulls run all day
• →Cron jobs — Magento's cron fires scheduled tasks that call external endpoints on a timer
• →Extension license checks — many third-party modules phone home to validate their licenses

Any of those endpoints failing TLS the wrong way — or anything an attacker can point your store at, such as a URL they control being fed into an integration — can crash the PHP that made the connection. The larger your extension footprint, the larger your outbound HTTPS surface, and the more opportunities exist for a misconfigured or malicious endpoint to trigger the bug.

And the exposure is universal across the platform: Magento 2.4.x runs on exactly the PHP lines that received these fixes. There is no supported Magento version sitting safely on an unaffected PHP line.

The fixed releases, mapped against the Magento versions that run on each PHP line:

One note for older stores: Magento 2.4.6 also supports PHP 8.1, which is past the end of its security support life and did not receive a July 2026 release. If you are still on PHP 8.1, the fix for these CVEs is to move to PHP 8.2.32 — and that is worth doing regardless of these two bugs. Our Magento 2 prerequisites page lists the supported PHP versions for every Magento release if you need to check where your store sits.

If you have SSH access, run:

php -v

Compare the reported version against the fixed release for your line:

• PHP 8.2: you need 8.2.32 or later
• PHP 8.3: you need 8.3.32 or later
• PHP 8.4: you need 8.4.23 or later
• PHP 8.5: you need 8.5.8 or later

No SSH? Most hosting control panels show the active PHP version in their PHP settings screen. If you are on unmanaged hosting or a shared server where you control the PHP version yourself, update now — this is not a patch to schedule for next month's maintenance window. If you are on managed hosting, the question is simpler: ask your provider which PHP build is actually deployed on your server.

PHP security patching is part of standard managed Magento 2 hosting at EveryHost — customers on EveryHost-managed stacks receive PHP security updates as standard, and the July 2026 releases are being deployed through our normal patch process. We are not going to claim these bugs could never have affected an EveryHost server before the patches existed — no host can honestly claim that. What we commit to is the process: security releases get applied, and if you ask us which PHP build your store is running, you get a straight answer.

One thing worth being clear about: our Sentinel WAF does not stop CVE-2026-12184, and neither does anyone else's. A WAF filters inbound traffic; this bug is triggered by outbound connections your own PHP makes. Outbound connections are simply not WAF territory. The honest mitigations are patching PHP and keeping your outbound HTTPS surface tidy — knowing which extensions and integrations phone out, and removing the ones you don't need.

If you're weighing up whether your current provider treats PHP patching as their job or yours, our UK Magento hosting pages set out exactly what is and isn't included in an EveryHost plan.