TechReaderDaily.com
TechReaderDaily
Live
Security · Supply Chain

Supply Chain Attacks Target Developer Workstations in 2026

From a backdoored Daemon Tools installer to a Linux RAT that steals SSH keys, attackers are now targeting developer workstations to steal code-signing credentials and push trusted updates.

In this article
  1. The Developer Workstation as the New Registry
  2. What the Disclosure Timelines Reveal

On May 5, 2026, researchers at Kaspersky's Global Research and Analysis Team published a finding: the official installer for Daemon Tools, a disk-image mounting utility with tens of millions of downloads, had been distributing a backdoor for at least 30 days. The installer was served from the developer's own website. It was signed. It passed every trust check that a reasonable user would apply.

The Daemon Tools compromise, reported by Dan Goodin at Ars Technica, was not an isolated event. It landed in a spring that had already produced a 73 percent year-over-year surge in malicious open-source packages, according to Sonatype's Q1 2026 Open Source Malware Index, which catalogued 21,764 malicious packages across npm, PyPI, and other registries in the first three months of the year. The pace did not slow in April and May.

What connects the Daemon Tools incident, the Quasar Linux RAT documented by Trend Micro, and the compromise of the Bitwarden CLI npm package in late April is a shift in attacker methodology. The target is no longer exclusively the package registry or the CI/CD pipeline. The target is the developer's workstation, the machine that holds SSH keys, npm tokens, signing certificates, and browser-stored credentials for GitHub, GitLab, and cloud consoles. Compromise that machine, and you can push signed, trusted code to production without ever touching a repository's access controls.

The Quasar Linux RAT, designated QLNX, was first documented publicly on May 5, 2026 by Trend Micro researchers and covered by The Hacker News on May 8. It is a modular Linux implant that deploys a dual rootkit, one userland, one kernel-level, to hide its presence. It harvests SSH keys, Git credentials, environment variables, and browser-stored tokens. It executes payloads filelessly. And it is purpose-built for one outcome: enabling the attacker to authenticate to package registries, source repositories, and build servers as the victim.

Trend Micro's analysis, also reported by SecurityWeek and BleepingComputer, found that QLNX uses a combination of LD_PRELOAD hooking and a kernel module to intercept system calls. This allows it to conceal files, processes, and network connections from forensic tools. The RAT communicates with its command-and-control server over encrypted channels and can receive modules that extend its credential-theft capabilities to specific development platforms. 'QLNX is not an opportunistic trojan,' Trend Micro researcher Feike Hacquebord told BleepingComputer. 'It is selective. It knows what a developer's environment looks like.'

Every time a developer types npm install, they are placing a bet that the package they are pulling into their project is not malicious., Sonatype Q1 2026 Open Source Malware Index

The numbers behind that bet have deteriorated sharply. Sonatype's research found that the most successful infection vector in Q1 2026 was not typo-squatting or dependency confusion but trust abuse: attackers compromising maintainer accounts and using those accounts' existing trust relationships to push malicious updates. The March 2026 hijacking of a maintainer account for Axios, a JavaScript HTTP library downloaded more than 45 million times per week, demonstrated the scale of exposure from a single compromised account.

In late April 2026, a campaign that singled out security vendors Checkmarx and Bitwarden illustrated a further refinement of the technique. Attackers exploited a compromised GitHub Action to publish a malicious version of the Bitwarden CLI to npm. The package, version 2026.4.0, was available on the registry for approximately six hours before it was pulled. During that window, any developer or CI pipeline running an automated update would have received the compromised version. Ars Technica's Dan Goodin reported that the campaign appeared to target the very organizations best positioned to detect and disclose supply-chain attacks, a form of counter-incident-response operational security.

The Checkmarx and Bitwarden breach shared infrastructure and techniques with the campaign described by Socket, the software supply-chain security firm, in research published on April 24 and covered by Infosecurity Magazine. Socket's researchers identified malicious npm packages exhibiting worm-like propagation, packages that, once installed, would scan the victim's filesystem for other npm tokens, authenticate to the registry as the victim, and publish further malicious packages under the victim's namespace. Socket named the campaign 'Canister.' The worm-like behavior meant a single compromised developer account could seed dozens of additional malicious packages within hours.

The Daemon Tools compromise, which Kaspersky attributed with moderate confidence to a group it tracks as 'BlindEagle,' added another dimension. The backdoored installer was not distributed through a package registry at all. It was served from the vendor's own website, discsoft.com, and was signed with a valid code-signing certificate. The installer dropped a second-stage payload that collected system information, enumerated installed development tools, and exfiltrated browser credentials. Kaspersky's telemetry indicated that victims were concentrated in Russia, Belarus, and Thailand, with a focus on government, scientific research, and retail organisations.

