Description

draw.io is a configurable diagramming and whiteboarding application. Prior to version 30.2.7, deployments with ENABLE_DRAWIO_PROXY=1 are vulnerable to server-side request forgery because src/main/java/com/mxgraph/online/Utils.java performs the private-address check in Utils.sanitizeUrl() using one DNS resolution, while src/main/java/com/mxgraph/online/ProxyServlet.java later calls URL.openConnection() and performs a second resolution. An attacker-controlled hostname can resolve to a public address during validation and then to a private, link-local, or cloud metadata address when the connection is opened. Successful exploitation can return cloud instance metadata or responses from internal HTTP services through the proxy. This issue is fixed in version 30.2.7.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.8",
  "pubDate": "2026-09-21T17:17:39.220Z",
  "pubdate": "2026-09-21T17:17:39.220Z",
  "executiveSummary": "A critical Server-Side Request Forgery (SSRF) vulnerability exists in draw.io versions prior to 30.2.7 when the ENABLE_DRAWIO_PROXY configuration is enabled.\nThe vulnerability arises from a Time-of-Check to Time-of-Use (TOCTOU) race condition during DNS resolution, allowing an attacker to bypass internal network access controls.\nBy manipulating DNS resolution, an unauthenticated remote attacker can force the application server to perform requests against internal services, including private IP addresses, link-local addresses, and cloud provider metadata services (e.g., 169.254.169.254).\nThis can lead to unauthorized information disclosure, such as the extraction of cloud instance identity credentials, sensitive configuration data, or interaction with internal APIs.\nThe risk is high for deployments using the proxy feature in cloud-hosted environments where metadata services are accessible from the application host.",
  "technicalDetails": "The root cause of this vulnerability is an inconsistent validation mechanism involving two separate DNS resolution events for the same hostname. In the vulnerable versions, the application performs an initial check in src/main/java/com/mxgraph/online/Utils.java via the Utils.sanitizeUrl() function. This function resolves the provided URL hostname to determine if the resulting IP address falls within a restricted range (such as private, loopback, or link-local subnets).\nHowever, the subsequent connection logic implemented in src/main/java/com/mxgraph/online/ProxyServlet.java does not reuse the validated IP address. Instead, it initiates a fresh network request via URL.openConnection(), which triggers a second, independent DNS resolution process. This design flaw introduces a TOCTOU (Time-of-Check to Time-of-Use) condition.\nAn attacker can exploit this by utilizing a malicious DNS server that returns a benign public IP address during the initial validation check performed by Utils.sanitizeUrl(). Upon passing this check, the application proceeds to the connection phase in ProxyServlet.java. During the second resolution performed by the operating system or the JVM, the attacker’s DNS server returns a restricted internal IP address, such as 127.0.0.1 or the cloud metadata service IP 169.254.169.254.\nBecause the connection is established using the malicious result from the second resolution, the application bypasses the intended security policy, allowing the server to proxy requests to internal-only resources. The attack flow involves: 1) The attacker provides a URL pointed to a controlled DNS server. 2) The application calls Utils.sanitizeUrl(), which resolves the hostname and validates the (public) IP. 3) The application calls ProxyServlet.java, which triggers a new connection. 4) The DNS server returns an internal/restricted IP address for the second lookup. 5) The server-side proxy performs an HTTP request to the restricted resource and reflects the response or performs unintended actions within the internal network context.\nThis vulnerability is restricted to deployments where ENABLE_DRAWIO_PROXY=1 is explicitly enabled. Successful exploitation does not require prior authentication, as the proxy servlet is intended to be accessible to process remote content. Post-exploitation impact ranges from internal network reconnaissance to the theft of cloud IAM tokens."
}