The discovery of WeaselBiscuit highlights a significant evolution in software supply-chain threats, demonstrating how attackers can use seemingly ordinary npm dependencies to compromise developer environments and steal sensitive information from browser extensions. Researchers at OpenSourceMalware identified 13 malicious npm packages distributing this previously undocumented JavaScript information stealer. Rather than relying on an elaborate infection framework, the malware uses a relatively compact design focused on retrieving an external payload, collecting host information and stealing Chrome extension storage. Its simplicity does not make it harmless. By targeting the data maintained by browser extensions, WeaselBiscuit potentially exposes information associated with cryptocurrency wallets and other extensions that may contain sensitive account or application data.

The attack begins when a developer or application incorporates one of the malicious npm packages. Unlike malware that depends on a preinstall or postinstall script to execute during package installation, WeaselBiscuit is triggered when the affected package is imported. Its loader, identified as loader.js, retrieves the main malware payload from an Npoint-hosted location and executes it directly in memory. This distinction is particularly important for organisations that have introduced controls to disable npm lifecycle scripts. Preventing installation scripts from running can eliminate one common attack path, but it does not prevent malicious code from executing when an application legitimately imports an untrusted dependency. 

The use of an external payload creates an additional supply-chain risk because the code published in the npm package is not necessarily the complete code that ultimately executes. A package may contain a small loader that appears relatively straightforward during inspection while retrieving its actual malicious functionality from infrastructure controlled by the attacker. This separation can make static analysis more challenging and allows the attacker to alter the remotely hosted payload without publishing another package version. It reinforces the need to examine not only the files contained in a dependency but also its runtime behaviour, particularly unexpected network connections and attempts to execute remotely retrieved code. 

After execution, WeaselBiscuit retrieves its command-and-control configuration from a separate Npoint location, profiles the compromised system and searches for Chrome extension storage across Windows, macOS and Linux. The use of an online JSON storage service as a configuration source is noteworthy because it separates the initial npm package, the payload-delivery location and the operational command-and-control infrastructure. This layered approach can make the attack more flexible, as configuration information may be changed without modifying the original package. The researchers also observed a command-and-control endpoint at 103.170.217[.]184:8787, which defenders can use as one investigation lead alongside other technical indicators. 

The malware's most distinctive capability is its collection of data from Chrome's Local Extension Settings directory. This directory contains LevelDB databases used by browser extensions to maintain local information. WeaselBiscuit reportedly uploads every readable, nonempty file in the targeted extension-storage directories rather than limiting collection to a specific wallet or searching exclusively for known credential formats. This broad collection approach is significant because the attacker does not need to understand the internal storage format of every extension before stealing the underlying files. The information can be examined later, potentially allowing the attacker to identify useful data from different extensions after exfiltration. 

Browser extension storage is an important target because extensions often operate close to sensitive user activities. Cryptocurrency wallets may maintain application state, account information or other data related to wallet operations. Password managers and productivity extensions may also store sensitive information, depending on their implementation and security architecture. However, the theft of extension storage does not automatically establish that wallet private keys, passwords or encrypted vault contents have been recovered. The actual consequences depend on what each extension stores locally, whether sensitive information is encrypted and whether the attacker can obtain any additional material required to decrypt it. The confirmed concern is unauthorised extraction of potentially sensitive extension data, not proven compromise of every account associated with an infected browser. 

WeaselBiscuit also includes additional surveillance capabilities on Windows. Based on commands received from its command-and-control server, it can capture clipboard contents and record keystrokes. These features expand the potential impact beyond stored browser-extension data because users frequently copy passwords, cryptocurrency addresses, access tokens and other sensitive information through the clipboard. Keystroke collection may expose information entered into applications, including credentials and confidential business data. The presence of these capabilities demonstrates that a comparatively small malware family can still combine multiple forms of information theft without requiring a large or complex payload. 

The investigation found functional similarities between WeaselBiscuit and BeaverTail and OtterCookie, malware associated with the North Korean Contagious Interview campaign. Both earlier families have targeted developers and other technically skilled individuals, making the resemblance particularly relevant to software supply-chain security. Nevertheless, researchers explicitly stated that the available evidence is insufficient to conclusively attribute WeaselBiscuit to North Korean operators. Similarities in code, infrastructure patterns or operational techniques can suggest a relationship, but they may also result from code reuse or imitation. Organisations should therefore focus on the observed malware behaviour and technical indicators rather than treating the attribution as established fact. 

