Trending Topics

Mini Shai-Hulud Supply Chain Attack Backdoors TanStack npm Packages With Credential-Stealing Malware

A critical supply chain attack has compromised 42 legitimate @tanstack/* packages on npm, allowing attackers to push credential-stealing malware through trusted software updates. The incident, tracked as CVE-2026-45321, involved 84 malicious package versions published within a six-minute window on May 11, 2026, using TanStack’s legitimate GitHub Actions OIDC trusted-publisher binding. Security researchers say the attack was part of the expanding Mini Shai-Hulud campaign, a self-propagating worm linked to broader ecosystem compromises across npm and PyPI. What makes this attack especially dangerous is that the publish workflow itself was not directly altered. Instead, the attackers chained together a pull_request_target misconfiguration, GitHub Actions cache poisoning across the fork-to-base trust boundary, and runtime extraction of the OIDC token from the Actions runner’s memory. That lets them publish malicious versions under a fully trusted identity, bypassing the assumptions many developers and CI systems make about the provenance of official packages. In other words, the packages looked legitimate because, from the registry’s perspective, they were legitimate publishers. The malicious payload did far more than simple reconnaissance. Public analyses convey that the malware harvested GitHub tokens, SSH private keys, npm credentials, cloud metadata from AWS and GCP, Kubernetes service account tokens, and HashiCorp Vault tokens, then exfiltrated the data through the Session or Oxen messenger network. Researchers also found evidence of worm-like behavior, with the malware attempting to identify other repositories and packages accessible to stolen tokens, inject the same payload, bump versionsouter_init[.]js, abused a fake optional dependency named @tanstack/setup, and in some cases attempted persistence in tools like Visual Studio Code and Claude Code. For organizations and developers, any environment that installed affected @tanstack/* packages during the compromise window should be treated as potentially compromised, with all reachable credentials rotated and cloud audit logs reviewed for suspicious activity. Teams should pin TanStack dependencies to known-good versions published before the incident, delete node_modules and lockfiles, and reinstall from clean sources, ideally with lifecycle scripts temporarily disabled using ignore-scripts as a defense-in-depth measure. More broadly, this breach is another reminder that software supply chain trust can fail even when packages come from official namespaces and valid publish pipelines, making CI hardening, token scoping, cache isolation, and dependency monitoring essential controls rather than optional best practices.

Fake FinalShell and Xshell Sites Are Quietly Turning Routine Downloads Into RAT Infections

Fake sites posing as FinalShell and Xshell download pages are being used to deliver Kong RAT, a remote access trojan aimed at developers, administrators, and other users who rely on SSH and remote management tools every day. The danger is not just the malware itself, but the delivery method: these victims are not opening suspicious attachments or disabling security controls; they are simply searching for trusted tools and clicking what appears to be the right result. That is what makes this campaign especially effective. Researchers say the attackers are using SEO poisoning to push malicious lookalike sites higher in search results, particularly for Chinese-speaking users searching for FinalShell, Xshell, QuickQ, and Clash. The fake pages copy the branding, language, and general layout of legitimate software portals closely enough to pass a quick visual check, which means the attack succeeds by blending into routine admin behavior instead of standing out as obvious fraud. Once the victim downloads and runs the installer, the compromise moves from deception to persistence. Kong RAT is installed in the background and can collect host details, communicate with command-and-control infrastructure, and give attackers remote access to the infected machine. In many environments, that machine is not an ordinary endpoint but an administrator workstation or developer system that already stores saved credentials, SSH keys, terminal profiles, and direct access to production servers, making a single bad download disproportionately valuable to an attacker. The campaign also shows a smart understanding of target behavior. FinalShell and Xshell are not random lures; they are the kinds of tools used by people who manage infrastructure, maintain cloud systems, and move between internal and external networks as part of their daily work. By compromising those users, attackers can skip the slow work of broad phishing campaigns and instead target a smaller group whose access is already privileged, trusted, and operationally central. Several reported domains linked to the activity include finalshell-ssh[.]com, xshell-cn[.]com, and quickq-cn[.]com, all of which should be treated as hostile and blocked where possible. Any device that downloaded software from one of these sites deserves immediate investigation, especially if it is used for server administration, cloud access, or software deployment. The larger lesson is simple but easy to ignore: software trust now starts before installation. In an environment where search results can be manipulated, and fake vendor pages can look convincing, organizations can no longer rely on employees to “just download the official tool” without providing a controlled, safe path to do so. For security teams, that means approved software catalogs, bookmarked vendor URLs, endpoint monitoring on admin systems, and a clear rule that remote access tools should never be installed from search-driven links, no matter how legitimate they look.

Fake Claude Code Installers Are Turning Developer Habits Into a Credential Theft Pipeline

The Fake Claude attack does not begin with malware; it begins with a search result, a familiar install page, and a command that looks routine enough to paste into a terminal without a second thought. That is the core of the fake Claude Code installer campaign, now targeting developers, in which threat actors imitate legitimate setup instructions to deliver malware that extracts browser passwords, cookies, payment data, and active session secrets. What makes this campaign so effective is how neatly it fits modern developer behavior. Many tools now advertise frictionless installation through a single command, and users have been trained to trust clean documentation pages and copy buttons more than bulky installers. Attackers are exploiting that trust by creating lookalike Claude Code pages, often surfaced through sponsored results or manipulated search placement, then swapping the real install command for a malicious one that pulls attacker-controlled code from domains like events[.]msft23[.]com. Once the command is executed, the infection chain becomes far more serious than a typical nuisance infostealer. Reporting says the fake installer downloads a heavily obfuscated PowerShell script that checks the victim system, looks for Chromium-based browsers, and hunts for the encryption material used to protect stored browser secrets. To get around Google’s Application-Bound Encryption, the malware uses a native helper and the IElevator2 COM interface to ask the browser’s Elevation Service to decrypt the data, effectively turning trusted browser mechanisms into part of the attack path. The result is not just access to usernames and passwords. Once the keys are recovered, the malware can decrypt cookies, stored credentials, and payment data from local browser databases, package the results, and send them to the attacker's infrastructure. It has also been reported to establish persistence via a scheduled task that polls for follow-on commands, meaning the compromise can continue long after the fake install appears complete. For a developer workstation, that is a worst-case scenario: the browser often holds live sessions to code repositories, cloud consoles, CI/CD systems, internal dashboards, and collaboration platforms that can be abused immediately without waiting for password resets or multifactor prompts. This is why developer-focused malware campaigns are becoming more dangerous than generic phishing. A compromised browser on a normal endpoint is bad, but one on a machine used for deployment, source control, infrastructure access, and privileged admin work can become a launch point into an entire engineering environment. In practice, attackers do not need to breach the company directly; they can steal a trusted developer's session and walk through the front door using the victim’s existing access. The broader lesson here is that documentation, install flows, and command-line convenience have become part of the security boundary. Teams that rely on AI coding tools and developer CLIs need to treat one-line install commands as executable code from an external source, not harmless setup text. That means verifying domains before copying commands, avoiding search-driven install links, logging unusual PowerShell activity, watching for abnormal browser decryption behavior, and assuming that any browser exposed to a fake installer may need full session revocation and credential rotation. The fake Claude Code installer campaign is a reminder that the fastest workflow is not always the safest one. In a development culture built around speed, automation, and copy-paste setup, attackers have found a way to make convenience do the initial work of compromise for them.

Foxconn Confirms Cyberattack on North American Factories, Raising New Supply Chain Questions

One of the world’s largest electronics manufacturers has confirmed that parts of its North American manufacturing footprint were recently disrupted by a cyberattack. Foxconn, best known as a major supplier to Apple and other top tech brands, says several of its factories in the region “suffered a cyberattack” but are now resuming normal production. The confirmation follows days of outages reported at its Wisconsin operations and a public claim by the Nitrogen ransomware group, which says it has stolen a massive trove of internal data. In statements to multiple outlets, Foxconn said that its cybersecurity team activated an emergency response mechanism, implemented operational measures to maintain production and delivery, and that affected facilities are returning to normal. The company has not publicly confirmed whether the incident involved ransomware, whether any data was stolen, or which specific plants were affected, but reporting indicates disruptions at its Mount Pleasant, Wisconsin, campus and a facility in Houston, Texas. At the same time, the Nitrogen ransomware gang has listed Foxconn on its leak site and claims to have exfiltrated 8 terabytes of data, including schematics and project details tied to major customers like Dell, Google, Apple, and Nvidia, a claim Foxconn has not yet addressed directly. From a supply chain perspective, the timing and location of the attack matter. Foxconn operates factories across Wisconsin, Ohio, Texas, Virginia, Indiana, and Mexico, many of which serve high‑visibility consumer and enterprise tech lines. While the company emphasizes that production has remained stable and that impacted plants are resuming regular operations, any sustained outage or compromise at North American sites could ripple through product availability for key partners, including Apple. Investors and industry analysts are already watching for signs of downstream impact, though early reports suggest that Apple‑specific schematics and quality control documentation may not have been affected in this incident. Strategically, this attack also fits into a broader pattern. Foxconn has been targeted by ransomware actors before, including a 2020 attack and a 2024 incident that hit its Foxsemicon Integrated Technology subsidiary. Nitrogen, the group now claiming responsibility, is a relatively new but active player that has shown a willingness to go after large, high‑value manufacturing and infrastructure targets. By claiming 8 terabytes of stolen data and listing Foxconn on its leak site, the group appears to be using the full playbook of double‑extortion tactics: operational disruption, public pressure, and the threat of sensitive data leaks. For other manufacturers and their customers, Foxconn’s latest incident underscores two uncomfortable realities. First, highly connected factories in North America are no less attractive as ransomware targets than plants in any other region, especially when they sit at the center of global technology supply chains. Second, even when companies manage to keep production largely stable or quickly restored, the question of what data was accessed or exfiltrated lingers long after the machines start running again. As Foxconn brings its affected factories fully back online, the real story may ultimately hinge not just on downtime, but on what, if anything, appears in future leaks and how downstream partners respond to yet another reminder that their hardware lifeline can be a single point of digital failure.

Microsoft’s May 2026 Patch Tuesday Lands Hard With 138 Fixes and Several Critical RCE Risks

Microsoft’s May 2026 Patch Tuesday is one of the larger update cycles of the year, bringing fixes for 138 vulnerabilities across Windows, Office, Edge, Azure, Dynamics 365, and other core enterprise products. What makes this month unusual is not just the volume, but the absence of any publicly disclosed or actively exploited zero-days at release time, a rare break from the steady stream of emergency Patch Tuesday updates defenders have dealt with over the past year. That said, the release is still packed with serious issues, including dozens of Critical bugs and multiple remote code execution flaws that affect central Windows services and business applications. At the heart of the release are several vulnerabilities that deserve immediate attention. Among the most serious is CVE-2026-41089, a Critical remote code execution flaw in Windows Netlogon that could allow an unauthenticated attacker to send a crafted request to a domain controller and trigger code execution. Microsoft also fixed Critical remote code execution vulnerabilities in the Windows DNS Client and the TCP/IP stack, the kind of networking flaws that security teams watch closely because they can become broadly disruptive if attackers find reliable exploitation paths. In addition, Dynamics 365 On-Prem received a Critical code-injection fix, and Microsoft Word again appears on the high-priority list with multiple document-based RCE flaws that could be exploited through malicious files and routine social engineering. The broader pattern in May’s update is familiar but still important: elevation of privilege and remote code execution continue to dominate Microsoft’s risk landscape. Tenable notes that almost half of the vulnerabilities fixed this month are elevation-of-privilege issues, while remote code execution accounts for roughly a quarter of the total. That mix reflects how attackers actually operate in real environments, first gaining a foothold through phishing, exposed services, or malicious documents, then chaining local privilege escalation flaws to reach SYSTEM-level access, disable defenses, or move laterally. For defenders, May 2026 offers a chance to patch based on business risk instead of panic.