CVE-2026-92932: MISP sachertortephp Xml::build() Operator Precedence Bypass Allows Unintended HTTPS SSRF When readFile Is Disabled
In the MISP sachertortephp library, the Xml::build() static method in lib/Cake/Utility/Xml.php contains a logic error in the conditional that gates network-based XML fetching. The original condition was written as: $options['readFile'] && strpos($input, 'http://') === 0 || strpos($input, 'https://') === 0. Because PHP's && operator has higher precedence than ||, the expression is evaluated as ($options['readFile'] && strpos($input, 'http://') === 0) || strpos($input, 'https://') === 0. As a result, when a caller explicitly sets the readFile option to false to disable file and URL reading, an input string beginning with https:// still satisfies the condition and triggers a network fetch via HttpSocket (configured to follow up to 10 redirects). The http:// branch is correctly gated by the readFile flag, but the https:// branch is not. An attacker who can influence the $input parameter passed to Xml::build() can therefore force the application to issue an outbound HTTPS request to an attacker-controlled or internal URL, even though the caller intended to suppress all remote reads. The fetched response is parsed as XML and may be returned to the caller, enabling information disclosure from internal services or external targets. This constitutes a Server-Side Request Forgery (SSRF) weakness with an information-disclosure impact. The vulnerability requires that the code path in Xml::build() be reachable with attacker-controlled input and that the readFile option be set to false (or the caller expects it to be false).
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using the affected Xml::build() method are exposed when an attacker can control its input and the application explicitly sets readFile to false. The bypass applies to inputs beginning with https://; http:// inputs remain gated by the flag.
What does an attacker need to exploit it?
The attacker needs to influence the string passed as the $input parameter to Xml::build() and make it begin with an HTTPS URL. No ability to enable readFile is required, because the HTTPS branch bypasses that setting.
What network behavior can exploitation trigger?
The application can make an outbound HTTPS request through HttpSocket to an attacker-controlled or internal URL. HttpSocket is configured to follow up to 10 redirects, and the fetched response is parsed as XML and may be returned to the caller.
How can I reduce exposure if I cannot apply the referenced fix immediately?
Do not pass attacker-influenced strings to Xml::build(), particularly strings that may begin with https://. Enforce an allowlist or reject URL-like input before it reaches this method, and restrict outbound network access from the application where possible.