Signal K Path Traversal: JWT Secret Leak and RCE Fix

A critical vulnerability in Signal K Server, a Node.js application distributed through npm, lets a user read files outside the intended storage folder through the resources API. According to the GitHub security advisory, one of those files holds the secret used to sign login tokens, and reading it can lead to administrator takeover and command execution on the host.

If you run signalk-server anywhere reachable from other devices, such as a local network, a VPS or a port-forwarded home connection, check your version now. The fix is in signalk-server 2.34.0 and @signalk/resources-provider 1.5.3. At the time of writing, the research for this story consists of one primary source, the advisory itself, and no CVE identifier was listed in it.

What happened

The advisory was published on October 18, 2026 in the SignalK/signalk-server repository and updated on October 30, 2026. It is rated critical. It describes a path traversal in the Signal K resources and applicationData APIs. An unauthenticated or low-privileged user can read, write and delete files outside the storage root.

The most serious chain starts with reading the server's security configuration file. That file stores the JWT signing secret in plaintext, so anyone who reads it can mint their own tokens.

Technical details

The weakness: path traversal

Path traversal happens when an application builds a file path from user input without checking that the result stays inside an intended folder. Sequences that mean "go up one directory" can then walk out of that folder and reach other files on the server.

Per the advisory, the v2 resources endpoint takes a resource identifier from the URL and passes it to the file store without validation. The file store joins it onto the resource directory and reads and parses the file. Encoded multi-level traversal sequences can escape the storage directory and return any JSON file on the server. The advisory also says write and delete operations are affected.

From file read to code execution

The advisory describes three stages, which we summarize here without reproducing the proof of concept:

• Read the security configuration file, which discloses the JWT signing secret and user password hashes.
• Use the secret to forge an administrator token, which the server accepts on admin-protected endpoints.
• As admin, add a data provider of type Execute, which runs a shell command when it is created. The provider is saved to the settings file and survives restarts.

The advisory reports that the reproduction was verified independently on the master branch, including persistence after a restart. The impact it describes is full compromise of the server process: arbitrary JSON file read, admin takeover, command execution with the server's privileges and re-execution after restart.

Who is affected

The advisory lists these affected and patched versions:

The advisory's impact section also states that all signalk-server releases and all published versions of the bundled or standalone resources-provider prior to 2.34.0 are affected. That differs slightly from the version ranges above, so treat anything below the fixed versions as vulnerable and do not rely on a lower bound.

How exposure depends on configuration

• Servers with allow_readonly set to true (a supported setting that grants anonymous read access) can be attacked without any login, according to the advisory.
• On default deployments where allow_readonly is false, the first step returns 401 to anonymous users but still works with any readonly user token. A low-privilege account is therefore enough.
• Servers reachable only from a trusted local network are less exposed, but any device or person on that network, or any account with a readonly token, becomes a potential starting point.

The sources do not say whether this is being exploited in the wild, and no exploitation reports are cited. A proof of concept is described in the advisory, so you should assume that attackers can reproduce it.

How to check your exposure

1. Find your installed signalk-server version, in the admin UI or by running npm list for the package on the host.
2. Check any standalone @signalk/resources-provider install against the 1.5.3 fixed version.
3. Open the server's security settings and see whether anonymous read access (allow_readonly) is enabled.
4. Check whether the server's port is reachable from the internet or from untrusted networks, including through port forwarding or a reverse proxy.
5. Review the configured data providers for any entry of type Execute that you did not create.

What to do now

1. Upgrade signalk-server to 2.34.0 or later, and @signalk/resources-provider to 1.5.3 or later, then restart the service.
2. Treat the JWT signing secret as potentially exposed if the server was reachable by untrusted users before the update. Rotating it invalidates existing tokens, including forged ones. The advisory does not give rotation steps, so check the Signal K documentation for how to do this safely.
3. Reset passwords for all Signal K users if you suspect the configuration file was read, since the advisory says password hashes are in the same file.
4. Remove any unexpected Execute providers and review the settings file, because the advisory says such providers persist across restarts.
5. If you find signs of compromise, assume commands ran with the server's privileges and follow a full incident process. Our guide on what to do when a website is hacked covers the general steps.

Hardening while you patch

• Do not expose the Signal K port directly to the internet. Put it behind a VPN or an authenticated reverse proxy.
• Turn off anonymous read access unless you need it.
• Run the server as an unprivileged user so that command execution has limited reach.
• Restrict who can create accounts and issue readonly tokens.

The advisory also suggests code-level fixes for maintainers: strict identifier validation, canonicalizing paths and rejecting anything outside the storage directory, keeping the signing secret in a separate key file with mode 0600, and gating command-executing provider types behind an explicit opt-in. Whether and how the released fix implements these is not detailed in the research, so rely on the version numbers rather than assuming each measure is in place.

Detection and monitoring

Look in web server or reverse proxy logs for requests to the v2 resources path that contain encoded slashes or repeated parent-directory patterns, and for unexpected requests to the provider creation endpoint. Watch for unfamiliar processes spawned by the Node.js service and for changes to the settings file.

If your Signal K instance sits behind a public hostname, certificate and header monitoring can help you notice unexpected changes to that endpoint, and the free security headers checker shows what the server exposes. Neither fixes this flaw. Only updating does. For background on filtering malicious requests in front of an application, see what a WAF is, and browse more advisories on the Webforta blog.

What is still unconfirmed

• No CVE identifier or CVSS score appears in the research, so none is given here.
• No source reports active exploitation.
• Only one source, the GitHub advisory, covers the issue so far. Details may change as the maintainers and others publish more.

Sources

This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.

• GHSA-4xm8-rg9h-jhq2 - GitHub Advisory Database (github.com, 30 October 2026)

Tags: Signal K, path traversal, JWT, RCE, npm, Node.js