Drupal 10.1.2 - web-cache-poisoning-External-service-interaction

Drupal 10.1.2 Web Cache Poisoning via External Service Interaction: A Critical Security Vulnerability

Drupal 10.1.2, a widely used open-source content management system (CMS), has recently been identified as vulnerable to a high-severity web cache poisoning exploit that leverages external service interaction. This vulnerability, disclosed by security researcher nu11secur1ty on August 30, 2023, enables attackers to manipulate server-side HTTP requests to arbitrary domains, potentially leading to widespread malicious content delivery to unsuspecting users.

Understanding the Vulnerability: How Cache Poisoning Works

Web cache poisoning is a sophisticated attack technique where an attacker forces a web application to cache malicious content under a specific URL or request path. Once cached, this content is served to all subsequent users who request the same resource, effectively propagating the attack across the user base.

In the case of Drupal 10.1.2, the vulnerability arises from improper handling of HTTP headers—specifically the Host header—during internal request processing. When a user sends a crafted HTTP request with a malicious Host value, the application interprets this as a legitimate external service request, even though it’s not intended for actual network communication.

This behavior is particularly dangerous because Drupal’s caching mechanism stores responses based on request parameters and headers. If an attacker controls the Host header, they can trigger the server to perform a real HTTP request to a domain they control—such as a Burp Collaborator or Oastify domain—and then store the malicious response in the cache.

Exploit Details and Proof of Concept

The following HTTP request demonstrates the exploit:

GET /drupal/web/?psp4hw87ev=1 HTTP/1.1
Host: d7lkti6pq8fjkx12ikwvye34ovuoie680wqjg75.oastify.com
Accept-Encoding: gzip, deflate, psp4hw87ev
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7,
text/psp4hw87ev
Accept-Language: en-US,psp4hw87ev;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.111
Safari/537.36 psp4hw87ev
Connection: close
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Sec-CH-UA: ".Not/A)Brand";v="99", "Google Chrome";v="116", "Chromium";v="116"
Sec-CH-UA-Platform: Windows
Sec-CH-UA-Mobile: ?0
Origin: https://psp4hw87ev.pwnedhost.com

Explanation: The attacker injects a unique domain in the Host header—d7lkti6pq8fjkx12ikwvye34ovuoie680wqjg75.oastify.com—which is controlled by the attacker. This domain is designed to capture HTTP requests from the Drupal server. The psp4hw87ev parameter is used as a placeholder to avoid triggering internal filtering mechanisms.

The server, due to flawed logic in request handling, treats this as a valid external service call and performs an actual HTTP GET request to the attacker-controlled domain. The response from the server—zeq5zcbz3x69x9a63ubxidzjlgigmmgifigz—is then cached based on the request parameters and headers.

Subsequent users who access /drupal/web/?psp4hw87ev=1 will receive the cached malicious response, even if the original request had no such intent. This is the essence of cache poisoning.

Real-World Impact and Attack Vector

This vulnerability is particularly dangerous in environments where:

• Drupal is used as a public-facing website with caching enabled (e.g., for performance).
• Users are frequently directed to URLs via email, social media, or third-party links.
• Content is automatically generated from external sources (e.g., RSS feeds).

Example Use Case: An attacker could craft a malicious URL like https://example.com/drupal/web/?psp4hw87ev=1 and send it via phishing email. When a user clicks the link, their browser triggers a request to the Drupal server. If the server has cached the malicious response, the user is served a payload—such as a JavaScript injection or redirect to a phishing site—without realizing they’ve been compromised.

Additionally, if the site uses rss.xml or similar endpoints, attackers can poison the cache by sending requests to /drupal/web/rss.xml?psp4hw87ev=1, causing the cached feed to include malicious content that appears in user RSS readers.

Technical Root Cause and Risk Analysis

The root cause lies in Drupal’s request processing pipeline, specifically in how it handles the Host header during internal HTTP requests. The system does not properly validate or sanitize this header when used in the context of external service calls—especially when such calls are triggered by user input or cached paths.

Key risk factors:

Factor	Risk Level	Description
Cache Mechanism	High	Responses are cached based on request parameters, allowing persistent poisoning.
External Service Interaction	High	Server performs actual HTTP requests to arbitrary domains based on user input.
Input Sanitization	Medium	Missing validation of Host header in non-external contexts.
Public Exposure	High	Commonly used in public websites, increasing attack surface.

Recommended Mitigations and Fixes

While Drupal 10.1.2 is currently vulnerable, the following mitigations are recommended for immediate implementation:

• Disable or restrict external service interaction: Ensure that the application does not make outbound HTTP requests based on user-supplied headers, especially Host.
• Implement strict header validation: Reject any Host header that does not match the server’s domain or is not explicitly allowed.
• Use secure caching policies: Cache only responses from trusted sources and ensure cache keys do not include user-controlled parameters.
• Monitor and audit: Use logging and monitoring tools to detect unexpected outbound HTTP requests to unknown domains.
• Update Drupal: Apply the official patch from Drupal.org as soon as it is released.

For developers, consider implementing a trusted_host whitelist in the application configuration. This ensures that only predefined domains are allowed in external service calls.

Conclusion: A Wake-Up Call for CMS Security

Drupal 10.1.2’s web cache poisoning vulnerability highlights a critical gap in modern web application security: the danger of trusting user input in HTTP headers. Even seemingly benign fields like Host can be weaponized if not properly validated.

Security professionals must prioritize:

• Input validation across all HTTP headers.
• Cache integrity checks.
• Monitoring for anomalous outbound requests.

As this exploit demonstrates, a single misconfigured parameter can compromise the entire user base. The nu11secur1ty research serves as a reminder: even trusted open-source platforms are not immune to zero-day vulnerabilities. Proactive security measures and timely updates are essential to protect digital infrastructure.</