Rojo's "rojo serve" HTTP API (default port 34872) has no Host/Origin header validation, making it vulnerable to DNS rebinding. A malicious webpage can read all project source, write malicious code to files on disk, and launch local programs via opener::open() with no user interaction beyond visiting the page.

Affected: crates.io: rojo

Rojo's `rojo serve` command starts an unauthenticated HTTP API on localhost (default port 34872) with no `Host` or `Origin` header validation. While direct cross-origin `fetch()` requests from a malicious website are blocked by the browser's default CORS policy, an attacker can use DNS rebinding to bypass this restriction entirely. The serve API is a two-way sync protocol. Once a DNS rebind is established, a malicious webpage visited by a developer running `rojo serve` can, without any further user interaction: - **Read the full project source:** `GET /api/rojo` returns the session ID, root instance ID, and project name. `GET /api/read/{id}` enumerates the complete instance tree including all script contents, exposing proprietary game logic, configuration, and any secrets embedded in source files. - **Write to project files on disk:** `POST /api/write` pushes changes back through Rojo's sync pipeline, allowing an attacker to inject arbitrary Lua into the developer's project. If the developer then publishes their game, the injected code executes on every player's client — a supply chain attack vector. - **Launch local programs:** `POST /api/open/{id}` calls the OS-level `opener::open()` function, which invokes the platform's default handler (`open` on macOS, `xdg-open` on Linux, `start` on Windows) for the target file. Exploitation requires only that `rojo serve` is running (the standard Roblox development workflow) and that the developer visits an att…