The comparison with BeaverTail and OtterCookie also reveals an interesting operational distinction. WeaselBiscuit does not incorporate the same broad functionality found in those malware families. Researchers did not identify built-in persistence, remote-access capabilities, direct cryptocurrency wallet-draining functionality or the ability to deploy secondary malware such as InvisibleFerret. Instead, the malware concentrates on collecting valuable information and communicating with its command-and-control infrastructure. This narrower design may reduce implementation complexity while still achieving an important attacker objective: obtaining data that can potentially support financial theft, account compromise or subsequent intrusion activity. 

The campaign illustrates why developer workstations are attractive targets. Developers frequently install third-party packages, execute unfamiliar code and maintain access to source repositories, cloud development environments and business applications. They may also use browser extensions for authentication, cryptocurrency transactions or productivity workflows. If a malicious dependency executes in that environment, it may encounter sensitive information that an ordinary application server would not possess. The risk therefore depends not only on the malicious package itself but also on the privileges, accounts and locally stored information available to the compromised user. 

Organisations should respond by reviewing their software dependency inventories for the 13 identified package names and examining whether any of them were imported or executed in developer workstations, automated test environments or build pipelines. Merely finding a package in a lockfile does not establish that the malware executed, but confirmed execution should be treated as a potential information-exposure incident. Investigators should review the relevant execution history, unexpected outbound connections, browser-extension directories and endpoint telemetry to determine what activity occurred. If sensitive extension data may have been exposed, the response should account for the particular extensions installed and the information they maintain. 

Removing a malicious npm dependency is necessary, but it cannot reverse data exfiltration that may already have occurred. Where compromise is confirmed, organisations should assess whether browser sessions, extension-held credentials, cryptocurrency wallet information or other sensitive data require additional protective action. Relevant credentials and access tokens may need to be revoked or rotated from a trusted environment. Cryptocurrency users should follow wallet-specific incident-response procedures based on evidence of exposed secrets rather than assuming that deleting the package makes previously stolen information safe. 

From a preventive perspective, dependency security must extend beyond checking package names and scanning for known malicious installation scripts. Organisations should review unfamiliar packages before adoption, assess publisher reputation and package history, monitor unexpected changes in dependency behaviour and restrict the ability of development processes to access unnecessary sensitive resources. Controlled package repositories and dependency approval procedures can reduce exposure, while runtime monitoring can help identify malicious behaviour that static inspection may miss. No single package-scanning tool should be assumed to detect every remotely loaded payload. 

Network monitoring and contextual data loss prevention can provide additional defensive opportunities. A Node.js process associated with an ordinary development dependency should not unexpectedly retrieve executable code from an unfamiliar configuration service, enumerate browser-extension storage and transmit large collections of local files to an external destination. Monitoring process-to-network relationships, unusual outbound connections and sensitive data movement can help identify this behaviour even when the exact malware family is previously unknown. Detection is strongest when network telemetry is correlated with endpoint evidence showing which process accessed the files and initiated the communication. 

Ultimately, WeaselBiscuit demonstrates that information-stealing malware does not need an elaborate architecture to create a serious cybersecurity risk. Thirteen malicious npm packages provided the distribution mechanism, an ordinary package import triggered execution, externally hosted content supplied the payload, and the resulting malware targeted browser-extension storage across multiple operating systems. The investigation also serves as a reminder that familiar attack techniques can reappear in smaller, specialised malware families without proving that the same threat actor is responsible.

Cybersecurity researchers have discovered a cluster of 13 npm packages that have been found to deliver a previously undocumented JavaScript stealer codenamed WeaselBiscuit. The new malware family, per OpenSourceMalware, exhibits functional overlaps with two malware strains associated with the Democratic People's Republic of Korea's (DPRK) Contagious Interview campaign: BeaverTail and

Source: WeaselBiscuit Stealer Spreads via 13 npm Packages to Harvest Chrome Extension Storage via The Hacker News — published 18 Sep 2026.