How We Audited a High-Traffic Magento 2 Enterprise Stack on AWS and Mitigated XML External Entity (XXE) injection in old SOAP integrations

Initial Stack Assessment and Threat Landscape

Our engagement began with a deep dive into a high-traffic Magento 2 Enterprise Edition stack hosted on AWS. The primary concern was a recent security audit that flagged potential XML External Entity (XXE) injection vulnerabilities, specifically within legacy SOAP integrations. These integrations, often developed years prior and maintained by different teams, presented a significant attack surface. The stack comprised several key AWS components: EC2 instances for the Magento application and web servers (likely Nginx or Apache), RDS for the primary database, ElastiCache for Redis, and S3 for media storage. The Magento version was confirmed to be 2.4.x, which, while having some built-in XXE mitigations, was not immune if configurations or custom code bypassed these safeguards.

The threat model focused on attackers exploiting XXE vulnerabilities in the SOAP endpoints to:

Read sensitive files from the server’s filesystem (e.g., app/etc/env.php, SSH private keys, system configuration files).
Perform Server-Side Request Forgery (SSRF) by making the server initiate requests to internal AWS metadata services (e.g., http://169.254.169.254/latest/meta-data/) or other internal network resources.
Cause denial-of-service (DoS) through recursive entity expansion (Billion Laughs attack).

Identifying Vulnerable SOAP Endpoints

The first step was to catalog all active SOAP endpoints. Magento 2 exposes several WSDL endpoints, typically found under paths like /soap/default/?wsdl&services=.... We needed to identify which of these were actively used by external integrations and, crucially, which were exposed to the public internet versus internal networks. A combination of Nginx/Apache access logs and network traffic analysis (if available) was used. For this specific case, we identified two primary legacy SOAP integrations that were still in use:

A third-party ERP system integration.
A custom order fulfillment service.

We then focused on the XML parsing mechanisms within these integrations. Magento 2, by default, attempts to mitigate XXE. However, custom SOAP handlers or older versions of PHP libraries could override these protections. The critical point of failure is often the libxml_disable_entity_loader() function. If this function is set to false (or not called at all) before parsing untrusted XML, the server becomes vulnerable.

Manual Code Review and Static Analysis

A thorough manual code review of the SOAP service implementations was paramount. We looked for instances where XML was being parsed from user-supplied input without proper sanitization or entity loading being disabled. The key function to scrutinize is SimpleXMLElement::loadXML() or DOMDocument::loadXML().

Consider a hypothetical vulnerable PHP snippet within a custom SOAP handler:

<?php
// ... inside a SOAP service method ...

$xmlString = $this->getRequest()->getRawBody(); // Assuming this retrieves the raw XML payload

// Vulnerable parsing: libxml_disable_entity_loader(false) might be implicitly or explicitly set elsewhere,
// or the PHP version/configuration might default to allowing external entities.
$xml = simplexml_load_string($xmlString);

if ($xml === false) {
    // Handle XML parsing errors
} else {
    // Process XML data...
    // This is where an attacker could inject malicious XML
}
?>

The goal was to find code like this and ensure that libxml_disable_entity_loader(true); was called *before* any XML parsing occurs, or that the XML parser was configured to disallow external entities.

We also leveraged static analysis tools. While not a silver bullet, tools like PHPStan or custom regex-based scripts can help identify patterns associated with XML parsing and potential XXE vectors across a large codebase.

Exploitation and Proof-of-Concept (PoC)

To confirm the vulnerabilities, we crafted proof-of-concept payloads. The primary goal was to demonstrate the ability to read sensitive files. A common target is app/etc/env.php, which contains database credentials and other sensitive configuration.

A typical XXE payload to read a file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=app/etc/env.php">
]>
<root>
  <data>&xxe;</data>
</root>

This payload defines an external entity `&xxe;` that uses PHP’s filter chain to read the contents of app/etc/env.php, encode it in Base64, and then embed it within the XML structure. The `php://filter` wrapper is a powerful tool for exfiltrating file contents when XXE is present.

If the server is vulnerable, the response from the SOAP endpoint would contain the Base64 encoded content of env.php. We would then decode this to verify.

Another critical test was for SSRF, targeting the AWS instance metadata service:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME>">
]>
<root>
  <data>&xxe;</data>
</root>

