GHSA-7Q9C-HPX7-9CWM: Unauthenticated Remote Shutdown in @typespec/spector Mock Server

The @typespec/spector package (historically part of the Microsoft TypeSpec and CADL ecosystems) is designed as a mock server framework. Its primary use case is in testing suites, allowing developers to execute validation tests against specific HTTP-based API scenarios. Because these environments are ephemeral, Spector exposes several control interfaces under an administrative namespace to facilitate automated teardown and setup lifecycle hooks. One such endpoint is designed to immediately shut down the mock server instance after test execution completes.

This architecture exposes an attack surface when deployed in multi-user environments or accessible networks. The critical shutdown mechanism, mapped to the path /.admin/stop, is implemented as an unauthenticated HTTP POST endpoint. By design, the endpoint allows any client capable of initiating a TCP session with the Spector instance to shut down the server process. This design relies on the assumption that the service runs strictly within an isolated local loopback context.

However, in vulnerable versions (up to and including 0.1.0-alpha.26), the mock server binds to the wildcard network address 0.0.0.0. This binding exposes the endpoint to any physical or virtual network interface on the host machine. If the host machine is connected to a local subnet, a corporate intranet, or is exposed to the public internet, the administrative shutdown capability becomes remotely reachable. Unauthenticated remote network actors can abuse this behavior to trigger immediate process termination, leading to an effective Denial of Service (DoS).

The root cause of this vulnerability involves two distinct architectural flaws: missing authentication on a highly sensitive endpoint, and unsafe network socket binding. The @typespec/spector administrative API provides structural utility routes designed to govern server state. The stop endpoint, configured via AdminUrls.stop (resolving to /.admin/stop), has no middleware layers to enforce authorization or authenticate incoming requests. It does not validate tokens, check for custom request headers, or restrict access via Cross-Origin Resource Sharing (CORS) policies.

The second contributing factor is the default network configuration of the underlying Express framework application. When initiating the HTTP listener, the application calls the listen method on the Express app instance while providing only a port number, omitting the host argument. Within the Node.js net and http modules, failing to provide a host argument causes the operating system to bind the socket to the wildcard address (0.0.0.0 for IPv4 and :: for IPv6).

Because of this wildcard binding, the operating system routes incoming TCP packets targeting the designated port on any network adapter directly to the Spector process. The application acts as an open network listener, meaning that local network isolation is entirely bypassed. Combined with the absence of per-request authentication, any packet arriving over the network that matches the administrative stop path will successfully reach the vulnerable code path and trigger a process shutdown.

A deep inspection of the codebase clarifies the vulnerability mechanics. The administrative routes are registered in the source file packages/spector/src/routes/admin.ts. The implementation of the stop route is shown below:

// packages/spector/src/routes/admin.ts
router.post(AdminUrls.stop, (_req, res) => {
  logger.info("Received signal to stop server. Exiting...");
  res.status(202).end();
  setTimeout(() => {
    process.exit(0);
  });
});

When a POST request hits /.admin/stop, the Express router dispatches the request to this anonymous handler. The handler logs a message, writes a 202 Accepted status back to the client, and schedules an asynchronous call to process.exit(0). There are no checks to establish whether the source IP address is a local loopback address, nor are there validation routines to intercept unauthorized callers.

The server's socket binding logic resides within packages/spector/src/server/server.ts. In the vulnerable version, the server starts as follows:

// packages/spector/src/server/server.ts (Vulnerable Version)
export class MockApiServer {
  // ...
  async start() {
    // ...
    return new Promise((resolve, reject) => {
      const server = this.app.listen(this.config.port, () => {
        const resolvedPort = getPort(server);
        logger.info(`Started server on ${resolvedPort}`);
        resolve(resolvedPort);
      });
    });
  }
}

The omission of the host string parameter in this.app.listen exposes the socket externally. The patch issued in pull request 11274 resolves the issue by enforcing a loopback bind limit. The patch defines LOOPBACK_HOST and feeds it directly into the listen call:

// packages/spector/src/server/server.ts (Patched Version)
const LOOPBACK_HOST = "127.0.0.1";
 
export class MockApiServer {
  // ...
  async start() {
    // ...
    return new Promise((resolve, reject) => {
      const server = this.app.listen(this.config.port, LOOPBACK_HOST, () => {
        const resolvedPort = getPort(server);
        logger.info(`Started server on ${LOOPBACK_HOST}:${resolvedPort}`);
        resolve(resolvedPort);
      });
    });
  }
}

This single parameter addition restricts the operating system from binding the listening socket to external network cards, rendering the port unreachable to external hosts.

To exploit this vulnerability, an attacker must identify an active instance of @typespec/spector running on a target host. Because the application defaults to binding to all adapters, the port is discoverable via simple TCP port scanning utilities (such as nmap or zmap) targeting the default port (typically 3000) or other custom ports specified during startup.

Once the open port is identified, the attacker does not need to establish an authenticated session, solve cryptographic challenges, or bypass any access control lists. The attack payload is a standard HTTP POST request directed to the endpoint path /.admin/stop. This can be executed using standard command-line tools like curl:

curl -i -X POST http://<target_ip>:<port>/.admin/stop

Upon receiving the request, the Express application processes the route. The caller receives an HTTP 202 Accepted response with an empty body, indicating the instruction has been received. Almost immediately afterward, the setTimeout callback triggers process.exit(0), terminating the node process. Any subsequent automated testing routines or network callers will experience a connection failure (Connection Refused), confirming the server is offline.

The technical impact of GHSA-7Q9C-HPX7-9CWM is classified as a complete loss of availability for the mock server component (Denial of Service). While this vulnerability does not allow an attacker to read confidential source files, steal session databases, or achieve remote code execution (RCE), its impact on continuous integration (CI) and local engineering cycles is significant.

In modern automated testing environments, mock servers are used to simulate external service behaviors. Terminating these servers in the middle of a validation suite causes build failures, test runners to hang, and deployment pipelines to crash. In shared multi-tenant development environments, such as cloud dev-boxes or shared staging hosts, an attacker can continuously poll and terminate Spector instances, entirely blocking the engineering department's capability to validate API changes.

The CVSS v3.1 rating is calculated as 7.5 (High) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The network attack vector and low complexity highlight that the vulnerability requires minimal effort to exploit. There are no prerequisites other than basic network line-of-sight to the listening socket.

To properly remediate this vulnerability, organizations must upgrade the @typespec/spector NPM package dependency to version 0.1.0-alpha.27 or higher. This upgrade implements the loopback address restriction, neutralizing the remote attack surface. Projects can update the dependency via their package manager of choice, for example:

pnpm update @typespec/spector@0.1.0-alpha.27

If upgrading is not immediately possible due to dependency constraints, host-level mitigations should be applied. Administrators should configure local packet filters (such as iptables on Linux or Windows Firewall) to restrict inbound connections to the Spector port. For example, the following command blocks all non-loopback inbound connections to port 3000 on Linux:

sudo iptables -A INPUT -p tcp --dport 3000 ! -s 127.0.0.1 -j DROP

Furthermore, developers should avoid exposing development utilities directly to untrusted networks. If access to the mock server from external systems is required for testing, it should be mediated through a secure reverse proxy (such as Nginx or Envoy) that enforces strong authentication and strips out or blocks any request paths matching /\.admin/ before forwarding the traffic.