Signal K: 558 Title Matches, 1,085 Body Matches, and a Path Traversal With a Visibility Condition

Signal K, an open data standard for marine and vessel data networks, was observed in a ZoomEye count-only scan on November 7, 2026. The scan reported zero instances where app=Signal K and title=Signal K were found, but 1,085 instances where http.body contained "Signal K". This led to the publication of advisory GHSA-4xm8-rg9h-jhq2, detailing a path traversal vulnerability in the Signal K v2 resources and applicationData APIs.

The vulnerability arises because the resource identifier is passed to FileStore.getResource() without validation, potentially allowing encoded traversal outside the storage directory. If this is exploited, attackers could read the security.json file, which contains the JWT signing secret, user password hashes, and enough information to forge an admin token. Additionally, attackers could execute commands through the provider configuration.

The affected packages are @signalk/resources-provider 1.0.0 through 1.5.2 and signalk-server 2.0.0 through 2.33.x, with fixed versions 1.5.3 and 2.34.0. The advisory notes that default deployments with allow_readonly=false allow anonymous users to access the resources API, but a readonly user token can also reach the vulnerable path.

The advisory emphasizes that the title and body counts are observations from a single query window, and do not indicate whether a listed page belongs to a specific vessel, marina, developer, or documentation site. Therefore, these counts alone do not provide a complete picture of the vulnerability's scope.

To mitigate the risk, security teams should locate Signal K servers within their marine or vessel network inventory, verify the package version through the application runtime, examine allow_readonly settings, review reverse-proxy rules, and ensure signalk-server is not reachable from untrusted networks. Upgrading to the fixed releases and reviewing provider configuration are also recommended.

If the server is internet-facing, access logs should be inspected for signs of traversal in resource paths, requests to security.json, and authenticated actions lacking normal login. Finally, the JWT signing secret and user passwords should be rotated if the configuration file may have been compromised.