The PHP 8.4.26 security release, shipped on September 24, 2026 alongside 8.5.11, 8.3.35 and 8.2.34, fixes eleven advisories, and six of them share one trait: the attacker is not the visitor hitting your storefront. It is the server your PHP code calls out to. For a Magento stack that talks to payment gateways, carriers, ERPs and a database, that changes how you triage the patch. The question is not only which version you run. It is which HTTP client each integration uses, because PHP streams and ext/curl land on opposite sides of this release.
What the September 24 PHP releases fix
PHP 8.4.26 and 8.5.11 each fix the same eleven GitHub security advisories, and 8.3.35 and 8.2.34 went out the same day as security releases for the older lines, per the PHP news archive. The PHP 8 changelog lists them by extension: two in OpenSSL, two in SOAP, two in the standard HTTP stream wrapper, and one each in FPM, mysqlnd, Phar, the stream filters and Windows file handling. Most carry a moderate rating. Moderate is exactly the label that gets a patch pushed to next month, which is why the grouping below matters more than the individual scores.
Sort the eleven by who has to be malicious and a pattern appears. Six need a hostile or compromised remote server. Two are reachable from inbound traffic: an IPv6 bypass of the FastCGI listen.allowed_clients list in FPM, and unbounded recursion in the SOAP server. The last three need crafted local input, such as a TAR archive handed to Phar.
Outbound vs inbound: where the risk actually sits
The risk sits mostly in the outbound group: six advisories that assume the other end of an integration turns against you, a case most Magento teams have never threat modelled. Four of the six illustrate the shape well.
The first is a TLS hostname check that falls back to the certificate's Common Name after the subjectAltName list fails to match. The advisory for CVE-2026-91769 rates it 4.3 and notes that exploiting it realistically requires access to a private or internal certificate authority. The second, CVE-2026-91767, is a heap overflow in wildcard name matching, rated 6.5, that a crafted server certificate triggers with verify_peer_name at its default setting. The third is the one we would fix first. Per the advisory for CVE-2026-91766, rated 5.9, the HTTP stream wrapper forwarded Authorization, Cookie and Proxy-Authorization headers unchanged across a redirect to another host, another port, or from HTTPS down to HTTP. The fourth sits in SoapClient: an integer overflow while reading chunked responses, rated 6.5, which a hostile SOAP endpoint can turn into a heap overflow. Add an out-of-bounds read on a redirect with an empty Location header and packet overreads in mysqlnd, and the list is complete.
The credential leak deserves the extra attention because it needs no memory corruption at all. A bearer token set in a stream context, a redirect issued by a partner endpoint that has been compromised or simply misconfigured, and the token travels to a host you never chose to trust. No crash, no log line.
PHP streams vs ext/curl: which integrations are exposed
Integrations built on PHP's own stream layer are in scope, and integrations built on ext/curl are not, because curl hands TLS verification and redirects to libcurl. The advisories name file_get_contents(), fopen() and stream_socket_client() over HTTPS or TLS. SoapClient belongs on the same side, since ext/soap does its HTTP work through PHP streams rather than curl. Magento's own curl client and a Guzzle setup using its curl handler sit on the other side.
On the Magento and Hyvä storefronts we maintain, the stream-based clients cluster in predictable places. SOAP carrier and ERP connectors are the obvious ones. Older payment and tax modules often fetch tokens with file_get_contents() and a stream context carrying an Authorization header, which is the precise shape CVE-2026-91766 describes. Small in-house scripts that pull price files or feeds from a supplier over HTTPS are the ones nobody inventories. None of these show up when you grep a codebase for vulnerabilities. They show up when you grep for the functions.
The inbound pair needs a separate check. The FPM flaw only matters if your pools listen on a TCP socket with an IPv6 allow list. Most containerised stacks talk to FPM over a Unix socket or a private network, which removes that path. The SOAP server recursion matters to anyone still exposing a SOAP web API endpoint publicly.
What we would change this week
Patch first, because every supported line got a release. That means 8.4.26 or 8.5.11 for Magento 2.4.8 and 2.4.9, and 8.3.35 for older installs still on 8.3. It is a within-line update with no migration surface. We made the case for why PHP runtime patches belong in the weekly window, not the quarterly one, when 8.4.25 and 8.5.10 shipped in August. That post was about the support calendar. This one is about which of your integrations were ever exposed.
Then run a short audit across app/code and vendor. Search for file_get_contents( and fopen( calls with an http or https URL, for stream_context_create with a header option, and for new SoapClient. For each hit, answer three questions. Does it send a credential. Does it follow redirects, which is the stream wrapper default. And does the endpoint sit on infrastructure you control. Any hit that says yes, yes, no is a candidate to move onto a curl-based client, or at minimum to turn off follow_location in its context.
Finally, treat outbound integrations as part of your attack surface in the way the rest of the stack already is. An integration layer that routes partner calls through one client, with redirects and credentials handled in one place, turns a release like this one into a version bump instead of a code search. Stores that grew integration by integration are the ones where six outbound advisories mean an afternoon of grep.