Skip to content

← Public intelligence

npm package

@tak-ps/cloudtak

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 7.6npmAmendedPublished

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

    CVE-2026-55177 · GHSA-r95q-fp26-h3hc

    Affected
    • npm @tak-ps/cloudtak < 13.10.0
    Fixed in
    13.10.0· Vendor fix available
    Issue
    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.isauth(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…

    Recommended action: Upgrade to 13.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  2. Medium, CVSS 5.0npmAmendedPublished

    TAK-PS-Stats Web UI: Authenticated full-read SSRF in CloudTAK basemap import (PUT /api/basemap) — no IP-classification guard

    CVE-2026-54546 · GHSA-vqrw-qphh-p34v

    Affected
    • npm @tak-ps/cloudtak < 13.22.1
    Fixed in
    13.22.1· Vendor fix available
    Issue
    PUT /api/basemap (the basemap import endpoint) fetches an attacker-supplied URL server-side with no SSRF protection whatsoever. Any authenticated user can submit a JSON body { "type": "...", "url": "<attacker url" }; the server calls fetch(url) against that URL and then reflects the response body (name, attribution, tiles[0], zoom levels) back to the caller in the OptionalTileJSON response. Because there is no IP-address classification, internal-only services are reachable: cloud metadata (http://169.254.169.254/...), loopback (http://127.0.0.1/...), RFC1918 ranges, and CGNAT. The response body flows back to the attacker, making this a full-read SSRF (not blind): the attacker reads the internal HTTP response verbatim. This enables theft of cloud instance credentials, internal service enumeration, and reading of internal-only HTTP endpoints from the network position of the CloudTAK API server. The only URL check in the basemap protocol layer (BasemapProtocol.isValidURL,…

    Recommended action: Upgrade to 13.22.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →