{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.24.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "signalk-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.25.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41893"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T20:52:06Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe 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 \u2014 sending `{login: {username, password}}` messages over an established WebSocket connection \u2014 calls `app.securityStrategy.login()` directly without any rate limiting.\n\nAn 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).\n\n## Details\n\n**Vulnerable code:** `src/interfaces/ws.ts`, function `processLoginRequest` (lines 753-780)\n\nThe function directly calls `app.securityStrategy.login(msg.login.username, msg.login.password)` with no throttling or attempt tracking.\n\n**Rate-limited HTTP path for comparison:** `src/tokensecurity.ts` lines 609-617 apply `loginLimiter` middleware to the HTTP login routes at line 637.\n\n## Steps to Reproduce\n\n1. Start Signal K server with security enabled\n2. Open a WebSocket connection to `ws://server:3000/signalk/v1/stream?subscribe=none`\n3. Wait for the hello message\n4. Send login attempts in rapid succession:\n   ```json\n   {\"requestId\": \"1\", \"login\": {\"username\": \"admin\", \"password\": \"guess1\"}}\n   {\"requestId\": \"2\", \"login\": {\"username\": \"admin\", \"password\": \"guess2\"}}\n   ```\n5. Observe that all attempts are processed without any 429 response or throttling\n6. For comparison, send 100+ HTTP POST requests to `/signalk/v1/auth/login` \u2014 the 101st returns 429\n\nA POC script is available that demonstrates both the HTTP rate limiting working correctly and the WebSocket path accepting unlimited attempts.\n\n## Impact\n\n- Credential brute-forcing via the WebSocket protocol at ~20 attempts/sec (bcrypt-limited)\n- Complete bypass of the HTTP rate limiting defense\n- A single WebSocket connection is sufficient for unlimited attempts\n- With multiple parallel connections, throughput multiplies\n- A 10,000-word dictionary attack completes in ~8 minutes over a single connection\n\nSignal K servers are commonly deployed on boat networks where they may be accessible to other devices on the same LAN.\n\n## CWE\n\nCWE-307: Improper Restriction of Excessive Authentication Attempts\n\n## Suggested Fix\n\nTrack 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.\n\n## Context\n\nFound while building an open source maritime security scanner. Verified on v2.24.0 (current master).\n\nDiscovered by Mark Curphey",
  "id": "GHSA-vmfm-ch9h-5c7g",
  "modified": "2026-05-04T20:52:06Z",
  "published": "2026-05-04T20:52:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SignalK/signalk-server/security/advisories/GHSA-vmfm-ch9h-5c7g"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SignalK/signalk-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Signal K Server\u0027s WebSocket Login Endpoint Lacks Rate Limiting (Credential Brute-Force)"
}