PHP SOAP Extension RCE (CVE-2026-6722): CVSS 9.8, Patch Now

The PHP Security Group shipped patches across all active PHP 8 branches in May. This week, NIST finalized the NVD scoring at 9.8 Critical for CVE-2026-6722, and coverage is picking up accordingly. If your server runs PHP with the SOAP extension loaded — common on cPanel and DirectAdmin hosts — you are exposed to unauthenticated remote code execution until you patch.

What the Bug Actually Does

The vulnerability lives in ext-soap, the module PHP uses to handle SOAP (Simple Object Access Protocol) messaging — an XML-based RPC protocol still widely used in payment gateways, ERP integrations, government service APIs, and some legacy CMS setups.

The flaw is a textbook use-after-free (CWE-416). PHP's SOAP extension deduplicates objects as it parses incoming SOAP XML, storing pointers to PHP objects in a global hash map. The problem: it never increments reference counts on those stored objects. When an apache:Map node arrives containing duplicate keys, the parser overwrites the first entry in its temporary result map and frees the original PHP object — but the stale pointer remains live in the global map. An attacker who controls the SOAP request body can then allocate a string into that freed memory slot, trigger type confusion, and redirect execution.

The end result: arbitrary code execution running as the web server process user — typically www-data, nobody, or a per-account user on shared cPanel hosting.

NIST scored this at CVSS 9.8 Critical under the v3.1 framework: network-accessible, low complexity, no privileges required, no user interaction needed. The PHP Group's own CVSS 4.0 assessment came in at 9.5 Critical. Either way, the number is telling you to move fast.

Two More Bugs Patched in the Same Release

CVE-2026-6722 shares its patch window with a cluster of smaller issues. Two worth noting:

• CVE-2026-7261 (CVSS 6.3) — A separate use-after-free in SoapServer, triggered during header parsing when the server is configured with SOAP_PERSISTENCE_SESSION. Lower severity, but the same memory-management family of defect.
• CVE-2026-6104 — A buffer over-read in mb_convert_encoding, patched simultaneously. Not SOAP-related, but a reason to update regardless of whether your stack uses SOAP at all.

Who Is Actually Exposed

The SOAP extension needs to be loaded for CVE-2026-6722 to be reachable. On a minimal PHP install, it often isn't. On shared hosting, the picture flips: cPanel and DirectAdmin enable ext-soap by default because CMS platforms and e-commerce stacks commonly depend on it. Most site owners have no idea it's loaded.

Realistic attack surfaces include:

• WooCommerce stores integrated with payment processors that expose SOAP endpoints — older PayPal SOAP gateway and Authorize.Net SOAP integrations among them
• WordPress multisite installations pulling data from SOAP-based third-party services or APIs
• Enterprise or government-adjacent sites connected to SAP, Oracle, or legacy ERP systems via SOAP
• Any custom PHP application that accepts SOAP requests from external clients on a public-facing endpoint

If your PHP application has a SOAP endpoint reachable from the internet and it's running an unpatched version, this is a low-friction path to shell access. On shared hosting, a compromised account can sometimes be a stepping stone to neighboring accounts depending on how isolation is configured.

What You Need to Do

1. Confirm your PHP version. Run php -v at the command line, or check your hosting control panel. Affected branches:

• PHP 8.2.x — update to 8.2.31
• PHP 8.3.x — update to 8.3.31
• PHP 8.4.x — update to 8.4.21
• PHP 8.5.x — update to 8.5.6

PHP 8.0 and 8.1 are end-of-life and receive no security patches. If you're still on either branch, CVE-2026-6722 is not your only problem — migrating to a supported release is the priority.

2. Patch immediately. Managed hosting providers should have already pushed these releases; verify rather than assume. Check the exact version string, not just the major branch.

3. Audit and disable SOAP if you don't use it. In php.ini, comment out extension=soap. On cPanel with MultiPHP, you can toggle extensions per PHP version in the INI Editor. If none of your applications make or accept SOAP calls, there is no reason to carry the extension. Shrinking your loaded extensions reduces your exposure to every future vulnerability in those modules, not just this one.

4. Restrict SOAP endpoints at the network layer. If SOAP is only called by known partners or internal services, use firewall rules or web server access controls to whitelist those IP ranges and block all other inbound requests to the endpoint path.

5. Consider WAF rules as a temporary bridge. ModSecurity with the OWASP Core Rule Set, or Cloudflare's managed ruleset, can be configured to reject SOAP requests carrying duplicate apache:Map keys — the specific trigger for this bug. That's a mitigating control, not a substitute for patching, but it buys time while updates roll out.

6. Confirm with your host. On managed shared hosting, explicitly ask your provider to confirm the PHP version has been updated to the patched release. Don't rely on a dashboard display — ask for the specific version string.

Why This One Deserves Urgency

A CVSS 9.8 unauthenticated RCE is always worth moving fast on. A few factors make this one worth extra attention. SOAP's default-enabled status on the two most common shared hosting control panels means the exposure is broad and largely invisible to the people running the sites. Proof-of-concept research is already circulating. The EPSS score — the probability-of-exploitation metric — sits at 0.30% as of this writing, which sounds small until you consider the sheer volume of unpatched PHP servers and the fact that a working memory exploit is already documented publicly.

At Falcon Internet, we've watched this pattern before: a protocol enabled by default, invisible to most application owners, becoming the soft underbelly when a memory bug lands. Patch to 8.2.31/8.3.31/8.4.21/8.5.6, audit your php.ini, and if SOAP isn't serving your application, it shouldn't be serving an attacker either.