Malicious npm Package js-logger-pack Turns Hugging Face Into Malware CDN and Data Exfiltration Backend

A rogue npm package called js-logger-pack has been caught turning Hugging Face — one of the most trusted platforms in the AI and machine learning community — into both a malware delivery network and a stolen data repository. The campaign, uncovered and reported by JFrog Security researchers on April 23, 2026, represents a significant evolution in how attackers abuse legitimate cloud infrastructure to conduct supply chain attacks while evading detection.

The Deceptive Package

At first glance, js-logger-pack appeared entirely harmless. When a developer installed it, a plausible logging library loaded normally into their project. The malicious activity was hidden in a postinstall script that executed automatically the moment npm finished installing the package. This script launched a detached background process — invisible to the developer — while the npm install command returned a normal exit code with no error messages.

Based on the host operating system, the background downloader fetched one of four malicious binaries from a public Hugging Face repository controlled by the attacker, identified as Lordplay/system-releases. The binaries targeted Windows, macOS, and Linux environments, ensuring broad cross-platform reach.

Cross-Platform Implant Architecture

JFrog Security researchers extracted and analyzed the embedded JavaScript payload from all four Node.js Single Executable Application (SEA) binaries. Their analysis confirmed a key architectural detail: all four were not separate malware families but the same JavaScript implant wrapped inside four different Node.js runtime containers. The malicious logic was identical across platforms — only the packaging differed.

Once deployed, the implant established persistence using platform-native mechanisms:

• Windows: Scheduled tasks and registry Run keys.
• macOS: LaunchAgent entries in the user’s Library folder.
• Linux: systemd user units.

The implant then opened a WebSocket connection to a hard-coded command-and-control server at 195[.]201[.]194[.]107, registering the infected machine and awaiting operator commands.

Full Remote Access Capabilities

Once active, the implant gave the attacker extensive remote access to the infected system. The operator could:

• Read and write arbitrary files anywhere on the filesystem.
• Scan for stored credentials across browser profiles and configuration files.
• Log keystrokes to capture credentials as they are typed.
• Monitor clipboard contents in real time.
• Deploy additional payloads at any time.
• Force-kill browser processes and wipe saved credentials, then capture any re-entered passwords via the active keylogger.

This last capability was particularly insidious: by forcing a browser logout, the attacker could harvest fresh, session-valid credentials even from users who had previously changed their passwords after a suspected compromise.

Hugging Face as the Exfiltration Backend

What makes this campaign especially notable is the attacker’s choice of exfiltration destination. Rather than sending stolen data to a dedicated private server — which would be easier to block and attribute — the operator directed all collected data into private Hugging Face datasets under the attacker’s account.

When the operator triggered an upload task through the C2, the implant received a Hugging Face authentication token, a target path, and an upload ID. It then compressed the requested file or folder into a gzip archive and uploaded it to the attacker-controlled Hugging Face dataset using an embedded Hugging Face hub client. The upload was tracked in a local state file and would resume automatically on reconnection, ensuring no stolen data was lost even if the network connection dropped mid-transfer.

This approach gave the attacker a significant operational advantage. The C2 server never stored stolen content directly, dramatically lowering its exposure. Traffic to Hugging Face blends in with the enormous volume of legitimate ML model and dataset traffic the platform handles daily, making it extremely difficult to detect through network monitoring alone.

Indicators of Compromise and Immediate Remediation Steps

Any machine that ran js-logger-pack version 1.1.27 should be treated as fully compromised. Affected developers and organizations should take the following immediate actions:

• Rotate all secrets immediately — including AWS keys, SSH keys, npm tokens, database passwords, API keys, and any credentials stored in browser profiles.
• Remove persistence artifacts — delete the MicrosoftSystem64 scheduled task and registry Run key (Windows), the LaunchAgent entry (macOS), or the systemd user unit (Linux), depending on the operating system.
• Purge the package and clear npm cache, then run npm config set ignore-scripts true to prevent postinstall hooks from executing automatically in the future.
• Review all package.json changes carefully, including minor patch-level updates, as malicious actors frequently hide in seemingly routine dependency updates.
• Block network traffic to and from 195[.]201[.]194[.]107.

The js-logger-pack campaign illustrates a growing trend: attackers are not just abusing open-source package registries to distribute malware, they are now integrating the entire legitimate cloud ecosystem — from AI model hosting platforms to serverless compute providers — as operational infrastructure. Defenders must adapt their monitoring strategies to account for trusted platforms being weaponized against them.