Supply Chain Attacks Target Ledger Hardware Wallets with Evolving Backdoors
After Ledger announced on 10 October that a backdoor embedded in several Ledger Nano X wallets sold in Southeast Asia had allowed thieves to steal roughly 102 million dollars in cryptocurrency, reports emerged of similar implants discovered in devices sold in Germany.
Initial hardware implants were found in an unknown number of Ledger Nano X units sold by the authorized Malaysian reseller CryptoBilis. Ledger initially stated the implants were limited to a single reseller batch. A European owner later reported finding implants in a Nano X purchased in August from the large electronics retailer MediaMarkt and in a second unit bought the following week from another MediaMarkt store, suggesting supply-chain compromise.
Users and researchers subsequently reported implants in Ledger Flex and Ledger Stax devices from Ledger’s newer product lines. The implants appear to be more advanced iterations of those first identified by hardware hacker Joe Grand earlier in the year. Grand had notified Ledger in March after discovering backdoors in multiple Nano X units purchased from suspicious online sellers, yet received limited follow-up until he publicly presented his findings at conferences in April and May.
The most recent implants were discovered in wallets sold through authorized channels, indicating attackers have shifted tactics to target trusted resellers. Bitquery analysis linked the October theft to approximately 315 compromised accounts connected to CryptoBilis devices, with stolen assets including Bitcoin, Ethereum, and Tron. Some funds have been frozen, while others reside on addresses previously flagged for fraud.
Mark Karpeles, the former Mt. Gox CEO, purchased two Ledger devices after reading Grand’s research and identified even more sophisticated implants. One version used a custom orange flexible PCB and a smaller battery; a later revision featured a black flexible PCB, erased markings, and an antenna silk-screened with the identifier AC-A2016-NANO-V1.1, indicating purpose-built components for mass production.
Ledger has stated it has found no evidence of compromise to its own infrastructure and reminded authorized resellers that returned devices must not be resold. CryptoBilis confirmed it is cooperating with the investigation. The company changed ownership in March, a fact that only became public after the thefts.
Related articles
Audit of 25 Package Managers Shows Only Two Verify Every Package's Integrity Against Compromised Repositories
A comprehensive test by Trail of Bits examined 25 popular package managers to determine whether they detect malicious code substituted by a compromised repository. The study found that fewer than half verify package integrity by default using lockfiles, and only two managers check the cryptographic hash of every downloaded package. Most managers either require manual configuration, use hashes insecurely, or lack any integrity checks even when lockfiles are present. Signature verification is even rarer, with only Go performing checks by default. The research used a Docker and mitmproxy testbed to simulate attacks while preserving realistic conditions. Results highlight significant gaps in supply-chain protections across ecosystems including JavaScript, Python, Ruby, Rust, and others. The findings also discuss limitations of current lockfile designs and emerging improvements in several communities.
Compromised ConnectWise Credential Used to Access 173 Microsoft 365 Environments in Supply Chain Attack
A compromised credential from ConnectWise Cloud Backup, formerly known as SkyKick Backup, was abused to access at least 173 partner and customer Microsoft 365 environments. Microsoft Threat Intelligence classified the incident as an active supply chain attack. The attacker bypassed password and multi-factor authentication by using a client assertion issued from the vendor environment, impersonating an already-approved application identity to obtain Microsoft Graph tokens. Access occurred on October 15 between 06:13 and 08:34 UTC, with the intruder enumerating environment identifiers sequentially at short intervals, indicating automated scripting against a prepared target list. The backup application's permissions covered Exchange, OneDrive, SharePoint, Teams, and directory information. In one environment, another vendor application was granted global administrator rights and planted secrets in two trusted applications valid until 2028. ConnectWise later disabled seven application identities, revoked affected certificates, and suspended Cloud Backup services.
OIDC Configured but GitHub Actions Still Vulnerable: Megalodon and actions-cool Attacks Expose Runner Risks
Even after widespread adoption of OIDC for temporary cloud credentials in GitHub Actions, two major attacks in May 2026 demonstrated that the approach remains insufficient on its own. Attackers compromised actions-cool/issues-helper by substituting action tags to execute malicious commits that read Runner.Worker memory. The Megalodon campaign injected malicious workflows into 5,561 public repositories, harvesting environment variables, credential files, kubeconfig, SSH keys, and OIDC tokens. OIDC eliminates long-lived AWS_ACCESS_KEY_ID secrets but leaves short-lived tokens exposed inside the runner during job execution. Four mandatory protection layers are now required: strict cloud trust policies using StringEquals on the sub claim, job-level id-token: write permissions, outbound traffic controls such as Harden-Runner, and CODEOWNERS enforcement on .github/workflows/. GitHub Environments with mandatory reviewers add an essential human-approval gate that would have disrupted the Megalodon attack path.
GitHub Repo Trap with 1774 Stars Mimics Microsoft Activation Scripts to Deliver Malware via Telegram Bot
A security researcher built a Telegram bot that daily delivers five trending GitHub repositories from trendshift.io along with README summaries. One repository named Microsoft Activation Scripts contained only a README with a reversed PowerShell command that decoded to download and execute a payload from a lookalike domain. The account was created 94 seconds before the repository and used classic one-liner installation syntax to blend with legitimate projects. Analysis of 321 trending repositories showed that simple filters such as recent account age or irm|iex patterns would incorrectly flag many legitimate projects including codex and opencode. Two independent detection rules were developed: one that normalizes and scans for obfuscated execution commands including base64, mshta, certutil and hidden window flags, and another that flags one-time owners created less than 30 days before the repository with under 10 KB of content. An additional groundedness check using the AIHOT method prevents DeepSeek from inserting unverified claims such as Ruby or Cypress into repository summaries.