CloudTAK <= 13.7.0 - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/cloudtak--13.7.0/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioFri, 17 Jul 2026 21:36:31 +0000Authenticated Full-Read SSRF in CloudTAK /api/esri* Routeshttps://feed.craftedsignal.io/briefs/2026-07-cloudtak-ssrf/Fri, 17 Jul 2026 21:36:31 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-07-cloudtak-ssrf/An authenticated Server-Side Request Forgery (SSRF) vulnerability exists in CloudTAK's `/api/esri*` routes, allowing any authenticated user to compel the server to make arbitrary outbound HTTP requests to internal network resources, enabling attackers to access sensitive cloud instance metadata, enumerate internal services, and exfiltrate data by reflecting the response bodies.A critical authenticated Server-Side Request Forgery (SSRF) vulnerability (GHSA-r95q-fp26-h3hc) has been identified in CloudTAK versions up to and including 13.7.0. The vulnerability resides within the /api/esri* family of routes, which process user-controlled URLs without proper IP/DNS classification. This oversight allows any authenticated user to force the CloudTAK server to initiate arbitrary HTTP requests to internal network resources, such as cloud instance metadata services (e.g., AWS IMDSv1 at 169.254.169.254) or loopback admin ports (127.0.0.1:<port>). Unlike blind SSRF, this is a full-read vulnerability, reflecting the upstream response body or error message directly back to the attacker. The issue stems from an incomplete security hardening effort, where an existing isSafeUrl guard was implemented in other parts of the application but neglected for the /api/esri* routes, which continue to use an unguarded fetch function from @tak-ps/etl.

Attack Chain

  1. An authenticated attacker (any valid user token) sends an HTTP POST request to /api/esri with a malicious url parameter in the body, or an HTTP GET request to /api/esri/* with malicious portal, server, or layer query parameters.
  2. The CloudTAK application receives the request, which contains a crafted URL targeting an internal resource, such as http://169.254.169.254/latest/meta-data/iam/security-credentials/arcgis/rest.
  3. The application's EsriBase.sniff() function performs a path validation, checking for /rest, /arcgis/rest, or /sharing/rest within the URL's pathname, which the crafted URL satisfies.
  4. Crucially, no host or IP address validation is performed, allowing internal IP addresses (e.g., 169.254.169.254, 127.0.0.1) to pass the check.
  5. The CloudTAK server, using the unguarded fetch function from @tak-ps/etl, makes an outbound HTTP request to the attacker-controlled internal address.
  6. The targeted internal service (e.g., AWS IMDSv1, a local admin port, or other VPC-internal services) responds to the CloudTAK server's request.
  7. The CloudTAK application captures the full response body or error message from the internal service.
  8. The application reflects this sensitive internal information, including potential cloud credentials or internal service configurations, back to the attacker.

Impact

This full-read Server-Side Request Forgery (CWE-918) carries significant risk. Successful exploitation can lead to cloud credential theft, specifically temporary AWS credentials from IMDSv1 services (169.254.169.254), which attackers can then use to access and control cloud resources. Attackers can also perform extensive internal network enumeration, probing any host and port reachable from the CloudTAK server, including loopback admin ports and VPC-internal services. The ability to read full JSON responses allows for data exfiltration of sensitive information from these internal systems. While the vulnerability requires authentication, it does not necessitate administrative privileges, making any authenticated user a potential vector for attack.

Recommendation

  • Deploy the Sigma rule "Detect CloudTAK SSRF Attempt via GET /api/esri/*" to your SIEM to identify suspicious exploitation attempts.
  • Monitor web server logs for HTTP GET requests to /api/esri/* routes containing internal IP addresses (e.g., 127.0.0.1, 169.254.169.254) or localhost within the portal, server, or layer query parameters.
  • Patch CloudTAK instances to a version that remediates GHSA-r95q-fp26-h3hc immediately.
  • Implement robust egress filtering on network firewalls and security groups to prevent CloudTAK servers from making outbound connections to internal-only IP ranges (e.g., 169.254.169.254, 127.0.0.1, RFC1918 addresses) unless absolutely essential and explicitly allowlisted.
]]>highadvisoryssrfweb-vulnerabilitycredential-accessnetwork-discoverycloud-security