GHSA-q59x-jc9f-gfqf Signal K Server: Server-Side Request Forgery via Remote Connection Endpoints
Summarysignalk-server versions up to and including 2.27.0 contain a Server-Side Request Forgery (SSRF) vulnerability in three administrative endpoints used for remote Signal K server connection management. The `makeRemoteRequest()` function accepts attacker-controlled `host`, `port`, `useTLS`, and `selfsignedcert` parameters without any validation, allowing an attacker to force the server to make arbitrary HTTP/HTTPS requests to internal network resources, cloud metadata services, and other unintended destinations.When security is not configured (the default state), these endpoints require **no authentication**.DetailsVulnerable FunctionThe core vulnerability is in `makeRemoteRequest()` at `src/serverroutes.ts:2483-2524`:Missing ValidationThe function performs **zero validation** on the destination host. The following address ranges are all reachable:**Loopback**: `127.0.0.1`, `::1`, `localhost`**RFC 1918 private ranges**: `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`**Link-local / Cloud metadata**: `169.254.169.254` (AWS EC2 instance metadata, GCP, Azure IMDS)**IPv6 link-local**: `fe80::/10`**Any arbitrary external host**: enabling the server as an open proxyAuthentication Bypass via Default ConfigurationThe endpoints are protected by `addAdminMiddleware()` (lines 2339-2345):However, when security is not configured, the server uses `dummysecurity.ts`, where `addAdminMiddleware` is a **no-op**:This means on a default installation with no admin user created, **all three endpoints are accessible without any authentication**.Additional Attack Surface: TLS Verification BypassThe `selfsignedcert` parameter directly controls `rejectUnauthorized`:When an attacker sets `selfsignedcert: true`, the server will connect to any HTTPS endpoint without verifying the TLS certificate, enabling MITM attacks on the outbound connection.Additional Attack Surface: Path Traversal in checkAccessRequestThe `checkAccessRequest` endpoint interpolates `requestId` directly into the URL path:An attacker can use path traversal (e.g., `requestId: "../../other/endpoint"`) to target arbitrary paths on the destination host.PoCTarget SetupSet up a bare-metal signalk-server for testing (or use Docker to simulate):Set the target variable:Confirm `"authenticationRequired":false` in the loginStatus response before proceeding.PoC 1: Loopback Connection (Self-Discovery)**Response** (confirms SSRF, the server connected to itself):PoC 2: Port Scanning via Error DifferentiationThe three distinct error responses allow an attacker to map internal network topology.PoC 3: AWS Instance Metadata Service (IMDSv1)On a cloud-hosted signalk-server (AWS EC2):The server connects to the EC2 metadata endpoint. The response will contain the discovery JSON parse result, leaking metadata. For deeper paths, use `checkAccessRequest` with path traversal in `requestId`:Impact**Internal Network Scanning**: An attacker can probe internal hosts and ports. The response distinguishes between open ports (HTTP response returned), closed ports (connection refused error), and filtered ports (timeout after 10 seconds).**Cloud Metadata Exfiltration**: On cloud-hosted instances (AWS EC2, GCP, Azure), an attacker can reach the instance metadata service at `169.254.169.254` to steal IAM credentials, instance identity tokens, and other sensitive metadata.**Internal Service Data Exfiltration**: The `testSignalKConnection` endpoint returns the full response body from the target, allowing reading of data from internal HTTP services not otherwise accessible from the internet.**Server-Side POST Requests**: The `requestAccess` endpoint sends a POST request with attacker-controlled JSON body (`clientId`, `description`), enabling interaction with internal APIs that accept POST requests.**Lateral Movement**: In containerized or Kubernetes environments, the server can be used to access cluster-internal services, the Kubernetes API, or other containers on the Docker network.
CVSS v3.1 score: 5.8