Entrypoint Rewiring: The Technical Mechanism Behind Execution Flow Hijacking in Malicious Packages

Recent supply chain attacks targeting the open-source ecosystem have evolved beyond simple data theft; they are moving into a stage called "Rewiring," where the actual execution structure of software is redesigned. These sophisticated attacks go far beyond stealing user passwords—they fundamentally alter the behavior of the tools we trust.

A recent case discovered by JFrog Security Research involving @bitwarden/cli (v2026.4.0) clearly illustrates the severity of this threat. By impersonating the CLI client for Bitwarden, a well-known password management tool, this package maintains seemingly legitimate metadata to trick developers into installing it without suspicion. However, internally, it is designed to modify the binary's entrypoint so that an attacker's custom loader is executed instead. This is not just simple malware; it is a sophisticated design intended to break the chain of truth.

Entrypoint Rewiring: How Execution Flow is Hijacked

The core technique used in this attack is "Entrypoint Rewiring." According to JFrog's analysis, the attacker manipulated the npm package metadata to ensure that instead of the legitimate Bitwarden CLI, a custom loader named bw_setup.js is executed.

This process is carried out with extreme precision. The attacker subtly modifies the scripts and bin configurations within the package.json file. For example, they set the preinstall script—which runs automatically during package installation—to node bw_setup.js, and reconfigure the binary entrypoint (the command called when a user types bw) to point to the malicious loader, bw_setup.js.

What makes this approach particularly dangerous is that the package's metadata remains consistent with legitimate Bitwarden information. The internal bundled data still points to Bitwarden CLI v2026.3.0, increasing the likelihood of passing security verification tools. In essence, while the "label" on the package is authentic, the "execution path" has been subtly twisted to run the attacker's code on the developer's workstation.

Payload Deployment: Leveraging the Bun Runtime and Obfuscated Attack Stages

Once executed, the loader named bw_setup.js immediately begins setting up the environment for full-scale infiltration. First, it checks if the bun runtime is installed on the system. If not, it directly downloads the appropriate Bun release archive from GitHub (github.com/oven-sh/bun) to configure the execution environment. This strategy utilizes a modern JavaScript runtime to accelerate the execution of malicious code and evade detection.

Once the environment is prepared, the loader runs a heavily obfuscated JavaScript payload. De-obfuscating this stage reveals an extensive credential theft operation targeting developer workstations and CI/CD environments. The scope of the attack is remarkably broad:

• Authentication Tokens: GitHub and npm Personal Access Tokens (PATs).
• Cloud Credentials: Secret information for AWS, GCP, and Azure.
• Development Environment Data: SSH keys, shell history, and AI tool configuration files.
• CI/CD Security: Secret values from GitHub Actions.

As shown, the attacker's goal extends beyond simple personal information; they are targeting "cloud authority" to potentially seize control of entire corporate infrastructures.

Exfiltration Paths: Stealthy Data Theft via Dual Channels

The process of transmitting stolen data to external servers is also highly sophisticated. To evade detection, the attacker operates two distinct channels (Primary and Fallback).

The first, the Primary Channel, involves sending encrypted telemetry data to audit.checkmarx.cx/v1/telemetry. The attacker collects stolen information through this server; analysis confirmed that this infrastructure is directly linked to the IP address 94.154.172.43.

If the primary channel is blocked, the attacker activates a second Fallback Channel. Remarkably, this method utilizes the GitHub API itself. Using pre-prepared PATs and routing data obtained from public commit messages, the attacker creates new repositories within the victim's account and uploads encrypted data blobs to those repositories. By using GitHub’s own legitimate infrastructure as an exfiltration path, they effectively bypass most security solutions.

Notably, strings following a Shai-Hulud theme (e.g., sardaukar, fremen, atreides) were discovered within the attack code. This suggests a connection to previous specific campaigns and indicates that the attacker may be part of a systematic group rather than an isolated hacker.

Conclusion: Developer Strategies for Strengthening Supply Chain Security

This case demonstrates how fatal the discrepancy between a package's "metadata" and its "actual binary" can be. Even if a package name and version appear trustworthy, developers must always remain vigilant about the possibility that internal scripts or binary paths have been tampered with.

Practical countermeasures for developers and security operators include:

1. Controlling Installation Scripts (Lifecycle Scripts): Closely monitor preinstall and postinstall scripts executed during npm install. It is a best practice to use the --ignore-scripts flag whenever possible to prevent the execution of unintended scripts.
2. Principle of Least Privilege in CI/CD: Worker nodes in CI/CD environments should be granted only the minimum permissions necessary for their tasks. Especially in environments containing cloud credentials (AWS, Azure, etc.), network outbound rules must be strictly enforced to block data transmission to unauthorized domains (e.g., audit.checkmarx.cx).
3. Package Integrity Verification: Implement automated security scanning processes that verify not just the package metadata, but also the hashes and entrypoint configurations of the actual binaries being executed.

Supply chain attacks are evolving into increasingly intelligent "rewiring" forms. In an open-source ecosystem built on trust, it is time for developers to move from "unconditional trust" toward "continuous verification" as a core competency.