Attacking The Developer Environment Through Drive-by Localhost Attacks

The talk starts from a small set of cross-site scripting and CSRF issues in a Java feature-toggle framework. The speaker noticed that the toggle console could evaluate JavaScript on the server, which made the findings more serious if an attacker could reach the endpoint. Browsers still send "simple" cross-origin requests to localhost even though the page cannot read the replies, so a malicious site can trigger local services without the user noticing.

The middle of the talk walks through several examples. A toggle endpoint could be reached this way and used to run code. Spring Boot actuators from an end-of-life version, combined with Spring Cloud, allowed properties to be changed and the application restarted, and redirecting an H2 in-memory database URL led to code execution through H2's alias feature. A Quarkus developer UI accepted similar configuration edits from an unmodified quick-start project. An MLflow server could be pointed at an attacker-controlled storage location to exfiltrate training data or, through pickle deserialisation, run code. Finally, an MCP server using server-sent events did not check session IDs or content types, so a browser could make it write a file on the developer's disk.

The talk closes with the vendor responses, which included fixes from Red Hat, Spring and Anthropic. Browser work such as Private Network Access was pulled back after breaking sites, and a permission prompt for local network access is the current direction, with uneven adoption. The practical takeaway is that developer tools bound to localhost should still require authentication and strict content-type checks, since the exposure persists.