CVE-2026-7261

What it actually does

CVE-2026-7261 is a use-after-free flaw in PHP's SOAP extension when SoapServer is configured with SOAP_PERSISTENCE_SESSION. In vulnerable PHP 8.2, 8.3, 8.4, and 8.5 releases, an error during SOAP request handling can cause the persisted handler object to be freed while a stale pointer to that object remains in session-backed persistence state. Subsequent access to that dangling pointer can corrupt process memory, crash the PHP worker, disclose memory contents, or potentially influence application behavior depending on allocator state, platform hardening, and the SOAP handler implementation.

Why it matters to the business

Organizations running PHP SOAP services with session-persistent SoapServer handlers may face unauthenticated remote service disruption and possible exposure or manipulation of application data. The issue has a critical CVSS score, is network-reachable, and requires no user interaction, but the currently low EPSS score and lack of known public exploit maturity indicate limited evidence of broad exploitation at this time. Because PHP is widely deployed and often embedded in business-critical web applications, affected internet-facing SOAP endpoints should still be prioritized for upgrade, especially where SOAP services process sensitive records, authentication workflows, payments, customer data, or administrative operations.

How an attack unfolds

An attacker first identifies a PHP-based SOAP endpoint backed by SoapServer using SOAP_PERSISTENCE_SESSION. They then send crafted SOAP requests that cause the server-side SOAP method invocation or parsing flow to enter an error path. In vulnerable PHP versions, that error path mishandles the session-persisted handler object: the object can be freed while a reference to it remains stored for future use. The attacker then sends additional requests using the same session context so the application attempts to reuse the stale handler pointer. At minimum, this can trigger PHP-FPM, Apache mod_php, or CLI server worker crashes, producing denial of service. Under favorable memory layout conditions, repeated requests and heap grooming may allow memory corruption effects that could leak process memory or alter execution state, although reliable remote code execution has not been established from the provided information.

How to fix it

Upgrade PHP to a fixed release for every deployed branch: PHP 8.2.31 or later, PHP 8.3.31 or later, PHP 8.4.21 or later, or PHP 8.5.6 or later. Restart PHP-FPM pools, Apache workers, containers, and application services after patching so all running workers use the corrected binary and extension. If immediate upgrade is not possible, reduce exposure by disabling or removing SOAP endpoints that use SoapServer with SOAP_PERSISTENCE_SESSION, changing the service to avoid SOAP_PERSISTENCE_SESSION where application-compatible, restricting SOAP endpoints to trusted networks, enforcing authentication and rate limits, and placing compensating controls at the reverse proxy or WAF for malformed or abusive SOAP traffic. Also ensure the PHP SOAP extension package is updated consistently across base images, system packages, containers, CI build images, and serverless/runtime layers.

How to confirm the fix worked

Confirm the active PHP runtime version is no longer in an affected range by checking php -v, php-fpm -v, package manager output, container image manifests, and runtime phpinfo() where safely available. Verify that ext/soap is either updated with the fixed PHP runtime or not enabled where unnecessary. Search application code and configuration for SoapServer usage with SOAP_PERSISTENCE_SESSION to identify exposed attack surface. Exercise representative SOAP requests, including error-producing requests, in a test environment and confirm PHP workers do not crash or log memory-management errors. Confirm all PHP-FPM, Apache, container, and process supervisors were restarted after upgrade; otherwise long-lived workers may still be running vulnerable code.

Typical attack path

1. Discover a PHP SOAP endpoint exposed over HTTP or HTTPS.
2. Determine or infer that the endpoint uses SoapServer with SOAP_PERSISTENCE_SESSION, often through application behavior, WSDL exposure, session cookies, or repeatable stateful SOAP interactions.
3. Send malformed or semantically invalid SOAP requests that trigger an error during SOAP request handling.
4. Maintain the same HTTP session so the vulnerable persisted handler state is reused across requests.
5. Send follow-up SOAP requests that cause PHP to access the freed handler object through the stale pointer.
6. Observe crashes, abnormal SOAP faults, connection resets, or memory-disclosure behavior and iterate requests to improve reliability or impact.

How to detect it

To assess prior exploitation, correlate web server access logs, reverse proxy logs, WAF events, PHP application logs, PHP-FPM logs, Apache error logs, system journals, kernel logs, and crash/core-dump artifacts. Focus on SOAP endpoint POST traffic that repeatedly triggers SOAP faults, HTTP 500 responses, upstream connection resets, or PHP worker crashes from the same client IP, user agent, session cookie, or short time window. Look for malformed SOAP envelopes, unexpected method names, oversized or unusual XML bodies, repeated invalid XML, and request sequences where an error-producing SOAP request is followed by additional requests using the same session identifier. On Linux hosts, review syslog, journald, dmesg, audit logs, and crash directories for php-fpm, php-cgi, httpd, apache2, or container worker segmentation faults, allocator corruption, invalid free, or core dumps. In containerized deployments, inspect orchestrator events for crash loops or restarts aligned with SOAP traffic. Because no specific public exploit signature is established, detection should emphasize behavioral correlation: stateful SOAP errors plus PHP memory-management crashes or abnormal worker restarts.

• SOAP_PERSISTENCE_SESSION
• new SoapServer
• setPersistence(SOAP_PERSISTENCE_SESSION)
• SoapServer::setPersistence
• Segmentation fault
• signal 11
• SIGSEGV
• zend_mm_heap corrupted
• double free or corruption
• free(): invalid pointer
• malloc(): memory corruption
• php-fpm: pool
• child exited on signal 11
• server reached pm.max_children
• AH01067: Failed to read FastCGI header
• upstream prematurely closed connection
• recv() failed (104: Connection reset by peer) while reading response header from upstream
• SOAP-ENV:Fault
• <soap:Envelope
• <SOAP-ENV:Envelope
• Content-Type: text/xml
• Content-Type: application/soap+xml

What your security team should do

• Inventory all PHP applications that expose SOAP endpoints and identify any use of SoapServer with SOAP_PERSISTENCE_SESSION.
• Prioritize internet-facing, partner-facing, and unauthenticated SOAP services for upgrade to PHP 8.2.31, 8.3.31, 8.4.21, 8.5.6, or later as applicable.
• Patch base images and shared PHP runtime packages, then rebuild and redeploy dependent applications rather than only updating source code repositories.
• Temporarily restrict SOAP endpoint access by IP allowlist, VPN, authentication gateway, or reverse proxy controls until patching is complete.
• Enable or tune monitoring for PHP worker crashes, segmentation faults, SOAP fault spikes, repeated malformed SOAP requests, and abnormal session reuse patterns.
• Review web access logs for repeated POST requests to SOAP endpoints from the same source or session followed by HTTP 500 responses, upstream resets, or PHP-FPM worker restarts.
• If crashes are observed, preserve PHP-FPM, web server, kernel, and application logs as well as core dumps where policy allows, because memory-corruption evidence may be volatile.