undici npm package: is it safe?

Interceptors are invoked dynamically at runtime (dispatch = interceptor(dispatch, interceptorOrigin)). If an attacker controls interceptor values, arbitrary code execution within the dispatch chain is possible. However, interceptors are supplied by the caller, not from external input, so risk is limited.

The compose() method wraps the dispatcher instance in a Proxy that intercepts property access and substitutes a custom dispatch function. While common in HTTP client libraries (e.g., undici) for interceptor support, this pattern could be abused to silently alter request behavior if the source were malicious. No evidence of exfiltration or credential access in this file.

The code reads HTTP_PROXY, HTTPS_PROXY, http_proxy, https_proxy, NO_PROXY, and no_proxy environment variables. While this is standard behavior for proxy agents (the 'Env' prefix implies environment-based configuration), it does grant the module visibility into the host's proxy configuration, which could be exfiltrated if the module were compromised elsewhere.

The dispatcher constructs ProxyAgent instances pointing at URIs derived from environment variables (HTTP_PROXY/HTTPS_PROXY) and routes outbound requests through them. This is the intended, documented purpose of an EnvHttpProxyAgent, but it does mean all traffic from callers using this agent can be redirected to an attacker-controlled proxy if the environment is compromised.

In #shouldProxy, the code references this.#noProxyChanged (line 87 in the file), but the class only defines a getter named #noProxyChanged. Reading this.#noProxyChanged invokes the getter, which is fine, but the naming (a getter used as a boolean flag) is confusing and may indicate an intended caching mechanism that isn't actually implemented. Not malicious, but worth noting for correctness.

The NO_PROXY parser uses regexes on untrusted environment input. The patterns are anchored and bounded, so catastrophic backtracking is unlikely, but parsing environment-controlled data with regexes is a minor robustness concern.

All network activity (Client/Pool/Agent/Socks5ProxyAgent, buildConnector) is directed at the proxy URI or origin supplied by the caller. No hardcoded external hosts, telemetry, or unexpected endpoints are present.

The code reads proxy credentials from constructor options (opts.auth, opts.token, URL username/password) and forwards them as Proxy-Authorization headers to the configured proxy. This is expected behavior for a ProxyAgent and does not constitute credential harvesting or exfiltration.

Contains throwIfProxyAuthIsSent/buildHeaders logic that explicitly prevents users from passing Proxy-Authorization headers per-request (fixes GHSA-6cv7-626c-qhqw), which is a defensive measure rather than a vulnerability.

This module sets and retrieves a global Dispatcher object on globalThis using Symbol.for. This is intentional API design for undici, a widely-used official HTTP client. It does not exfiltrate data, harvest credentials, or execute dynamic code.

The module creates and installs a default Agent at import time if no global dispatcher exists. This is a benign initialization side effect consistent with the library's purpose.

The file embeds a large base64-encoded WebAssembly blob (llhttp parser) and lazily decodes it via Buffer.from on first access to module.exports. This is a legitimate pattern used by llhttp (the HTTP parser used by Node.js). The WASM imports only env callbacks typical of llhttp (wasm_on_headers_complete, wasm_on_message_begin, wasm_on_body, etc.), and exports llhttp_* APIs. No suspicious host bindings for file, network, or process access are present in the imports.

Top-level code defines a getter for module.exports that base64-decodes the embedded blob on demand. There is no eval, no child_process, no network calls, no filesystem access, and no environment/credential harvesting. Execution at import time is limited to defining the property; the decode happens only when exports are accessed.

The file contains a large base64-encoded WebAssembly binary for llhttp (HTTP parser). This is a standard technique used by llhttp to ship a WASM build. The binary exposes only HTTP-parsing callbacks (on_headers_complete, on_message_begin, on_url, on_status, on_header_field, on_header_value, on_body, on_message_complete) and llhttp API functions. No network, filesystem, process-spawning, or credential-harvesting functionality is present.

module.exports is redefined with a getter that lazily decodes the base64 WASM payload once. This is a benign pattern to defer the cost of base64 decoding until first use. It executes at import time but performs no I/O or code execution beyond a Buffer.from base64 decode.

The code is a mock agent implementation for Undici. It only uses local module imports, standard JavaScript constructs, and does not perform any network requests, file I/O, process spawning, dynamic code execution, or credential harvesting. All operations are confined to in-memory dispatcher management and call history tracking.

The snapshot recorder writes request/response data to disk at user-controlled paths via saveSnapshots(), which is expected for a testing/mocking library but does represent persistent file system writes outside the immediate package directory depending on the snapshotPath provided.

Flush failures are silently ignored via empty catch handlers, which could mask write failures and diagnostics; not malicious but a quality concern.

When autoFlush is enabled, the scheduler periodically writes snapshot contents (which may include request headers, bodies, and responses) to the configured snapshotPath. If snapshotPath points outside the project or sensitive headers are not excluded, this can persist sensitive data to disk.

The multipart parser uses input.indexOf to scan for boundaries and processes arbitrarily large bodies without size limits or iteration caps. A maliciously crafted multipart body could cause excessive memory or CPU usage. This is a robustness concern rather than an intentional backdoor.

parseContentDispositionAttribute applies decodeURIComponent to extended (RFC 5987) values and performs ad-hoc percent-decoding replacements (%0A, %0D, %22) on quoted strings. Malformed percent sequences could throw, and the transformation is non-standard, but this is a correctness/robustness issue rather than an exploit vector in this module.

The InflateStream class wraps zlib inflate with caller-provided options. While it doesn't expose dynamic code execution or network access, decompressing untrusted streams without size limits could be used for resource exhaustion if callers pass attacker-controlled data. This is normal fetch/undici behavior rather than a malicious pattern.

The script reads and overwrites './undici-fetch.js' using readFileSync and writeFileSync. While this is likely a build-time script for encoding conversion (UTF-8 to Latin-1), it modifies a source file in place and could be abused to alter package contents.

The script executes file I/O operations at import time (top-level code), which can have side effects when the module is required.

The script uses buffer transcode to convert a file from UTF-8 to Latin-1. This is a legitimate but unusual operation that could theoretically be used to obfuscate or alter code content.