CVE-2026-6722: PHP's SOAP RCE Has a Working Exploit — Patch Today

If your server runs PHP — and statistically it does — you have a critical patch to apply right now. CVE-2026-6722, a use-after-free vulnerability buried in PHP's SOAP extension, earned a CVSS 9.8 from NIST and a 9.5 from the PHP Group itself. A working proof-of-concept exploit by researcher Brett Gervasoni began circulating within days of the patch release, and automated scanning for exposed SOAP endpoints spiked within 72 hours of disclosure. The practical patching window is effectively zero.

What the Bug Actually Is

The vulnerability lives in soap_add_xml_ref() inside ext/soap/php_encoding.c. PHP's SOAP extension maintains a global reference map — SOAP_GLOBAL(ref_map) — that stores pointers to PHP objects for deduplication during request processing. The problem: it stores those pointers without incrementing the objects' reference counts.

When the extension encounters duplicate keys inside an apache:Map node in a SOAP request, it frees the first object while leaving a live dangling pointer in the map. An attacker who controls the SOAP request body can then craft a follow-up allocation to place attacker-controlled data into that freed memory region, and dereference the dangling pointer to achieve remote code execution on the server — running as whatever user the PHP process runs under. The CWE classifications are CWE-416 (Use After Free) and CWE-825 (Expired Pointer Dereference).

Gervasoni's PoC uses a SOAP XML envelope with duplicate-key Apache map structures to trigger the condition reliably. This isn't a theoretical edge case — it's a reproducible attack against any reachable PHP application that loads the SOAP extension and processes external requests.

Who Is Exposed — and Why Shared Hosting Is Especially at Risk

The affected range spans all currently supported PHP branches:

• PHP 8.2.x before 8.2.31
• PHP 8.3.x before 8.3.31
• PHP 8.4.x before 8.4.21
• PHP 8.5.x before 8.5.6

On shared hosting platforms running cPanel or DirectAdmin, the SOAP extension is enabled by default in most PHP builds. You don't need to have written a SOAP API yourself to be vulnerable — any plugin, theme, or library that loads the extension is sufficient. WordPress multisite networks, WooCommerce stores that integrate with external payment gateways via SOAP, and applications that parse third-party SOAP feeds are realistic attack surfaces. The extension just has to be loaded.

This batch of patches also closes two closely related SOAP flaws patched simultaneously: CVE-2026-7261 (a use-after-free in SoapServer when session persistence encounters a header-parsing error, CVSS 6.3) and CVE-2026-7262 (broken NULL check in Apache map value handling, CVSS 6.3). And if you use openssl_encrypt() with the AES-WRAP-PAD cipher mode, there's also CVE-2026-14355 in the same release cycle — a heap memory corruption that could lead to process corruption or RCE depending on context.

The Real Problem: The Patching Window Has Already Collapsed

Security teams often talk about the race between disclosure and exploitation as if it plays out over weeks. For CVE-2026-6722, it played out in days. Exploit code appeared publicly almost immediately after the patch was released, giving defenders almost no time to patch before attackers began probing. Scanning data shows automated tools hitting SOAP endpoints at elevated rates within 72 hours of disclosure.

This matters because a lot of PHP deployments — on shared hosting, VPS, and managed servers alike — don't update automatically. PHP version upgrades often require a manual step through a control panel, a support ticket, or a deployment pipeline. That delay is exactly what attackers are counting on.

What to Do Right Now

The only complete fix is upgrading PHP. There is no configuration-only workaround for CVE-2026-6722 if your application uses SOAP. Here's the priority order:

• Check your version immediately. Run php -v on the command line, or find your PHP version in cPanel under MultiPHP Manager, Plesk's PHP Settings, or DirectAdmin's PHP Version Manager. If you're below the patched versions listed above, you're exposed.
• Upgrade to a patched branch. All four active branches (8.2.31, 8.3.31, 8.4.21, 8.5.6) received simultaneous patches. If your host gives you a choice, 8.3 or 8.4 are the sensible picks for most applications today — 8.2 reaches end-of-life in December 2026.
• Check whether SOAP is even loaded. If you can't upgrade immediately for some reason, run php -m | grep -i soap on the CLI, or add <?php print_r(get_loaded_extensions()); ?> to a temporary PHP file. If SOAP does not appear, you're not exposed via this vector. If it does, weigh whether any application actually requires it — the directive extension=soap in php.ini can be commented out to disable it if nothing needs it.
• Check WAF rules. If you have a WAF in front of your application (ModSecurity, Cloudflare WAF, Imunify360), verify that rules targeting SOAP payload anomalies are enabled. This buys time but is not a substitute for patching.
• Review logs. Look for unusual POST traffic targeting .php endpoints with a Content-Type: text/xml or application/soap+xml header — that's the fingerprint of SOAP requests. Elevated traffic with malformed payloads may indicate active scanning.

The Bigger Pattern

What's striking about CVE-2026-6722 isn't just the severity — it's the location. The SOAP extension is old, widely deployed, and rarely the thing developers think about when reviewing attack surface. It ships enabled on most control-panel-managed hosts, it's used indirectly through libraries, and it has a history of memory management issues that have gone unaudited for years. This is exactly the kind of component attackers have learned to look at when higher-profile libraries get hardened.

Managed server environments with consistent PHP patch cycles generally reached patched versions within hours of release. The businesses that will hurt are the ones running unmanaged PHP on hosting they haven't looked at in six months — and with automated exploit kits already scanning, that window is closing fast.