CVE-2025-68620
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2026-01-01

Last updated on: 2026-01-06

Assigner: GitHub, Inc.

Description
Signal K Server is a server application that runs on a central hub in a boat. Versions prior to 2.19.0 expose two features that can be chained together to steal JWT authentication tokens without any prior authentication. The attack combines WebSocket-based request enumeration with unauthenticated polling of access request status. The first is Unauthenticated WebSocket Request Enumeration: When a WebSocket client connects to the SignalK stream endpoint with the `serverevents=all` query parameter, the server sends all cached server events including `ACCESS_REQUEST` events that contain details about pending access requests. The `startServerEvents` function iterates over `app.lastServerEvents` and writes each cached event to any connected client without verifying authorization level. Since WebSocket connections are allowed for readonly users (which includes unauthenticated users when `allow_readonly` is true), attackers receive these events containing request IDs, client identifiers, descriptions, requested permissions, and IP addresses. The second is Unauthenticated Token Polling: The access request status endpoint at `/signalk/v1/access/requests/:id` returns the full state of an access request without requiring authentication. When an administrator approves a request, the response includes the issued JWT token in plaintext. The `queryRequest` function returns the complete request object including the token field, and the REST endpoint uses readonly authentication, allowing unauthenticated access. An attacker has two paths to exploit these vulnerabilities. Either the attacker creates their own access request (using the IP spoofing vulnerability to craft a convincing spoofed request), then polls their own request ID until an administrator approves it, receiving the JWT token; or the attacker passively monitors the WebSocket stream to discover request IDs from legitimate devices, then polls those IDs and steals the JWT tokens when administrators approve them, hijacking legitimate device credentials. Both paths require zero authentication and enable complete authentication bypass. Version 2.19.0 fixes the underlying issues.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-01-01
Last Modified
2026-01-06
Generated
2026-05-27
AI Q&A
2026-01-01
EPSS Evaluated
2026-05-25
NVD
CVE-2025-68620
EUVD
EUVD-2025-206136
Affected Vendors & Products
Showing 5 associated CPEs
Vendor Product Version / Range
signalk signal_k_server to 2.19.0 (exc)
signalk signal_k_server 2.19.0
signalk signal_k_server 2.19.0
signalk signal_k_server 2.19.0
signalk signal_k_server 2.19.0
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-288 The product requires authentication, but the product has an alternate path or channel that does not require authentication.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in Signal K Server (versions prior to 2.19.0) allows unauthenticated attackers to steal JWT authentication tokens by exploiting two chained issues: first, unauthenticated WebSocket request enumeration where the server sends cached access request events to any WebSocket client without verifying authorization; second, unauthenticated token polling where the access request status endpoint returns the full request state including the JWT token in plaintext once approved, without requiring authentication. Attackers can either create their own access requests and poll for approval or passively monitor legitimate requests to steal tokens, resulting in a complete authentication bypass. [1]


How can this vulnerability impact me? :

An attacker exploiting this vulnerability can obtain any JWT token issued by the server without authentication. This allows them to gain full privileged access, including administrative rights, by tricking administrators into approving access requests or hijacking legitimate device credentials. Consequently, attackers can access all protected endpoints, perform actions like package installation, and fully compromise the SignalK server environment. [1]


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring WebSocket connections to the SignalK server's `/signalk/v1/stream` endpoint with the `serverevents=all` query parameter to see if unauthorized clients receive `ACCESS_REQUEST` events. Additionally, repeated unauthenticated polling of the REST endpoint `/signalk/v1/access/requests/:id` can indicate exploitation attempts. A practical detection method includes using a WebSocket client or script to connect and observe if cached server events including `ACCESS_REQUEST` events are sent without authentication. For example, using a WebSocket client or a Python script to connect to `ws://<server>/signalk/v1/stream?serverevents=all` and monitoring for `ACCESS_REQUEST` events. Also, monitoring HTTP requests to `/signalk/v1/access/requests/:id` without authentication can help detect polling attempts. Specific commands would depend on your environment, but using tools like `websocat` or custom scripts to connect and observe the WebSocket stream, and network monitoring tools to detect unauthenticated REST polling, are recommended. [1]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include upgrading the SignalK server to version 2.19.0 or later, which fixes the vulnerability. Additionally, enforce strict authentication on all WebSocket channels, restrict the `serverevents=all` parameter to authenticated admin users only, and prevent unauthenticated or readonly users from receiving any server events, especially `ACCESS_REQUEST` events. Ensure that access request details are only accessible to authenticated administrators, and implement client verification so only the original requester can retrieve their token. Consider delivering tokens through a separate secure channel rather than via the polling endpoint. If upgrading immediately is not possible, disable the `allow_readonly` setting to prevent unauthenticated readonly access. [1]


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability allows unauthenticated attackers to steal JWT authentication tokens, leading to a total authentication bypass and potential unauthorized access to sensitive data and system functions. Such unauthorized access and data exposure can result in non-compliance with common standards and regulations like GDPR and HIPAA, which require strict access controls and protection of sensitive information. Therefore, exploitation of this vulnerability could lead to violations of these regulations due to compromised confidentiality and integrity of protected data. [1]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart