CVE-2026-53723: Guzzle Services XML CDATA Injection (request integrity)

Technical summary

The vulnerability exists in Guzzle Services' XML request serializer, which uses `XMLWriter::writeCData()` to safely escape values containing `<`, `>`, or `&`. However, the CDATA wrapper itself is terminated by the sequence `]]>`. If an attacker controls a request parameter marked with `location: xml` in the service description, they can embed `]]>` in the parameter value. This prematurely closes the CDATA section, causing the remainder of the attacker's payload to be parsed as literal XML markup by the receiving service. The vulnerability requires several conditions: the application must use `guzzlehttp/guzzle-services`, the parameter must use XML element text (not attribute) serialization, the input must be untrusted, and the downstream service must parse the malformed XML structurally. The fix in version 1.5.3+ safely splits CDATA terminators before serialization, preserving the scalar value while preventing element injection.

Business impact

Organizations using Guzzle Services to communicate with external APIs or microservices face request integrity risks. An attacker exploiting this vulnerability can cause the downstream service to interpret requests differently than intended—for example, injecting hidden fields, duplicating parameters, or bypassing validation logic. The impact depends on the receiving service's parsing behavior and the sensitivity of data being transmitted. This is particularly concerning in multi-tenant environments where one tenant's input could affect another's requests, or in scenarios where privileged or sensitive fields can be smuggled through the XML injection. Applications that only use Guzzle Services to parse incoming responses are not directly at risk unless they subsequently reuse parsed data as input to a new outgoing request.

Affected systems

Any PHP application using `guzzlehttp/guzzle-services` version prior to 1.5.3 is potentially affected if it meets all of these conditions: (1) it serializes requests with parameters defined as `location: xml` in the service description; (2) those parameters are populated as XML element text (not XML attributes); (3) the parameter values can contain untrusted input (user-supplied, tenant-controlled, or from external sources); (4) the values are not restricted by a safe `enum`, `pattern`, or custom validation that excludes `]]>`; and (5) the receiving service parses the generated XML and acts on its structure. Applications using only response parsing, or those with all XML parameters as attributes rather than element text, are unaffected.

Exploitability

Exploitation requires no authentication, no special network position, and no user interaction. An attacker simply needs to control input to a parameter that the application serializes as XML element text. The attack is straightforward: inject `]]>` followed by XML markup. However, the severity is bounded by whether the downstream service parses the resulting malformed XML in a way that changes its behavior. Some strict XML parsers may reject the malformed document; others may accept it and act on the injected elements. This makes the vulnerability moderate in impact—not trivially exploitable against all downstream services, but dangerous against permissive parsers or services that accept duplicated or unexpected fields.

Remediation

Upgrade `guzzlehttp/guzzle-services` to version 1.5.3 or later. This version safely handles CDATA terminators by splitting them before serialization, preventing injection of XML elements. For applications unable to upgrade immediately, implement one or more workarounds: (1) constrain all untrusted XML element values with a strict `enum`, `pattern`, or custom validation filter that rejects the substring `]]>`; (2) restructure the service description to use XML attributes instead of element text for parameters that contain untrusted input (attributes are not affected because they use different XMLWriter APIs); or (3) avoid serializing untrusted data into `location: xml` parameters until patched. Review your service descriptions to identify all parameters using `location: xml`, including both operation-level and `additionalParameters` definitions, and audit whether their values are controlled by untrusted sources.

Patch guidance

Update `guzzlehttp/guzzle-services` to version 1.5.3 or later using your package manager: `composer update guzzlehttp/guzzle-services`. Verify the update in your `composer.lock` file. Test your application thoroughly with your downstream services to ensure the XML requests are still correctly formed and accepted. No configuration changes are required; the fix is transparent to application code. If you maintain custom service descriptions, no modifications are needed—the fix works with existing descriptions.

Detection guidance

To identify vulnerable configurations, search your service description files (typically YAML or JSON) for parameters with `location: xml`. Use a code search tool or grep to find service definitions and examine request parameter blocks. Pay special attention to nested object and array parameters, as leaf scalar properties can also be vulnerable. Correlate those parameters with code paths that populate them from untrusted sources: user input, query parameters, request bodies, or external APIs. Review your application logs and API gateway logs for suspicious XML payloads containing `]]>` sequences in request bodies, particularly in parameters known to use XML element text serialization. Monitor the receiving downstream service's logs for unexpected XML elements or parsing warnings that might indicate injection attempts.

Why prioritize this

This vulnerability warrants prompt patching because it affects request integrity in a broadly-used library and requires no authentication or user interaction to exploit. While severity is rated MEDIUM rather than HIGH due to the requirement that downstream services parse the malformed XML structurally, the consequences can be significant: parameter smuggling, field injection, and operation semantic changes. Organizations with multi-tenant systems or those sending sensitive data through Guzzle Services to external APIs should prioritize this update. The fix is low-risk (version 1.5.3 is already stable) and straightforward to deploy.

Risk score, explained

The CVSS 3.1 score of 5.8 (MEDIUM) reflects an attack with no authentication requirement, low attack complexity, and network-accessible scope—factors that elevate concern—but limited impact (integrity only, no confidentiality or availability loss). The score acknowledges that the vulnerability enables request tampering but does not guarantee exploitation against all downstream services. The scope change to CHANGED indicates the attacker can affect downstream services beyond the vulnerable application. This is a classic case where numeric severity understates real-world risk for certain deployments (e.g., APIs handling financial or multi-tenant data), warranting context-aware prioritization by threat teams.

Frequently asked questions