CVE-2026-40608
Out-of-Memory Crash via Unrestricted POST in Next AI Draw.io
Publication date: 2026-04-21
Last updated on: 2026-04-27
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| dayuanjiang | next_ai_draw.io | to 0.4.15 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability described in CVE-2026-40608 causes a denial-of-service (DoS) condition by crashing the MCP server due to uncontrolled memory consumption from large POST request bodies. It impacts availability by disrupting active user sessions and automated workflows.
However, there is no indication in the provided information that this vulnerability affects confidentiality or integrity of data, nor does it mention any direct impact on personal data or protected health information.
Therefore, based on the available data, this vulnerability primarily affects system availability and does not directly compromise compliance with standards like GDPR or HIPAA, which focus heavily on data confidentiality and integrity.
Can you explain this vulnerability to me?
CVE-2026-40608 is a denial-of-service (DoS) vulnerability in the Next AI Draw.io MCP server, specifically in three POST HTTP handlers (/api/state, /api/restore, and /api/history-svg). These handlers accumulate the entire request body into a JavaScript string without any size limitation.
Because Node.js buffers the entire payload in the V8 heap memory, sending a sufficiently large request body (for example, 500 MiB or more) exhausts the process heap memory, causing an Out-of-Memory (OOM) error that crashes the MCP server process.
The embedded HTTP server listens only on localhost, so exploitation requires local access, but any process on the same machine can reach the vulnerable endpoints.
How can this vulnerability impact me? :
This vulnerability can cause the MCP server process to crash due to memory exhaustion, resulting in a denial-of-service condition.
The crash disrupts active user diagram sessions and causes loss of any unsaved diagram state.
In automated workflows, a crashed MCP server can block the entire pipeline, impacting availability and productivity.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by sending a large POST request to one of the vulnerable endpoints (/api/state, /api/restore, or /api/history-svg) on the MCP server running on localhost port 6002.
A proof-of-concept script demonstrates sending a 10 MiB payload to /api/state and checks if the server returns HTTP 413 (Payload Too Large). If the server does not return HTTP 413, it indicates the absence of body size limits and vulnerability to memory exhaustion.
Example command using curl to test the vulnerability by sending a large payload (adjust size as needed):
- Generate a large file (e.g., 10MB): dd if=/dev/zero of=large_payload.bin bs=1M count=10
- Send POST request to the vulnerable endpoint: curl -X POST --data-binary @large_payload.bin http://localhost:6002/api/state -v
If the server crashes or does not respond with HTTP 413, the vulnerability is present.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves implementing a maximum allowed request body size limit in the vulnerable POST handlers (/api/state, /api/restore, and /api/history-svg) to prevent memory exhaustion.
Specifically, introduce a function that reads the request body in chunks while tracking the cumulative size, and if the size exceeds a defined limit (e.g., 10 MiB), respond with HTTP 413 (Payload Too Large) and terminate the connection.
Upgrade the MCP server package to version 0.1.19 or later, which includes the fix that enforces a 10MB request body size limit on these endpoints.
If upgrading immediately is not possible, consider restricting local access to the MCP server port (6002) to trusted processes only, as exploitation requires local access.