CVE-2026-61782: Sensitive Information Disclosure and Source Code Exfiltration via Insecure HTTP Server Defaults in @rsdoctor/rspack-plugin

The @rsdoctor/rspack-plugin is a diagnostic analyzer designed for the Rspack build system to help developers audit build speeds, bundle size, and compilation behavior. During the build process, the plugin automatically instantiates an embedded HTTP server to host an interactive dashboard displaying report statistics. By default, this server executes in local development environments and serves diagnostic pages locally for the developer.

Prior to version 1.5.16, the diagnostic server was configured with insecure defaults that exposed critical system information. Specifically, the server bound to all network interfaces (0.0.0.0) and served wildcard Cross-Origin Resource Sharing (CORS) headers. Additionally, it exposed several sensitive API endpoints, including the retrieval of full, uncompiled module source code maps. This architectural pattern created an immediate risk of unauthorized data exfiltration.

This vulnerability class is characterized as CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). It represents a significant risk because build systems frequently process proprietary source files, local environment variables, and configuration paths. If exploited, an attacker can silently reconstruct the target application's codebase without authentication.

The core issue in CVE-2026-61782 stems from the combination of binding to the wild-card host address (0.0.0.0) and permissive cross-origin resource sharing headers. When an application listens on the 0.0.0.0 interface in Node.js, the operating system permits incoming network traffic on all network interfaces. This configuration exposes the diagnostic port to the local subnet, making it accessible to adjacent machines on the same physical or wireless network.

The second failure occurs in the CORS policy implementation. The server set the "Access-Control-Allow-Origin" header to "*" (wildcard) while also permitting credential transfers. This configuration disables standard browser protection mechanisms like the Same-Origin Policy (SOP). When a developer with an active diagnostic server visits a malicious website, the web browser is instructed by the malicious site to query the local server and successfully reads the response due to the wildcard CORS configuration.

The third and final component of the vulnerability is the unauthenticated POST endpoint "/api/data/key". The server mapped this route to return serialized internal build structures. A query containing the parameter "moduleCodeMap" instructed the server to return the complete mapping of module identifiers to their respective original source code. The server processed this request and replied with the full source code payload without requiring any session tokens, client authentication, or source-origin validation.

Analysis of the vulnerable implementation in packages/utils/src/build/server.ts and packages/sdk/src/sdk/server/index.ts reveals that server.listen was called with only the port argument. This triggered the default behavior in Node.js to accept connections on the unspecified IPv4 (0.0.0.0) or IPv6 (::) address. Below is a representation of the vulnerable configuration in the server initialization phase.

// Vulnerable Server Initialization
import express from 'express';
import cors from 'cors';
 
const app = express();
// Permissive wildcard CORS configuration allowed any origin
app.use(cors());
 
app.post('/api/data/key', (req, res) => {
  const { key } = req.body;
  // Unauthenticated access to the build-time data dictionary
  const data = buildDataStore.get(key);
  res.json(data);
});
 
// Binding without specifying the host defaults to 0.0.0.0
app.listen(port, () => {
  console.log(`Diagnostic server listening on port ${port}`);
});

The patches introduced in commits 602eb306a49b6d19c4c1ea9d8ee0f8caab9e208f and e9aaef21f85becfe43a46f716509f41ea5edeb40 enforced rigorous security controls. The primary modification restricted the default host to the loopback interface "127.0.0.1". Additionally, the wildcard CORS middleware was removed and replaced with a strict origin-validation mechanism. This mechanism checks that the request origin belongs to localhost or loopback IP addresses before populating the Access-Control-Allow-Origin header.

Furthermore, the WebSocket handshake protocol was hardened through a multi-step verification process. This includes verifying that the Host header points to a local address to prevent DNS rebinding attacks, and validating a cryptographically random socket token. Below is the structured representation of the remediated code paths implementing these controls.

// Patched Server Implementation (1.5.16+)
import { randomBytes } from 'crypto';
 
export const defaultHost = '127.0.0.1';
const LOCAL_HOSTNAMES = new Set(['localhost', '127.0.0.1', '[::1]', '::1']);
 
// Strict Host header validation to mitigate DNS rebinding
export function isAllowedRequestHost(host: string | undefined): boolean {
  if (!host) return false;
  const hostname = host.split(':')[0].toLowerCase();
  return LOCAL_HOSTNAMES.has(hostname);
}
 
// Custom security middleware verifying cross-origin source addresses
function setCorsHeaders(req: any, res: any) {
  const origin = req.headers.origin;
  if (typeof origin !== 'string') return false;
  
  try {
    const url = new URL(origin);
    if (LOCAL_HOSTNAMES.has(url.hostname)) {
      res.setHeader('Access-Control-Allow-Origin', origin);
      res.setHeader('Vary', 'Origin');
      res.setHeader('Access-Control-Allow-Headers', 'Content-Type');
      res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
      return true;
    }
  } catch {
    return false;
  }
  return false;
}

Exploitation of CVE-2026-61782 does not require complex payloads or high levels of privilege. In a local area network scenario, an attacker can execute a standard TCP port scan across a subnet to discover active diagnostic ports on target developer workstations. Once an open port is identified, a single POST request containing a JSON body with the key "moduleCodeMap" returns the application source code.

In a cross-origin web attack vector, the exploit sequence occurs when a developer visits a malicious website. The website runs JavaScript code in the background that issues fetch requests to local ports on loopback (127.0.0.1) across the typical port range of the Rsdoctor server. When a request succeeds, the browser transmits the payload, receives the code map, and sends it to an attacker-controlled listener.

The attack flow can be modeled using the following architecture diagram, illustrating the interaction between the developer workstation, the malicious site, and the vulnerable server.

The impact of this vulnerability is categorized as high because it allows complete exposure of the application source code being analyzed. Under development conditions, the compiled assets contain not only public frontend scripts but also proprietary intellectual property, draft algorithms, internal system logic, and test files. This direct exfiltration of source code severely compromises intellectual property protection.

Moreover, configuration metadata is also exposed via the "/api/data/key" endpoint when querying other keys like "configs". These configurations often store absolute file system paths, local user directories, environment variables, or hardcoded API keys. Access to these parameters provides an attacker with actionable intelligence about the developer's workstation environment, facilitating further privilege escalation or targeted attacks.

This vulnerability is assigned a CVSS 3.1 base score of 7.5 (High). It has an attack vector of Network and requires no user privileges or operational complexity. It represents a significant threat to development workstations in both corporate offices and public network environments.

The primary remediation strategy is to upgrade @rsdoctor/rspack-plugin to version 1.5.16 or higher. The package manager will resolve the underlying @rsdoctor/sdk and @rsdoctor/utils dependencies to their patched states. This restricts the diagnostic HTTP server to listen exclusively on the local loopback interface (127.0.0.1), preventing external nodes on the network from initiating connections.

If an immediate upgrade is not feasible, developers should configure their build tasks to run with the "CI" environment variable set to "true". The Rsdoctor plugin automatically disables the diagnostic client server when a CI environment is detected. This effectively mitigates the vulnerability by preventing the server from launching entirely.

As a defense-in-depth measure, development organizations should enforce strict firewall policies on workstation endpoints. Restricting incoming connections to development machines prevents unauthorized network-adjacent discovery of diagnostic servers. Developers should also avoid visiting untrusted websites while local developer servers are running in the background.