The Daemon Tools developers, Disc Soft Limited, confirmed the breach on May 6 and released a clean version, but the disclosure timeline raised questions. Kaspersky's researchers had notified the company privately before publication. The company did not issue a public advisory until after the Kaspersky report went live. Users who downloaded Daemon Tools between approximately April 1 and May 5, 2026 had no way of knowing the installer was compromised during that period. There is no centralised notification mechanism for this class of supply-chain event.

The Developer Workstation as the New Registry

Each of these incidents points toward the same systemic problem. Package registries have invested heavily in integrity guarantees, npm's signed packages, PyPI's Trusted Publishers, Sigstore for container images. But those guarantees are only as strong as the machine that originates the push. If an attacker owns the developer's workstation, they inherit the developer's signing keys, registry tokens, and multi-factor authentication sessions. The signed artifact is genuine. The compromise is invisible to the registry.

QLNX makes this point explicitly. Its credential harvesting targets the artifacts of the developer workflow: ~/.ssh/id_rsa, ~/.gitconfig, ~/.npmrc, environment variables containing NPM_TOKEN or PYPI_API_TOKEN, and the browser profile that holds authenticated sessions to GitHub and GitLab. With these, an attacker does not need to breach a registry account. They do not need to exploit a CI/CD misconfiguration. They can simply push as the developer, from the developer's own IP address, during the developer's working hours.

The Canister campaign demonstrated how quickly that access can compound. Socket's analysis found that once a token was harvested, the worm could publish a new malicious package to npm within seconds. Each new package could, in turn, harvest tokens from its installers. The propagation graph was exponential. By the time npm's security team removed the initial packages, secondary and tertiary packages had already been published from compromised maintainer accounts whose owners had no idea they had been infected.

What makes these attacks difficult to attribute and disrupt is that they operate within the normal trust boundaries of the development ecosystem. A developer pushing a package update at 10:00 UTC does not look anomalous to the registry. A signed installer served from a vendor's primary domain does not trigger browser warnings. A Linux process that hooks system calls to hide itself from ps and netstat does not appear in the output of those commands. The attacker has studied the defender's assumptions and built tooling that slips through every gap.

What the Disclosure Timelines Reveal

A recurring weakness across the spring 2026 incidents was the disclosure timeline. The Bitwarden CLI compromise was detected by the community, not by any automated monitoring system operated by npm or Bitwarden. The compromised package was available for approximately six hours. No notification reached downstream consumers during that window. The Daemon Tools backdoor operated for at least 30 days before Kaspersky's publication. The Quasar Linux RAT was discovered in the wild before any vendor shipped a detection signature.

These gaps are structural. Package registries do not guarantee real-time integrity verification of every publish event. Code-signing certificates are only revoked after a compromise is confirmed and disclosed, which can take weeks. Antivirus signatures for Linux workstations are maintained with lower priority than those for Windows or macOS, despite the fact that most production infrastructure and nearly all CI/CD pipelines run on Linux. The developer workstation has been treated as a personal device rather than as critical infrastructure, and the security posture reflects that assumption.

Sonatype's data supports this reading. The 73 percent surge in malicious packages was driven in large part by packages that were not novel in technique but were published from accounts that had been trusted for months or years. The trust-abuse vector accounted for the largest share of successful infections, outpacing dependency confusion and typo-squatting combined. The research indicates that the attacker's most reliable strategy is not to introduce new attack surface but to capture existing trust relationships and operate within them.

The systemic version of the single-vendor failure is clear. Registries authenticate packages but not publishers. Code-signing certificates authenticate binaries but not the machine that produced them. Multi-factor authentication protects the account but not the browser session that holds the authenticated token. Each layer of the stack trusts the layer below it, and the bottom layer, the developer's operating system, is increasingly the target of purpose-built implants like QLNX that are maintained, updated, and sold on the same forums that once traded Windows botnets.

The residual risk is not theoretical. As of May 10, 2026, there is no public list of every npm package published by compromised accounts during the Canister campaign. There is no complete inventory of Daemon Tools users who downloaded the backdoored installer. There is no automated way for a developer to audit their workstation for QLNX infection without kernel-level forensic tooling. The cleanup is manual, slow, and incomplete. The next campaign, if it learns from these gaps, will be faster and harder to trace.

What to watch for next: registry-level behavioural anomaly detection that flags pushes from an account whose keyboard cadence, working hours, or IP geolocation have suddenly shifted; mandatory workstation attestation for maintainers of packages above a download threshold; and, most difficult of all, a cultural shift within development teams that treats the developer laptop not as a convenience to be secured lightly but as the first link in a supply chain that, once broken, breaks everything downstream.

Read next

Progress 0% ≈ 8 min left
Subscribe Daily Brief

Get the Daily Brief
before your first meeting.

Five stories. Four minutes. Zero hot takes. Sent at 7:00 a.m. local time, every weekday.

No spam. Unsubscribe in one click.