CVE-2026-55591

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.

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.

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:

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…

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.

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.

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:

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…