CDP Tools MCP Server

In the server's implementation (`build/utils/modal-detector.js:69`): Evaluating a runtime value as code (rather than a fixed literal) executes whatever reaches it — a direct RCE primitive, and almost never necessary in legitimate code. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: xt-line no-eval eval(isBasicVisibleFn); // eslint-disable-next-line no-eval eval(isBlockingPosit

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/utils/modal-detector.js

The implementation both builds shell commands out of runtime values (`build/server-manager.js`) and evaluates runtime values as code (`build/utils/modal-detector.js`). Each is a separate arbitrary-execution primitive; a server exposing both gives anything that reaches either one a direct path to running attacker-chosen code. These two sinks are in different files — confirm whether they are actually connected, or are unrelated code paths (e.g. a vendored bundle plus a CLI wrapper).

Fix: Remove the dynamic eval, and pass command arguments as an argv array instead of building a shell string. If both are genuinely required, constrain and validate every value that can reach them.

Location: server implementation

In the server's implementation (`build/utils/modal-detector.js:69`): Evaluating strings as code is the most direct RCE primitive; if any tool input reaches it, the server executes attacker-chosen code. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: xt-line no-eval eval(isBasicVisibleFn); // eslint-disable-next-line no-eval eval(isBlockingPosit

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/utils/modal-detector.js

In the server's implementation (`build/chrome-launcher.js:5`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: import { spawn } from 'child_process'; import * as os from 'os'; import * as path from 'path'; import * as net from 'ne

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/chrome-launcher.js

In the server's implementation (`build/runners/docker-compose-runner.js:5`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: ort { spawnSync } from 'child_process'; import * as path from 'path'; import * as fs from 'fs'; import { debugLog } from

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/runners/docker-compose-runner.js

In the server's implementation (`build/runners/docker-runner.js:5`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: ort { spawnSync } from 'child_process'; import { debugLog } from '../debug-logger.js'; /** * Check if Docker is availab

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/runners/docker-runner.js

In the server's implementation (`build/runners/native-runner.js:5`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: import { spawn } from 'child_process'; import * as fs from 'fs'; import * as path from 'path'; import { debugLog } from

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/runners/native-runner.js

In the server's implementation (`build/server-claims.js:49`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: { execFileSync } from 'child_process'; import { atomicWriteFile } from './atomic-write.js'; import { getOutputPath } fr

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/server-claims.js

In the server's implementation (`build/server-manager.js:786`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: nst { exec } = require('child_process'); exec(`lsof -ti :${port}`, (error, stdout) => { if (

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/server-manager.js

In the server's implementation (`build/supervisor/child-manager.js:16`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: import { spawn } from 'child_process'; export class ChildManager { opts; child = null; onExitCallback = nul

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/supervisor/child-manager.js

In the server's implementation (`build/supervisor/client-watcher.js:30`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: { execFileSync } from 'child_process'; /** * Package managers and shells that are only ever launch plumbing, never the

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/supervisor/client-watcher.js

In the server's implementation (`build/tools/screenshot-tools.js:11`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: import { spawn } from 'child_process'; import { resolveSelector, isExtendedSelector, cleanupResolvedSelector } from '..

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/tools/screenshot-tools.js

In the server's implementation (`build/server-manager.js:787`): A shell/process command assembled from concatenated or interpolated values is command injection when any part is attacker-influenced — the OWASP canonical RCE flow. Verify what reaches the interpolated value. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: _process'); exec(`lsof -ti :${port}`, (error, stdout) => { if (error || !stdout.trim()) {

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/server-manager.js

In the server's implementation (`build/helpers/parser-plugins.js:51`): Loading a module chosen at runtime (from a variable) can pull in and run attacker-influenced code paths. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: ; const mod = await import(url); const plugin = (mod.default ?? mod); if (!plugin || typeof plugin.extract !

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/helpers/parser-plugins.js

In a packaging/dev/install script (shipped, but not the server runtime) (`build/tools/storage-tools.test.js:317`): Evaluating strings as code is the most direct RCE primitive; if any tool input reaches it, the server executes attacker-chosen code. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: const rebuilt = new Function('return (' + describeStructuredValue.toString() + ')')(); const value = { w

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server build/tools/storage-tools.test.js