A newly identified vulnerability, CVE-2025-1219, affects multiple PHP versions and puts many web applications at risk when using the DOM and SimpleXML extensions to fetch remote HTTP resources. The flaw centers on how PHP handles the content-type header, specifically the charset, when following HTTP redirects. This misbehavior can lead to incorrect document parsing and may give attackers a way to bypass content validation.

This post walks you through what CVE-2025-1219 means, how it works, real-world exploit examples, and what you can do to keep your web apps safe.

PHP 8.4.\* before 8.4.5

If you're running any of these, especially in web-facing environments, it's important to update ASAP.

The Vulnerability in Simple Terms

When your PHP code uses DOM or SimpleXML to open a remote HTTP(S) resource, it might follow an HTTP 3xx redirect. The serious *bug* is: PHP keeps using the original content-type header to determine the charset of the resource, even after a redirect to a different domain or file type. That means PHP might parse the *wrong* type of document, misinterpret encodings, or skip vital security checks.

An attacker could craft a malicious page that redirects you to content with an intentionally mismatched charset, leading to security bypasses or data corruption.

Let’s see a code snippet that demonstrates the vulnerable behavior

<?php
// Vulnerable: PHP prior to 8.1.32, 8.2.28, 8.3.19, 8.4.5
$url = "http://attacker.com/redirect";;
$doc = new DOMDocument();
$doc->load($url);
echo $doc->saveXML();
?>

How the exploit works

1. You request http://attacker.com/redirect.
2. That URL issues a 302 redirect to, say, http://attacker.com/evil.xml.
3. The initial response has a Content-Type: text/html; charset=UTF-8.
4. The final evil.xml instead is actually Content-Type: text/xml; charset=ISO-8859-1 and crafted to exploit parsing differences.
5. PHP uses the *original* charset (UTF-8) to parse the final XML, causing parsing mismatches or allowing bypasses.

Exploit Scenario

Suppose your app validates XML input by checking for valid encodings or certain content, but the attacker tricks the parser thanks to the encoding confusion. The attacker might introduce malicious code or inject unwanted data, bypassing your validation.

Your app uses DOMDocument::load() on user-supplied URLs.

2. Attacker's server returns a harmless response with Content-Type: text/html; charset=UTF-8 and a redirect to a different resource.
3. Actual payload (malicious XML/HTML) is returned with another encoding.
4. Your app parses the attacker’s content using the *wrong* charset, resulting in unintended behavior.

First response, at /redirect

HTTP/1.1 302 Found
Location: http://attacker.com/malicious.xml
Content-Type: text/html; charset=UTF-8

Second response, at /malicious.xml

HTTP/1.1 200 OK
Content-Type: text/xml; charset=ISO-8859-1

<!-- Insert malicious content encoded in ISO-8859-1 -->

PHP Fetcher

<?php
$doc = new DOMDocument();
$doc->load("http://attacker.com/redirect";);
echo $doc->saveXML();
?>

If you analyze the parsing behavior, you’ll notice PHP interprets the content using UTF-8 (from original header), potentially misreading the malicious content or not catching forbidden constructs.

Bypassing Validation: App logic that restricts input based on charset can be bypassed.

- Parsing Poisoning: The wrong charset might hide or reveal content, causing missed security checks.
- Injection & Manipulation: Mismatched parsing opens new doors for data or code injection, even if you’re validating downstream.

Original References

* PHP Changelog 8.1.32
* GitHub Commit Fixing the Bug *(replace with actual commit)*
* CVE Details Listing

Conclusion

CVE-2025-1219 is a real-world example of how small header misinterpretations can have big consequences for web security. If your PHP code fetches remote HTTP resources, especially using DOM or SimpleXML, make sure to patch and validate everything. The fix is simple, but the risks are not.

Stay safe, keep your stack updated, and help spread the word!


For more technical details, check the PHP security team advisories and keep an eye on Mitre’s CVE entry as new information emerges.

Timeline

Published on: 03/30/2025 06:15:13 UTC
Last modified on: 04/15/2025 16:54:55 UTC