GHSA-jxh8-jh77-xh6g

Summary

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 validation_commands 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 validation_tasks 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.validation_commands (an array of attacker-controlled strings) and passes it straight to runInSandbox(commands, {}). No call to policyCheck.isValidationCommandAllowed() happens on this path. The author's own comment at sandboxExecutor.js:41-42 acknowledges this gap: "This closes the gap where validation_commands go straight from Hub to runInSandbox without passing through policyCheck.isValidationCommandAllowed()."

3. src/gep/validator/sandboxExecutor.js:172-218 — runSingleCommand calls parseCommand(cmd), then checks ALLOWED_EXECUTABLES.has(parsed.executable):

   // sandboxExecutor.js:35
   const ALLOWED_EXECUTABLES = new Set(['node', 'npm', 'npx']);
   

   parseCommand only rejects shell metacharacters (| & ; > < \ $) and unbalanced quotes. A string like npm install /tmp/evil-pkg --no-audit --no-fundcontains none of those and parses cleanly into{ executable: 'npm', args: [...] }`.

4. sandboxExecutor.js:54-66 —...