When localhost becomes a remote attack surface.

Loopback services are easy to treat as internal. They are not. A browser can often reach 127.0.0.1, and WebSockets make the application—not the browser—responsible for deciding which origins may connect.

The first primitive: a writable local socket

The desktop application started a WebSocket server on a random loopback port whenever its built-in script editor was open. The port was unpredictable, but the protocol was not. A short scan could identify the right listener from its response behavior.

The server accepted connections without a session secret and did not validate the browser's Origin header. Once connected, a page could call the same read and write operations used by the application's own editor.

// Simplified connection logic
socket.on("message", message => {
  dispatchEditorCommand(message); // no token, no Origin check
});

The write operation accepted a project-relative path. It was intended to save source files in the open project, but it also allowed paths that reached the project's plugin directory. The attacker never needed to know where the project lived on disk.

A random localhost port is obscurity, not authentication. If a web page can discover it in seconds, the port number is not a security boundary.

The second primitive: plugins that load from the project

Projects could contain plugins. When a project was opened or reloaded, the application discovered plugin folders automatically and read a small manifest describing the plugin and the capabilities it wanted.

The attacker-controlled page used the local editor socket to place two files inside the project: a plugin manifest and a script. The manifest requested filesystem and process-execution capabilities; the script used the granted process capability to run a host command.

// Deliberately generic pseudocode
writeProjectFile("../Plugins/Project/manifest.json", manifest);
writeProjectFile("../Plugins/Project/main.js", payload);

// On the next project load
Process.spawnSync("benign-proof-command");

Putting the chain together

1. The application is open with a project and its script editor active—a normal working state.
2. The victim visits an attacker-controlled HTTP page.
3. The page finds the loopback WebSocket and writes a plugin into the already-open project. No prompt appears.
4. The project is saved, reopened, or reloaded during ordinary work.
5. A single dialog asks whether to trust and load the project. Once approved, the planted plugin executes immediately as the victim user.

The dialog displayed the attacker-chosen plugin name and requested capability labels, but it did not explain that the plugin had just appeared, where it came from, or whether it was signed. A generic name made the prompt look like routine project setup.

The browser was mitigation by accident

Public websites could reach the local service in some browsers while others applied stricter private-network controls. Pages delivered from a local network remained viable more broadly. A malicious project or any local process skipped the browser restriction entirely.

That variance did not change the application defect. The service itself had no authentication and no origin policy. Browser behavior merely changed which delivery routes were convenient.

Impact

After the one approval, the plugin ran with the desktop user's privileges. A real attacker could read source projects and credentials, execute additional tools, establish persistence, or exfiltrate local files.

The important part was not any one API. It was the composition:

• a browser-reachable local control plane;
• an unauthenticated project file-write primitive;
• automatic discovery of project-scoped executable code; and
• a consent prompt with too little provenance information.

How to fix the class, not only the path

Canonicalizing file paths is necessary, but it does not repair the trust boundary. The local service should require an unguessable per-session secret, validate Origin and Host, and bind each command to the project and editor session that created the token.

Project plugins also need provenance. Newly added or unsigned plugins should be distinguished from known project content, and host-reaching capabilities should not be granted to silently introduced code through a single routine-looking action.

Closing thought

Each individual feature was understandable: a local editor socket, project plugins, and a permissions dialog. The vulnerability existed in the seams between them. That is where desktop application testing earns its keep.