A critical use-after-free vulnerability (CVE-2026-6722) in PHP's built-in SOAP extension allows an attacker to execute arbitrary code on any server running PHP 8.2 through 8.5 with the SOAP extension enabled. The vulnerability lies in how PHP's SOAP implementation handles apache:Map deduplication — a flaw in memory management allows an attacker to write into freed memory regions by sending a specially crafted SOAP request. Remote code execution follows from there.
Active exploitation has not yet been confirmed, but the CVSS rating is CRITICAL and a patch is available. Update PHP to the latest security release for your branch immediately. If your application doesn't use SOAP, disable the extension to eliminate the attack surface entirely.
CVE Reference
- CVE-2026-6722 — Primary use-after-free RCE in the SOAP extension (PHP 8.2–8.5)
- CVE-2026-6735 — PHP-FPM status page exposure (related disclosure)
- CVE-2026-7259 — Additional PHP security fix in the same release cycle
- CVE-2026-6104 — Additional PHP security fix in the same release cycle
- CVSS: CRITICAL
- Active Exploitation: Not yet confirmed
What Is a Use-After-Free Vulnerability?
A use-after-free (UAF) vulnerability occurs when a program frees a block of memory and then continues to use a pointer that references that freed location. In a managed runtime like PHP, this should theoretically be handled by the memory manager — but lower-level C extensions like the SOAP module manage their own memory structures, and bugs in that management can create exploitable UAF conditions.
When an attacker can control the contents of freed memory before the vulnerable pointer dereferences it, they can supply a crafted value that redirects execution — effectively achieving arbitrary code execution on the server. In PHP's execution context, this typically means running code as the web server user (www-data, apache, or similar), with access to all files the web server can read and all network connections the server can make.
The Vulnerable Code Path: apache:Map Deduplication
The specific vulnerability is in PHP's handling of apache:Map type elements during SOAP request parsing. When PHP processes a SOAP message that includes apache:Map entries, it performs deduplication of certain internal structures. The deduplication routine frees a memory region but doesn't properly nullify or invalidate the internal reference to it. A subsequent operation in the same SOAP parsing flow then accesses that freed memory.
An attacker who can send a SOAP request to a PHP application can craft the apache:Map payload to trigger the UAF at a predictable memory location, control what gets written into the freed region, and redirect the PHP interpreter's execution to attacker-supplied code.
Which Applications Are Affected?
Any PHP application that:
- Runs PHP 8.2, 8.3, 8.4, or 8.5
- Has the SOAP extension loaded (check
php.iniforextension=soap) - Accepts SOAP requests from external clients — either directly via a SOAP endpoint, or indirectly by consuming SOAP-based third-party APIs that pass attacker-controlled data back to the PHP SOAP parser
Common SOAP use cases in production PHP applications include integrations with legacy enterprise systems (ERP, accounting software, insurance platforms), payment processors that still offer SOAP APIs, government/municipal service APIs, shipping carrier APIs (some UPS and FedEx endpoints remain SOAP-based), and healthcare or insurance data exchange platforms.
Remediation: Update PHP Immediately
PHP has released security updates for all affected branches. Update to the latest patch release for your branch:
# Check your current PHP version:
php -v
# Ubuntu/Debian — update PHP via apt:
apt update && apt upgrade php8.x php8.x-soap
# CentOS/RHEL/AlmaLinux:
yum update php php-soap
# Plesk servers — update via Plesk panel:
# Tools & Settings → Updates and Upgrades → PHP versions
After updating, confirm the version has changed:
php -v
On PHP-FPM deployments, restart the FPM service after updating:
systemctl restart php8.x-fpm
Disable the SOAP Extension If You Don't Use It
If your application doesn't use SOAP, the fastest mitigation is to simply disable the extension:
# Find your php.ini location:
php --ini
# In php.ini, comment out or remove:
;extension=soap
# Restart PHP-FPM or Apache:
systemctl restart php8.x-fpm
Verify SOAP is disabled:
php -m | grep soap
No output means SOAP is successfully disabled. This eliminates CVE-2026-6722's attack surface entirely until you can schedule a full PHP update.
PHP-FPM Status Page (CVE-2026-6735)
The same PHP release cycle also addressed CVE-2026-6735, which involves PHP-FPM's status page endpoint being accessible without authentication. If you use PHP-FPM and have the status page enabled, restrict it to internal/loopback access only in your NGINX or Apache config:
# NGINX — restrict FPM status page:
location ~ ^/(status|ping)$ {
access_log off;
allow 127.0.0.1;
deny all;
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.x-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
Quick Checklist
- Check PHP version:
php -v - Check if SOAP is loaded:
php -m | grep soap - If SOAP is loaded and you don't use it: disable it now
- Update PHP to the latest security release for your 8.x branch
- Restart PHP-FPM after updating
- Restrict PHP-FPM status page to loopback only
- Confirm update via
php -vafter patching