signalk-server has SSRF via absolute signalk.appIcon URL in the app store icon fetcher

Summary

The app store icon code (dist/appstore/icon-probe.js around line 200 and icon-bytes.js around line 138) resolves a plugin's declared signalk.appIcon. Relative paths are pinned to the CDN, but an absolute http(s) URL is used as-is: the server fetches it, follows redirects, and stores any image/* response as the plugin's icon, which is then served to the admin UI. Unrelated to GHSA-q59x-jc9f-gfqf.

Affected

signalk-server 2.33.0 (latest).

Reproduction

The real dist modules driven directly, Docker with --network none; a local "internal" service on 127.0.0.1 logs requests:

[CONTROL relative] declared=../../icon.png
  resolved=null
  internal-service hits: []  stored: null
[ATTACK absolute] declared=http://127.0.0.1:35013/latest/meta-data/iam
  resolved=http://127.0.0.1:35013/latest/meta-data/iam
  internal-service hits: ["GET /latest/meta-data/iam"]  stored: .../icon-bytes/[email protected] (70 bytes)
[ATTACK redirect] declared=http://127.0.0.1:35013/redir
  internal-service hits: ["GET /redir","GET /internal-secret-via-redirect.png"]  stored: .../icon-bytes/[email protected] (70 bytes)

The modules were tested directly rather than through a full running server.

Impact

Anyone who can get a plugin listed in the app store (publishing an npm package with the signalk keywords) can make every signalk-server that browses the app store send requests to internal addresses on the vessel network and to cloud metadata endpoints. Responses with an image content type are stored and served back to the user.

Suggested fix

Only accept relative icon paths resolved against the CDN (or an https allowlist of known hosts), do not follow redirects to other hosts, and reject private, loopback and link-local addresses after resolution.