Skip to content

← Public intelligence

npm package

@evomap/evolver

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 8.1npmAmendedPublished

    @evomap/evolver's validator sandbox allowlist permits npm/npx, yielding RCE from Hub-delivered validation tasks via lifecycle scripts

    GHSA-jxh8-jh77-xh6g

    Affected
    • npm @evomap/evolver <= 1.70.0-beta.4
    Fixed in
    1.70.0-beta.5· Vendor fix available
    Issue
    The validator-mode sandbox executor (src/gep/validator/sandboxExecutor.js) places npm and npx in its hard executable allowlist. Because npm install <pkg and npx -y -p <pkg <bin execute arbitrary code by design (preinstall/install/postinstall lifecycle scripts and remote-package bin entries), and because validator nodes consume validationcommands strings from unsigned Hub responses with no per-response signature check, an attacker who controls or MITMs the Hub achieves automatic remote code execution on every validator node within one daemon poll (default 60s). Details End-to-end chain: 1. src/gep/validator/index.js:71-87 — fetchValidationTasks() POSTs to <hub/a2a/fetch and reads validationtasks from the JSON response. The outbound request is signed via buildHubHeaders(), but the Hub's response is parsed directly with await res.json() and no signature is verified on data.payload. 2. src/gep/validator/index.js:98-108 — validateOneTask() extracts task.validationcommands (an…

    Recommended action: Upgrade to 1.70.0-beta.5 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  2. Medium, CVSS 6.2npmAmendedPublished

    @evomap/evolver has an unbounded request body in proxy /asset/submit that causes persistent disk-exhaustion DoS

    GHSA-7xp7-m392-h92c

    Affected
    • npm @evomap/evolver <= 1.70.0-beta.4
    Fixed in
    1.70.0-beta.5· Vendor fix available
    Issue
    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): 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…

    Recommended action: Upgrade to 1.70.0-beta.5 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  3. High, CVSS 8.8npmAmendedPublished

    @evomap/evolver: Path Traversal in evolver fetch default-branch safeId allows Hub-controlled overwrite of project files (RCE)

    GHSA-cfcj-hqpf-hccf

    Affected
    • npm @evomap/evolver <= 1.70.0-beta.4
    Fixed in
    1.70.0-beta.5· Vendor fix available
    Issue
    The evolver fetch subcommand in index.js writes Hub-supplied bundledfiles[] into a directory derived from a Hub-supplied skillid. When --out is not used, the path-sanitizing regex permits . characters, allowing a skillid of .. to escape the skills/ subdirectory and resolve to the user's current working directory. Combined with the file-extension allow-list (which includes .js/.json/.sh/.py/.md), this lets a malicious Hub overwrite the victim's index.js, package.json, or other files in cwd, achieving remote code execution on the next invocation of the evolver. Details The vulnerable code is in the fetch command handler: Three problems compose: 1. The regex allow-list permits . — [^a-zA-Z0-9\-\.] only strips characters outside this set, so the literal dot is preserved. A skillid of .. (verified: '..'.replace(/[^a-zA-Z0-9\-\.]/g,'') === '..') survives sanitization. 2. path.join collapses .. traversal — path.join('.', 'skills', '..') evaluates to '.' (the cwd), so outDir is now…

    Recommended action: Upgrade to 1.70.0-beta.5 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  4. High, CVSS 8.1npmAmendedPublished

    Evolver: Path Traversal via --out flag in fetch command allows Arbitrary File Write

    CVE-2026-42075 · GHSA-r466-rxw4-3j9j

    Affected
    • npm @evomap/evolver < 1.69.3
    Fixed in
    1.69.3· Vendor fix available
    Issue
    A path traversal vulnerability in the skill download (fetch) command allows attackers to write files to arbitrary locations on the filesystem. The --out= flag accepts user-provided paths without validation, enabling directory traversal attacks that can overwrite critical system files or create files in sensitive locations. Details The vulnerability exists in index.js at lines 752-767: The outFlag.slice('--out='.length) extracts the user-provided path without any sanitization or validation. An attacker can provide paths like ../../../etc/cron.d to write files outside the intended directory. Note: The safeId variable is sanitized via inline replacement (replace(/[^a-zA-Z0-9\-\.]/g, '')), but this sanitization only applies to the default path, not to the user-provided --out= path. PoC Prerequisites: - Node.js installed - Access to the evolver application Steps to reproduce: 1. Create a test file demonstrating the vulnerability: 2. Run the test: Expected output: Actual exploit…

    Recommended action: Upgrade to 1.69.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  5. Critical, CVSS 9.8npmAmendedPublished

    Evolver: Command Injection via execSync in _extractLLM() function allows Remote Code Execution

    CVE-2026-42076 · GHSA-j5w5-568x-rq53

    Affected
    • npm @evomap/evolver < 1.69.3
    Fixed in
    1.69.3· Vendor fix available
    Issue
    A command injection vulnerability in the extractLLM() function allows attackers to execute arbitrary shell commands on the server. The function constructs a curl command using string concatenation and passes it to execSync() without proper sanitization, enabling remote code execution when the corpus parameter contains shell metacharacters. Details The vulnerability exists in src/gep/signals.js at lines 260-274: The corpus parameter is derived from user input (via userSnippet in extractSignals() function) and flows through to extractLLM() where it becomes part of the shell command. While JSON.stringify() escapes some characters, it does not prevent shell command substitution via $(...) syntax when the resulting string is passed to execSync(). The extractSignals() function is called from the main evolution loop in src/gep/evolver.js, which processes user snippets and session transcripts. PoC Prerequisites: - Node.js installed - Access to the evolver application Steps to…

    Recommended action: Upgrade to 1.69.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  6. Medium, CVSS 5.2npmAmendedPublished

    Evolver has Prototype Pollution via Object.assign() in its mailbox store operations

    CVE-2026-42077 · GHSA-2cjr-5v3h-v2w4

    Affected
    • npm @evomap/evolver < 1.69.3
    Fixed in
    1.69.3· Vendor fix available
    Issue
    A prototype pollution vulnerability in the mailbox store module allows attackers to modify the behavior of all JavaScript objects by injecting malicious properties into Object.prototype. The vulnerability exists in the applyUpdate() and updateRecord() functions which use Object.assign() to merge user-controlled data without filtering dangerous keys like proto, constructor, or prototype. Details The vulnerability exists in src/proxy/mailbox/store.js at lines 123 and 145: The vulnerability can be triggered when an attacker has the ability to write to the messages.jsonl file (used for mailbox persistence). By crafting a malicious JSONL entry with proto as a field key, the attacker can pollute the prototype of all objects. The data flows from: 1. messages.jsonl file → 2. readLines() function (line 47) → 3. rebuildIndex() (line 113) → applyUpdate() (line 121) → 4. Object.assign() pollutes prototype PoC Prerequisites: - Node.js installed - Access to write to the mailbox messages…

    Recommended action: Upgrade to 1.69.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →