Summary
Rsdoctor report servers before the patched release expose compiled JavaScript source code, build configuration, errors, and other metadata through an unauthenticated API endpoint. Because the default server listens on all network interfaces and permits wildcard cross-origin requests, a network-adjacent attacker may retrieve sensitive build information without special access.
Affected context
The issue occurs in Rsdoctor deployments using the default report HTTP server started by the @rsdoctor/rspack-plugin integration. Risk is present when the server binds to 0.0.0.0, remains reachable from an untrusted network, and exposes the report API without authentication or origin restrictions. The default behavior is especially relevant for non-CI development or build environments.
Exploit preconditions
- Attack surface: Rsdoctor's report HTTP server and its
POST /api/data/keyendpoint - Required access: Network connectivity to the report server; authentication is not required
- Trigger point: A request to the report data endpoint
- Why exploitation is possible: The service listens on all interfaces, lacks authentication, and permits wildcard CORS, allowing accessible clients to request report data
Why this happens
The vulnerability results from exposing a diagnostic and build-analysis service beyond the local host without an authentication or authorization boundary. Binding the server to 0.0.0.0, combining it with an unauthenticated data endpoint, and allowing unrestricted cross-origin requests permits untrusted clients to retrieve internal build artifacts and metadata. This behavior maps to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.
Potential impact
- Attackers may obtain source code from compiled JavaScript modules
- Build configurations may be disclosed, including potentially sensitive project details
- Error reports and build metadata could reveal implementation or dependency information
- Exposed data may support reconnaissance, intellectual property theft, or follow-on attacks
- Cross-origin access could allow malicious web pages to request report data from reachable developer environments
General mitigation guidance
Mitigation generally focuses on reducing the report server's exposure and enforcing an explicit trust boundary around diagnostic data.
Common defensive patterns include:
- Binding development-only report services to loopback interfaces by default
- Requiring authentication and authorization before serving report data
- Restricting CORS to explicitly trusted origins rather than using wildcard access
- Disabling report servers when their data is not required
- Keeping source maps, configuration details, and diagnostic output out of broadly reachable services
- Running build tooling with least-privilege network and filesystem permissions
- Isolating development and build services from untrusted networks through network policy or equivalent controls
How teams detect issues like this
Organizations can look for report servers that bind to all interfaces, expose diagnostic endpoints without authentication, or return source and configuration data to arbitrary origins. Static analysis and code review can flag wildcard CORS settings, unauthenticated API routes, and default listeners using 0.0.0.0. Runtime testing can verify listener scope, authorization behavior, and response contents, while network monitoring and policy enforcement can identify unexpectedly exposed developer tooling. Automated security review tools may help detect these patterns during dependency and build-pipeline assessments.