Replacing <ROLE_NAME> with the actual IAM role name assigned to the EC2 instance (which can often be discovered through other metadata endpoints) could reveal temporary security credentials, granting attackers access to other AWS resources.

Mitigation Strategies Implemented

Based on the findings, we implemented a multi-layered mitigation strategy:

1. Server-Side XML Parsing Hardening

The most direct fix was to ensure that all XML parsing within the application, especially for untrusted input, strictly disables external entity loading. This was achieved by modifying the relevant SOAP service handlers and any other custom XML processing logic to include:

<?php
// ...

$xmlString = $this->getRequest()->getRawBody();

$xml = new DOMDocument();
// Crucially, disable external entity loading BEFORE loading the XML
$xml->loadXML($xmlString, LIBXML_NOENT | LIBXML_XINCLUDE); // LIBXML_NOENT is often sufficient, but LIBXML_XINCLUDE can also be relevant.
// Alternatively, and often preferred for clarity and broader protection:
// $xml = new DOMDocument();
// $xml->resolveExternals = false; // This is a DOMDocument property
// $xml->loadXML($xmlString);

// Ensure libxml_disable_entity_loader is called if using older PHP versions or other parsing methods
if (function_exists('libxml_disable_entity_loader')) {
    libxml_disable_entity_loader(true);
}

// If using SimpleXML, ensure it's done before parsing:
// if (function_exists('libxml_disable_entity_loader')) {
//     libxml_disable_entity_loader(true);
// }
// $xml = simplexml_load_string($xmlString);

// ... process $xml ...
?>

We also updated the PHP version to the latest stable release (e.g., 8.x) as newer versions often have improved default security settings and better library support.

2. Web Application Firewall (WAF) Rules

While code-level fixes are preferred, a WAF provides an essential defense-in-depth layer. We implemented custom WAF rules (e.g., using AWS WAF or a cloud-native WAF solution) to detect and block common XXE patterns in incoming requests to the SOAP endpoints. This included rules to:

Block requests containing <!DOCTYPE declarations with external entity definitions (SYSTEM or PUBLIC keywords followed by URLs or file paths).
Sanitize or reject requests with suspicious XML parsing directives like php://, file://, or common SSRF targets like 169.254.169.254 within the XML payload.
Monitor for unusual entity expansion attempts.

Example AWS WAF rule logic (conceptual):

// Rule: Block XXE Doctype Declarations
If the request body contains a pattern matching:
<!DOCTYPE\s+[a-zA-Z0-9]+\s+(SYSTEM|PUBLIC)\s+["'][^"']+["']

// Rule: Block XXE Protocol Wrappers
If the request body contains a pattern matching:
(php://|file://|http:\/\/169\.254\.169\.254)

These rules were configured to be in “count” mode initially to monitor for false positives before switching to “block” mode.

3. Network Segmentation and Access Control

For SOAP integrations that did not require public internet access, we enforced stricter network segmentation. This involved:

Placing the application servers and integration endpoints within private subnets.
Using Security Groups and Network ACLs to restrict inbound traffic to only necessary IP addresses or CIDR blocks.
Leveraging AWS PrivateLink or VPC Endpoints for secure communication between services where applicable, rather than exposing endpoints over the public internet.

This significantly reduced the attack surface by ensuring that only authorized systems could even attempt to interact with the SOAP endpoints.

4. Dependency Updates and Patching

We reviewed all third-party modules and custom extensions that might interact with XML parsing or SOAP. Any outdated libraries known to have XXE vulnerabilities were updated or replaced. A regular patching schedule for Magento itself, PHP, and underlying operating systems was reinforced.

Post-Mitigation Verification and Monitoring

After implementing the fixes, a rigorous re-testing phase was conducted. We re-ran all the previously successful XXE and SSRF PoCs to confirm they were now blocked or resulted in safe error messages. Automated security scanning tools were also re-pointed at the endpoints.

Ongoing monitoring was established, focusing on:

WAF logs for any blocked XXE attempts, which could indicate continued external probing.
Application error logs for any unexpected XML parsing failures that might suggest a new vulnerability or a misconfiguration.
AWS CloudTrail logs for any suspicious API calls originating from the EC2 instance metadata service, which could indicate a successful SSRF exploit if network controls failed.
Regular security audits and penetration testing cycles.

This comprehensive approach, combining code-level remediation, network security, and robust monitoring, successfully mitigated the identified XXE injection risks within the Magento 2 Enterprise stack.