GHSA-7xp7-m392-h92c @evomap/evolver has an unbounded request body in proxy /asset/submit that causes persistent disk-exhaustion DoS
SummaryThe 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`):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`):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`):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`):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.PoCRun from the repo root:Verified output:Live exploitation against a running daemon (default port 19820):`<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 FixCap body size in `parseBody()` (`src/proxy/server/http.js`):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.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()`.(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.
CVSS v3.1 score: 6.2