CVE-2026-6722 PHP SOAP Use-After-Free in SOAP_GLOBAL(ref_map)

Vulnerability class and primitive

The PHP SOAP extension (ext-soap) maintains per-request global state, including SOAP_GLOBAL(ref_map) — a libxml2-node-keyed hash mapping XML node addresses to PHP object pointers. Its purpose is object deduplication: when a SOAP envelope references the same logical object more than once (via SOAP multiRef / href), the extension parses the object once and re-uses the PHP object for every subsequent reference. The bug is in how soap_add_xml_ref() and adjacent helpers populate the map — the PHP object pointer is stored without taking an additional reference (no Z_TRY_ADDREF_P / zend_objects_store_add_ref). When a SOAP envelope contains an apache:Map node carrying duplicate keys, the second insertion overwrites the first, and the overwrite path frees the original PHP object via zval_ptr_dtor while a stale pointer to it remains in the map. Subsequent href resolutions in the same envelope retrieve that freed memory address; the PHP allocator may have already filled the freed slot with attacker-controlled bytes coming from later parts of the SOAP body. The result is a CWE-416 use-after-free with attacker-controlled overwrite of the freed object's vtable / properties, leading to arbitrary code execution as the PHP worker — same process privilege as the PHP-FPM pool (PHP GHSA-85c2-q967-79q5; php.watch — PHP 8.5.6 release).

CVE-2026-7261 (UAF in SOAP_PERSISTENCE_SESSION header parsing — GHSA-m33r-qmcv-p97q) and CVE-2026-7262 (NULL dereference in Apache map NULL-check — GHSA-hmxp-6pc4-f3vv) are companion defects in the same extension fixed in the same point releases (both Moderate, CVSS 4.0 6.3). The companion bugs are lower-impact — CVE-2026-7261 needs a session-pinned SOAP server (less commonly deployed), CVE-2026-7262 reaches NULL deref rather than UAF — but they share the same memory-management bug class and the same patch set, suggesting the upstream review pass that produced GHSA-85c2-q967-79q5 covered the whole apache-map handling surface (PHP 8 ChangeLog).

Exploitation prerequisites and attack surface

A SoapServer reachable on a public HTTP endpoint, configured to accept arbitrary <SOAP-ENV:Envelope> bodies, is sufficient. No authentication is required — SOAP servers typically do not check session cookies because SOAP itself carries authentication in headers if needed, and many SOAP services are integration endpoints reachable by any client that knows the URL. The attacker only needs to POST a SOAP envelope to the endpoint URL. The PHP application's own code does not have to call SoapServer explicitly for the bug to trigger — any framework or library that mounts a SOAP endpoint (legacy WSDL-described integration handlers, the SoapClient/Server pair used for reverse-direction RPC, mod_php applications with SOAP exposed via the routing layer) is in scope.

Where SOAP commonly lingers in EU public-sector estates: legacy integration endpoints retained for backwards compatibility with partner systems long after the customer-facing UI has moved to REST; framework-internal SOAP receivers exposed unintentionally on public ingress paths because the routing default did not exclude them. The GHSA does not enumerate product impact — any PHP application built against the affected 8.x branches with ext-soap enabled and a SoapServer instantiated against attacker-reachable input is in scope.

MITRE ATT&CK mapping

• T1190 Exploit Public-Facing Application — initial access via SOAP POST to vulnerable PHP endpoint.
• T1059.004 Command and Scripting Interpreter: Unix Shell — post-exploitation shell as the PHP-FPM worker user (typically www-data / nginx / apache).
• T1505.003 Server Software Component: Web Shell — likely follow-on persistence path observed in prior PHP RCE incidents.

Detection concepts

• WAF rule class: alert on SOAP envelopes whose body contains an apache:Map element with duplicate key children, or whose href attribute count exceeds the number of distinct id attributes by more than the structurally expected amount. The published GHSA gives enough description to derive a structural detection rule without IOCs.
• PHP process crash monitoring: SIGSEGV / SIGABRT in php-fpm worker processes correlated with SOAP-handling URLs is a high-fidelity signal of attempted exploitation, since the UAF primitive is fragile under unfamiliar heap layouts and unsuccessful attempts typically segfault the worker rather than execute clean.
• Linux audit / EDR: hunt for unexpected child processes spawned from php-fpm, php, or apache2 parent-process trees — particularly shell binaries (/bin/sh, /bin/bash), interpreter binaries (perl, python3, node), and outbound TCP connections from the PHP worker UID to non-standard ports. Behavioural patterns are the same as historical PHP-deserialisation RCE incidents.
• Web access logs: POST requests with Content-Type: text/xml or application/soap+xml to endpoints not previously logged as SOAP receivers; unusually large SOAP bodies (UAF triggers often need significant heap manipulation); rapid sequential POSTs to the same endpoint with identical or near-identical bodies (heap-spray fingerprint).
• PHP error logs: increased Notice: Trying to access array offset on null or Fatal error: Uncaught Error: Call to a member function ... on null clustered around SOAP request handlers — failed exploitation attempts.

Hardening and mitigation

• Patch is the primary mitigation: upgrade to PHP 8.2.31, 8.3.31, 8.4.21 or 8.5.6 (all released 2026-05-07). Inventory PHP versions across web-facing infrastructure, including container base images that may have pinned older PHP minors.
• If patching is delayed: disable the SOAP extension where unused — phpdismod soap (Debian/Ubuntu), remove extension=soap from php.ini (RHEL family), or rebuild custom Docker images without the extension. Restart PHP-FPM after the change.
• Where SOAP must remain available: front the SoapServer endpoint with a WAF rule blocking duplicate-key apache:Map patterns and unusually deep XML nesting, restrict the endpoint to known consumer IP ranges via firewall, and require mutual-TLS for the SOAP endpoint where the integration partner supports it.
• Defence-in-depth: PHP-FPM workers should run with the minimum filesystem privileges needed; open_basedir restrictions; disable_functions should include exec, system, shell_exec, passthru, proc_open, popen; SELinux or AppArmor confinement of the PHP worker process limits the blast radius of any successful RCE.
• Audit your SoapServer instantiations: grep -rn 'new SoapServer' /var/www/ to enumerate every endpoint; document which are exposed publicly versus internally; remove or restrict the publicly-exposed ones unless business-justified.