NPM bundle with three million weekly downloads had a critical vulnerability

108 0

Getty Images

The popular NPM package “pac-resolver” has fixed a serious bug in Remote Code Execution (RCE).

The pac-resolver package receives over 3 million weekly downloads, extending this vulnerability to Node.js applications that are based on the open source dependency. Pac-Resolver advertises itself as a module that accepts JavaScript proxy configuration files and generates a function for your app to map specific domains to use a proxy.

Proxy or not proxy

This week developer Tim Perry announced a fatal bug in pac-resolver that could allow local network threat actors to execute arbitrary code in your Node.js process when it tries to make an HTTP request.

While adding proxy support to his HTTP toolkit, Perry started testing the pac resolver code and came across the security issue. The vulnerability tracked as CVE-2021-23406 has to do with how Proxy Auto-Config (PAC) files are handled by the module. PAC files consist of JavaScript code that specifies a proxy configuration – which network requests go through a proxy and which should be issued directly. For example, network administrators can explicitly specify in a PAC file a network proxy through which all traffic should be routed and view domains that are exempt from the request:

function FindProxyForURL (url, host) {// Send all * .example requests directly without a proxy: if (dnsDomainIs (host, ‘’)) {return ‘DIRECT’; } // Send any other request through this proxy: return ‘PROXY’; }

In the example above, network requests to “” bypass the proxy, while the rest of the traffic is directed to go through a proxy server.

Originally introduced as part of Netscape Navigator 2.0 in 1996, the PAC standard is still relevant and widely used today. For example, the Web Proxy Auto-Discovery Protocol (WAPD) uses DNS and / or DHCP services to find PAC files on a network and import the proxy configuration into an application. However, as the proxy configurations increase, the JavaScript code in a PAC file can become more complex and is ideally designed to run in a virtualized environment (VM).


A few lines of JavaScript can bypass VM, lead to RCE

And this is where the problem begins.

For example, a related NPM package called Pac-Proxy-Agent, which was created by the same author and has over 2 million weekly downloads, provides PAC file support for Node.js applications. Pac proxy agent does this by taking the url to a .pac file, getting the file, and then acting as the Node.js HTTP agent handling outbound requests for your application. However, the Pac proxy agent cannot sandbox PAC files correctly because it uses the vulnerable pac-resolver module that still relies on “Degenerator” to establish the PAC function.

Degenerator is another package by the same author that helps convert arbitrary code into a sandbox function using the “VM” module of Node.js. However, the VM module was never designed as a security mechanism, which is specifically mentioned in the Node.js documents. Therefore, the output from Degenerator – when used by a chain of packages such as pac-resolver, Pac-Proxy-Agent, and Proxy-Agent – presents a security risk.

Referring to a disclaimer in Node documents that says, “The VM module is not a security mechanism. Don’t use it to run untrustworthy code, “Perry said in a blog post:” This is a simple mistake – it’s small text (frankly, it should be the heading on this page and next to each method). “Perry further claims that MongoDB did “exactly the same thing, with even worse consequences.” However, the CVE link Perry refers to includes a third-party tool called mongo-express. MongoDB confirmed to Ars that it had no connection to the have questionable package.

Perry went on to explain that “This is a big problem. While VM tries to create an isolated environment in a separate context, there is a long list of easy ways to access the original context and get out of the sandbox entirely … code in the Inside to allow “the ‘sandbox’ to do basically whatever it wants on your system.”


With this, Perry communicated a proof-of-concept exploit code that shows how an attacker can break out of the VM:

“That’s all – that’s all it takes to break out of the VM module sandbox. If you can get a vulnerable target to use this PAC file as a proxy configuration, you can run arbitrary code on their machine, ”he explained.

The vulnerability has serious implications for those using pac-resolver versions prior to 5.0.0, even temporarily in their Node.js application, and:

  • Use PAC files explicitly for proxy configuration or
  • Read and use the operating system proxy configuration in Node.js on systems with WPAD enabled or
  • Use the proxy configuration (env vars, config files, remote config endpoints, command line arguments) from an untrustworthy source

In any of these scenarios, a remote attacker could configure a malicious PAC URL and execute arbitrary code on a computer when making an HTTP request using the proxy configuration.

The fix for pac-resolver in version 5.0.0 is to simply upgrade the degenerator version to 3.0.1. The core fix went into the degenerator itself and implemented a stronger sandboxing mechanism via the vm2 module to “prevent the privilege escalation of untrustworthy code”.

Perry thanked Snyk for helping the developer through the coordinated vulnerability disclosure process.

Affected developers should update to pac-resolver version 5.0.0 or higher to fix this serious vulnerability in their applications.

Leave a Reply