CodeVetter · Repo Unpack · Risk map
web-infra-dev/rspack
The principal sensitive boundaries are executable build inputs, output deletion/writes, remote-resource fetching, and native-backed JavaScript lifetimes. Source contains protective conditions as well as compatibility limitations. The observations below are not confirmed vulnerabilities, and the single resource-exhaustion concern is explicitly a hypothesis. Partial inspection does not establish the absence of other guards or tests.
- Configuration loading invokes an external config loader with parameters, and plugins/loaders execute supplied functions; this is an execution trust boundary for build inputs.
- output.clean can recursively remove the configured output directory, while CLI outputPath resolves against cwd; these operations target configured filesystem locations rather than a repository-root confinement boundary.
- HTTP imports cross a network boundary guarded by allowed_uris; redirect validation permits only HTTP(S) and rechecks the target against allowed URIs.
- Hypothesis: the inspected Node HTTP client may consume substantial memory for large or highly compressed responses because it decompresses streams, collects every chunk, and concatenates the body without a size limit visible in this function. (inferred)
- Native-backed class access depends on wrapper-specific stale-target policies and hook/loader execution windows; retained Compilation wrappers deliberately resolve to the latest native compilation after rebuild.
- Native close extends a compiler reference to a static lifetime under an explicit N-API ownership argument, waits for in-flight work to become idle, and releases compiler-scoped callback handles in finally.
- PluginDriver::new panics through expect when plugin.apply returns an error; Compiler.compile also documents that afterCompile ordering is driven from Rust, making plugin initialization and hook sequencing high-impact coupling points.
- New-cache compatibility exclusions and WASM cache-suite exclusions limit default validation; the WASM database is a no-op, so native persistence behavior must not be assumed for that target.