CVE-2025-6491

Overview

PHP is a general-purpose scripting language used mostly for web development. It runs behind web servers through server APIs such as Apache mod_php and PHP-FPM, and powers content management systems and frameworks such as WordPress, Drupal, Moodle and Laravel. Its SOAP extension implements SOAP clients and servers, building and parsing SOAP messages with the libxml2 library.

A Denial of Service (DoS) vulnerability (CVE-2025-6491) has been identified in the message serialization of PHP's SOAP extension, which allows an attacker who can make an application build a SOAP node name of more than 2 GiB, for example through a namespace prefix taken from a remote SOAP service, to crash the PHP process with a NULL pointer dereference. PHP tracks this issue as GHSA-453j-q27h-5p8x.

Per MITRE CWE-476: The product dereferences a pointer that it expects to be valid but is NULL.

This issue affects all versions of PHP before 8.1.33, PHP 8.2 before 8.2.29, PHP 8.3 before 8.3.23 and PHP 8.4 before 8.4.10, including the End-of-Life release lines PHP 5.6, 7.0, 7.1, 7.2, 7.3, 7.4 and 8.0 through their final releases.

Details

Module Info

• Product: PHP
• Affected packages: php-src (ext/soap)
• Affected versions: <8.1.33, >=8.2.0 <8.2.29, >=8.3.0 <8.3.23, >=8.4.0 <8.4.10
• GitHub repository: https://github.com/php/php-src
• Published packages: https://www.php.net/downloads
• Package manager: N/A
• Fixed in:
  • OSS PHP 8.1.33, 8.2.29, 8.3.23, 8.4.10
  • NES for PHP 5.6.1 (based on PHP 5.6.40)
  • NES for PHP 7.2.1 (based on PHP 7.2.34)
  • NES for PHP 7.4.1 (based on PHP 7.4.33)

Vulnerability Info

This Medium-severity vulnerability is found in the SOAP extension of PHP before 8.1.33, 8.2 before 8.2.29, 8.3 before 8.3.23 and 8.4 before 8.4.10. The CVE record does not list the End-of-Life PHP 5.6, 7.0, 7.1, 7.2, 7.3, 7.4 and 8.0 release lines, but they carry the same code and never received the upstream fix. The PHP project scores it 5.9 under CVSS 3.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H).

When the SOAP extension serializes a parameter, it creates an XML node and then names it with libxml2's xmlNodeSetName(). The upstream fix explains that libxml2 versions before 2.13 cannot handle a name longer than 2 GiB: the call leaves the node with a NULL name instead of failing. The serializer then compares that name without checking it. In PHP 7.4.33 the code reads:

xmlParam = master_to_xml(enc, val, style, parent);
zval_ptr_dtor(&defval);
if (!strcmp((char*)xmlParam->name, "BOGUS")) {
    xmlNodeSetName(xmlParam, BAD_CAST(paramName));
}
return xmlParam;

With a NULL name, strcmp() dereferences a NULL pointer and the process crashes. According to the fix, this can be triggered when a SoapVar is created with a fully qualified name longer than 2 GiB, which is possible if application code takes a namespace prefix from an untrusted source such as a remote SOAP service. HeroDevs' analysis found that on PHP 5.6 a SoapVar name of 2 GiB, the largest string PHP 5 allows, is enough.

Exploitation needs a 64-bit build with the SOAP extension and libxml2 older than 2.13, and an application that builds a SoapVar name of that size from data an attacker controls, with a memory_limit large enough to hold it. This applies to any SAPI; the impact is a crash of the PHP process, not code execution. Systems with libxml2 2.13 or later, and applications that do not build SOAP names from untrusted input, are not exposed.

The fix checks for a missing name and gives the node the parameter name instead:

if (xmlParam != NULL) {
    if (xmlParam->name == NULL || strcmp((char*)xmlParam->name, "BOGUS") == 0) {
        xmlNodeSetName(xmlParam, BAD_CAST(paramName));
    }
}

Mitigation

The PHP project publishes security fixes only for its supported release lines. PHP 5.6, 7.0, 7.1, 7.2, 7.3, 7.4 and 8.0 are End-of-Life and will not receive any public updates to address this issue.

Until an upgrade is possible, updating libxml2 to version 2.13 or later removes the condition that leaves the node name NULL, according to the upstream fix.

Users of the affected components should apply one of the following mitigations:

• Upgrade to PHP 8.1.33, 8.2.29, 8.3.23, 8.4.10, or later.
• Leverage a commercial support partner like HeroDevs (NES for PHP) for post-EOL security support.

Credits

• Ahmed Lekssays (finder, remediation)
• Nora Dossche (remediation)