PHP 8.4.22 and PHP 8.5.7 landed on June 4. Both wear a bug fix label on the release archive, but between them the changelogs ship ten CVE fixes, including a SOAP use-after-free, a cross-site scripting hole in the FPM status endpoint, and a DOM C14N regression that breaks signed XML. For studios maintaining Magento Hyvä or Adobe Commerce 2.4.9 storefronts in production, the PHP 8.4.22 rollout is this week's work, not next quarter's.
What changed
The 8.4 line, since it picks up the heavier backport list,
carries the longer CVE roll. CVE-2026-7261 fixes a use-after-free
after a header parsing failure under SOAP_PERSISTENCE_SESSION.
CVE-2026-7262 fixes a broken null check on Apache map values, and
CVE-2026-6722 fixes a stale ref_map pointer in the same module.
CVE-2026-6735 patches a cross-site scripting bug in the FPM
status endpoint. CVE-2026-7263 stops DOM\XMLDocument::C14N()
from emitting duplicate xmlns declarations after
setAttributeNS(), which silently broke
canonicalisation. CVE-2026-7259 and CVE-2026-6104 close mbstring
null pointer and out of bounds bugs. CVE-2026-7568 and
CVE-2026-7258 patch a signed integer overflow and a ctype.h
signedness mismatch in the standard library. CVE-2025-14179
closes a SQL injection via NUL bytes in PDO_Firebird. The full
list is on the
PHP
8.4.22 changelog.
On top of the security work, the release fixes a tracing JIT crash that hit when the VM interrupt fired during an observed user function call, a tailcall VM crash from the same area, a long-standing segfault tracked as GH-21746, and an integer overflow in date math. OpenSSL 4.0 builds compile cleanly again. Several of these have been on the issue tracker since the 8.4 line stabilised, and the JIT fixes alone are worth the upgrade for anyone running tracing JIT in production. PHP 8.5.7 picks up the same URI parser CVEs (CVE-2026-44927 and CVE-2026-44928) on top of a narrower bug list, per the PHP 8.5.7 changelog.
Why it matters for premium studios in Asia
Adobe Commerce 2.4.9 went GA in late May and dropped PHP 8.2 from the support matrix. PHP 8.4 and 8.5 are the only supported runtimes. Most studios that started a 2.4.9 migration in May are now running 8.4 in staging and either 8.4 or 8.3 in production. PHP 8.4.22 is the first patch release after the GA hit. It is also the release that includes the SOAP and FPM fixes most Magento operators actually need.
The SOAP fixes are the operationally interesting ones for Hyvä and Adobe Commerce work. Magento's first-generation web API is still SOAP. It is not the path the storefront uses anymore, but it is exactly the path that long-running ERP, PIM and 3PL integrations push through. We see it on every B2B project we audit. On large multi-brand Adobe Commerce platforms the back-office surface stays SOAP-shaped for the systems that have always spoken SOAP. CVE-2026-7261 turns a session-persisted SOAP integration into a use-after-free under specific header parsing failures. If your warehouse system or your accounting bridge calls Magento through SOAP with session persistence, this CVE was always reachable from a misformed upstream response.
CVE-2026-6735, the FPM status XSS, is the other one to track. The status endpoint is supposed to be locked behind an internal subnet or a vhost on a non-public port. In production we still see it exposed through a reverse proxy on the same public host as the storefront, because someone added it to a dashboard during the last incident and forgot to remove it. An XSS in the status output is a small footprint but a real one when the endpoint is publicly reachable.
The DOM C14N regression matters narrowly but seriously. CVE-2026-7263 is the kind of bug that signs documents correctly nine times and breaks the tenth. Anyone running SAML single sign on or signed XML payloads for partner integrations should treat that as a "patch before the next audit" item, not a routine update.
What we would actually change this quarter
Cut a Magento patch window for PHP 8.4.22 inside the next two weeks. The release is a SEMVER patch, not a minor, and the change set is small enough to stage and ship behind contract tests on every site you operate. Treat it the way you treat a Magento security-only patch: a fast lane, but still a lane, with a real changelog read and real staging time.
Audit FPM exposure. The check is short. Confirm that
/status, /ping and any FPM-specific
endpoint return 403 or 404 from a non-internal IP. If they are
reachable, fix the proxy rules first and patch second. The
reverse proxy is the real boundary, the PHP patch is the
depth-in-defence.
Inventory your SOAP integrations on Magento. Anything still on the legacy v1 SOAP API with session persistence should move to REST or GraphQL when the rewrite fits the roadmap. If the rewrite is not in this quarter's budget, the 8.4.22 patch is your interim mitigation, and your monitoring should already alert on SOAP error rates. For ERP and PIM integration workloads, bundle the PHP bump into the same release window as your scheduled cron and queue worker upgrades. The JIT and date fixes are quietly worth the rollout there too.
Re-run any signed-XML test suites you have. SSO, OFX, signed catalogues, partner feeds. The C14N fix changes how canonicalisation rounds in edge cases, and that is the kind of change you want to verify against your own corpus, not trust on the changelog. We caught one C14N edge case on a B2B SSO setup last year that did not surface until the third production release, and the lesson stuck.