pastilhasandClaude Opus 5
2873948f98
A Member account could open a terminal. Demonstrated, not inferred: on 2026-08-06 a token for dingoshf@gmail.com (role Member) was refused GET /api/tasks with 403 and, in the same minute, opened /api/tasks/pipeline/ws with 101 Switching Protocols. The account backstop lives in originScopeMiddleware, which is a Hono middleware. Websocket upgrades never reach Hono: Bun's route table in server.tsx matches '/api/terminal/ws' and its siblings before the '/api/*' entry that hands off, so NON_OWNER_PATHS was enforced on HTTP and nowhere else. upgradeWs verified the token and the blacklist, then upgraded — it proved WHO was calling and never asked what they could reach. None of the handlers behind it checked either; terminal, chat and desktop have no authorisation code at all. What was reachable with any valid token: a shell as the owner in the owner's home, the agent with --dangerously-skip-permissions, arbitrary script execution through task-runner and pipeline, and the owner's physical screen and keyboard over the VNC mirror. upgradeWs now refuses any provider a non-owner has no business on. cliamp and cliamp-audio stay open to them — those are the socket half of /api/music, which is what a music account exists for. An unrecognised provider denies. NON_OWNER_WS_PROVIDERS is declared beside NON_OWNER_PATHS on purpose. They are one rule at two doors, and the whole failure was that only one door had it; splitting them across files is how that happens again. The vault socket was already gated — it verifies isSuperAdmin in `open` and closes 4001 — so upgradeWs was the only gap. Not yet verified against the running server: platform TS does not hot-reload, so the 101 above still reproduces until `pm2 restart officer`. The provider table was checked in isolation: the five execution providers and an unknown name all deny, cliamp and cliamp-audio allow. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>