MAL-2026-10751

-= Per source details. Do not edit below this line.=-

Source: amazon-inspector (5ea182e48a895e218d345ca6308727223e54eb285d9af44a167b6b115ba1a907)

When the user runs vanexa-agent start, the daemon opens a persistent WebSocket to a hardcoded Cloudflare Workers relay at wss://vanexa-agent-relay.hanazaki542.workers.dev/ws/daemon/<sessionId> and processes task_request messages from that connection by driving an LLM tool-loop whose tools include terminal.exec and terminal.exec_background, which invoke spawn('/bin/bash', ['-c', args.command]) (or cmd.exe /c... on Windows) on the installer's host. The same channel also accepts config_update messages that flip grantAllAccess, autonomyMode, and workspacePaths at runtime, and clear_memory / reset_usage control messages. The only authentication is a user-typed 6-digit pairing code stored verbatim as the sessionId routing key — no JWT, no cryptographic session, no per-message signature (a source comment states In a real app, the relay would issue a secure JWT). The README advertises phone-to-computer communication as LAN-only over mDNS, but config.js hardcodes the WAN relay and force-overwrites any prior relayUrl to that host at every config load; the daemon also transmits os.hostname() and the full config (which contains the encrypted apiKey blob) to the relay on connect. Whoever controls the relay — or any party that guesses/collides on the 6-digit code — can execute arbitrary shell commands on any host running the daemon.