CVE-2026-100373 in OpenMetadata
Summary
by MITRE • 09/25/2026
OpenMetadata through 2.0.2 contains a server-side request forgery vulnerability in the URLValidator.validateURL function that fails to properly resolve DNS hostnames and validate internal addresses. Users permitted to create or update EventSubscription can set webhook destinations to internal hosts, allowing the server to send requests to private networks and cloud metadata endpoints while returning HTTP status codes that enable blind SSRF probing.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
OpenMetadata versions up through 2.0.2 are affected by a critical Server-Side Request Forgery vulnerability located within the URLValidator.validateURL function. This security flaw stems from an insufficient validation mechanism when processing user-supplied URLs, specifically regarding DNS hostname resolution and internal address verification. The core technical deficiency lies in the application's failure to adequately distinguish between public internet resources and private network endpoints during the validation phase. Instead of strictly enforcing allowlists or rejecting requests destined for non-routable IP ranges such as RFC 1918 addresses, localhost, or cloud metadata service IPs like those found on AWS EC2 instances, the validator permits these inputs to pass through without triggering appropriate security blocks. This oversight allows attackers who possess permissions to create or update EventSubscription configurations to manipulate webhook destinations toward internal infrastructure components that are otherwise inaccessible from the public internet.
The operational impact of this vulnerability is significant because it enables blind SSRF probing against private networks and sensitive cloud metadata endpoints. By configuring a webhook target to an internal host, authenticated users can force the OpenMetadata server to initiate HTTP requests on their behalf. The application's response behavior further exacerbates the risk by returning distinct HTTP status codes based on whether the request succeeds or fails in reaching its destination. This differential response mechanism provides attackers with a reliable channel for blind exploitation techniques, allowing them to infer information about internal network topology and service availability without needing direct access to the target resources. Such capabilities can be leveraged to discover sensitive data stored within cloud metadata services, which often contain authentication credentials, instance profiles, or configuration details that could lead to full system compromise if combined with other attack vectors.
From a classification perspective, this vulnerability aligns closely with CWE-918 Server-Side Request Forgery and specifically relates to CWE-20 Improper Input Validation where the application fails to verify that user input conforms to expected formats or destinations. In terms of offensive security frameworks, this exploit path corresponds to MITRE ATT&CK technique T1557 Adversary-in-the-Middle, as it allows an attacker to position themselves between internal services by proxying requests through a trusted server component like OpenMetadata. The ability to probe internal networks effectively bypasses perimeter defenses since the traffic originates from a legitimate and authorized service account or application instance within the protected environment.
To mitigate this vulnerability, organizations running affected versions of OpenMetadata should immediately upgrade to version 2.0.3 or later where these validation checks have been strengthened. In environments where upgrading is not immediately feasible, administrators can implement network-level controls such as firewall rules that restrict outbound HTTP traffic from the OpenMetadata server host to only known external domains and block access to private IP ranges entirely. Additionally, implementing strict input validation at the API gateway level or using a Web Application Firewall with SSRF detection capabilities can provide an additional layer of defense by inspecting outgoing requests for suspicious destination patterns before they reach the application logic. Regular security audits focusing on URL handling functions in all web-facing applications are also recommended to prevent similar misconfigurations from being introduced into other systems within the infrastructure.