While reading through src/runtime/server/services/parallel/worker-pool.ts:213 and worker.ts:22 (also apis/parallel-compute.api.ts:187,233) I noticed the worker execution reconstructs code via:
new Function("input", "return (" + functionBody + ")(input)")in an unsandboxed worker_threads context (eval: true). Today compute is always a dev-authored closure at the call sites in this repo, so it's not reachable from client/network input in shipped code — but nothing stops a consumer from deriving compute from a network payload down the line, and if that happens it's instant RCE in the worker.
I'd suggest forbidding dynamic function bodies and requiring worker tasks to import a named, statically-registered task module instead of stringifying closures.
While reading through
src/runtime/server/services/parallel/worker-pool.ts:213andworker.ts:22(alsoapis/parallel-compute.api.ts:187,233) I noticed the worker execution reconstructs code via:in an unsandboxed
worker_threadscontext (eval: true). Todaycomputeis always a dev-authored closure at the call sites in this repo, so it's not reachable from client/network input in shipped code — but nothing stops a consumer from derivingcomputefrom a network payload down the line, and if that happens it's instant RCE in the worker.I'd suggest forbidding dynamic function bodies and requiring worker tasks to
importa named, statically-registered task module instead of stringifying closures.