Vulnerabilities

Vulnerability · GHSA-4xm8-rg9h-jhq2

Signal K resources API path traversal can disclose the JWT signing secret and enable remote code execution

Published Oct 30, 2026 · catalog updated Oct 30, 2026 · Signal K resources API

Last checked Oct 31, 2026. A connected source was read within the last 7 days.

Open the advisory

Exploitation likelihood is not on this record for GHSA-4xm8-rg9h-jhq2. A missing EPSS score is not a low risk. Compare Signal K resources API with the linked advisory before you change production.

Severity

Critical9.8

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

Awaiting synchronization with FIRST

Remediation

Advisory link

Affected products

npm @signalk/resources-provider · npm signalk-server

### 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 /security.json discloses the JWT signing secret, enabling admin token forgery and remote code execution. ### Details ## Description The v2 REST resources API passes to without validation. builds the file path with followed by + , so a -encoded multi-level traversal ( ) escapes the resource storage directory and returns any JSON file on the server (source: , ). Because the JWT signing secret is stored in plaintext in (generated at , persisted via at ), an unauthenticated attacker on deployments with (a supported, UI-toggleable configuration granting anonymous read access) can: 1. **Read ** — disclosing the JWT signing secret (512-hex) and user password hashes. 2. **Forge an admin JWT** — HS256-sign with the disclosed secret; accepted by ( ) and all admin-protected endpoints ( , , applied at ). 3. **Gain remote code execution** — (admin) accepts a provider of type ; executes it via at creation time. The provider persists to and survives restarts. On default deployments ( ), step 1 returns 401 to anonymous users but succeeds with any readonly user token. ## Suggested fixes 1. Validate against a strict whitelist (for example, UUID format) in before any storage call, including PUT/DELETE. 2. In , canonicalise with and reject results outside . 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 ( ) behind an explicit opt-in. ### Proof of concept Fully local testbed. Start the server, enable , then run: Reproduction verified independently on master (Node 22 / macOS), including restart persistence. PoC artifacts are available on request. ### Impact Unauthenticated access (with ) leads to full compromise of the server process: arbitrary JSON file read, admin takeover, arbit