{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/cloudtak--13.7.0/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["CloudTAK \u003c= 13.7.0"],"_cs_severities":["high"],"_cs_tags":["ssrf","web-vulnerability","credential-access","network-discovery","cloud-security"],"_cs_type":"advisory","_cs_vendors":["dfpc-coe"],"content_html":"\u003cp\u003eA 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 \u003ccode\u003e/api/esri*\u003c/code\u003e 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 \u003ccode\u003e169.254.169.254\u003c/code\u003e) or loopback admin ports (\u003ccode\u003e127.0.0.1:\u0026lt;port\u0026gt;\u003c/code\u003e). 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 \u003ccode\u003eisSafeUrl\u003c/code\u003e guard was implemented in other parts of the application but neglected for the \u003ccode\u003e/api/esri*\u003c/code\u003e routes, which continue to use an unguarded \u003ccode\u003efetch\u003c/code\u003e function from \u003ccode\u003e@tak-ps/etl\u003c/code\u003e.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn authenticated attacker (any valid user token) sends an HTTP POST request to \u003ccode\u003e/api/esri\u003c/code\u003e with a malicious \u003ccode\u003eurl\u003c/code\u003e parameter in the body, or an HTTP GET request to \u003ccode\u003e/api/esri/*\u003c/code\u003e with malicious \u003ccode\u003eportal\u003c/code\u003e, \u003ccode\u003eserver\u003c/code\u003e, or \u003ccode\u003elayer\u003c/code\u003e query parameters.\u003c/li\u003e\n\u003cli\u003eThe CloudTAK application receives the request, which contains a crafted URL targeting an internal resource, such as \u003ccode\u003ehttp://169.254.169.254/latest/meta-data/iam/security-credentials/arcgis/rest\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe application's \u003ccode\u003eEsriBase.sniff()\u003c/code\u003e function performs a path validation, checking for \u003ccode\u003e/rest\u003c/code\u003e, \u003ccode\u003e/arcgis/rest\u003c/code\u003e, or \u003ccode\u003e/sharing/rest\u003c/code\u003e within the URL's pathname, which the crafted URL satisfies.\u003c/li\u003e\n\u003cli\u003eCrucially, no host or IP address validation is performed, allowing internal IP addresses (e.g., \u003ccode\u003e169.254.169.254\u003c/code\u003e, \u003ccode\u003e127.0.0.1\u003c/code\u003e) to pass the check.\u003c/li\u003e\n\u003cli\u003eThe CloudTAK server, using the unguarded \u003ccode\u003efetch\u003c/code\u003e function from \u003ccode\u003e@tak-ps/etl\u003c/code\u003e, makes an outbound HTTP request to the attacker-controlled internal address.\u003c/li\u003e\n\u003cli\u003eThe targeted internal service (e.g., AWS IMDSv1, a local admin port, or other VPC-internal services) responds to the CloudTAK server's request.\u003c/li\u003e\n\u003cli\u003eThe CloudTAK application captures the full response body or error message from the internal service.\u003c/li\u003e\n\u003cli\u003eThe application reflects this sensitive internal information, including potential cloud credentials or internal service configurations, back to the attacker.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis 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 (\u003ccode\u003e169.254.169.254\u003c/code\u003e), 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;Detect CloudTAK SSRF Attempt via GET /api/esri/*\u0026quot; to your SIEM to identify suspicious exploitation attempts.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for HTTP GET requests to \u003ccode\u003e/api/esri/*\u003c/code\u003e routes containing internal IP addresses (e.g., 127.0.0.1, 169.254.169.254) or \u003ccode\u003elocalhost\u003c/code\u003e within the \u003ccode\u003eportal\u003c/code\u003e, \u003ccode\u003eserver\u003c/code\u003e, or \u003ccode\u003elayer\u003c/code\u003e query parameters.\u003c/li\u003e\n\u003cli\u003ePatch CloudTAK instances to a version that remediates GHSA-r95q-fp26-h3hc immediately.\u003c/li\u003e\n\u003cli\u003eImplement robust egress filtering on network firewalls and security groups to prevent CloudTAK servers from making outbound connections to internal-only IP ranges (e.g., \u003ccode\u003e169.254.169.254\u003c/code\u003e, \u003ccode\u003e127.0.0.1\u003c/code\u003e, RFC1918 addresses) unless absolutely essential and explicitly allowlisted.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-17T21:36:31Z","date_published":"2026-07-17T21:36:31Z","id":"https://feed.craftedsignal.io/briefs/2026-07-cloudtak-ssrf/","summary":"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.","title":"Authenticated Full-Read SSRF in CloudTAK /api/esri* Routes","url":"https://feed.craftedsignal.io/briefs/2026-07-cloudtak-ssrf/"}],"language":"en","title":"CraftedSignal Threat Feed - CloudTAK \u003c= 13.7.0","version":"https://jsonfeed.org/version/1.1"}