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 have tied the attack to the expanding Mini Shai-Hulud campaign, a self-propagating worm linked to broader ecosystem compromises across npm and PyPI.

What makes this attack particularly dangerous is that the publish workflow itself was never directly altered. Instead, 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 combination allowed them to publish malicious versions under a fully trusted identity, bypassing the provenance assumptions that developers and CI systems routinely make about official packages. From the registry's perspective, the publisher was legitimate - because it was.

The malicious payload went well beyond reconnaissance. Public analyses show 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: the malware attempted to identify other repositories and packages accessible via stolen tokens, inject the same payload, bump package versions outer_init[.]js, abused a fake optional dependency named @tanstack/setup and in some cases establish 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. All reachable credentials should be 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.

The broader lesson here is one the industry keeps relearning: supply chain trust can fail even when packages arrive from official namespaces and valid publish pipelines. CI hardening, token scoping, cache isolation, and dependency monitoring are not optional hygiene. They are the controls standing between a misconfigured workflow and a full credential harvest.

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 targeting developers, administrators, and other users who rely on SSH and remote management tools daily. The danger is not just the malware itself - it is the delivery method. These victims are not opening suspicious attachments or disabling security controls. They are searching for trusted tools and clicking what looks like the right result.

Researchers say 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 layout of legitimate software portals closely enough to pass a quick visual check. The attack succeeds by blending into routine admin behavior rather than standing out as obvious fraud.

Once the victim downloads and runs the installer, the compromise moves from deception to persistence. Kong RAT installs in the background, collects host details, establishes communication with command-and-control infrastructure, and gives attackers remote access to the infected machine. In many environments, that machine is not an ordinary endpoint. It is an administrator workstation or developer system that already holds 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 reflects a clear understanding of target behavior. FinalShell and Xshell are not random lures. They are 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 reach a smaller group whose access is already privileged, trusted, and operationally central.

Several domains linked to the activity include finalshell-ssh[.]com, xshell-cn[.]com, and quickq-cn[.]com. All should be treated as hostile and blocked where possible. Any device that downloaded software from one of these sites warrants immediate investigation, especially if it is used for server administration, cloud access, or software deployment.

The broader lesson is straightforward but easy to overlook: 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 path to do so. For security teams, that means approved software catalogs, bookmarked vendor URLs, endpoint monitoring on admin systems, and a firm 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. What makes this campaign effective is how cleanly 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 exploit 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 that command is executed, the infection chain becomes far more serious than a typical infostealer. The fake installer downloads a heavily obfuscated PowerShell script that profiles the victim system, locates Chromium-based browsers, and hunts for the encryption material protecting stored browser secrets. To bypass Google's Application-Bound Encryption, the malware uses a native helper and the IElevator2 COM interface to ask the browser's own Elevation Service to decrypt the data - 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 decrypts cookies, stored credentials, and payment data from local browser databases, packages the results, and sends them to attacker infrastructure. Persistence is established via a scheduled task that polls for follow-on commands, meaning the compromise can continue long after the fake install appears to have completed normally.

For a developer workstation, that is a worst-case outcome. The browser on a developer machine often holds live sessions to code repositories, cloud consoles, CI/CD systems, internal dashboards, and collaboration platforms - all of which can be abused immediately, without waiting for password resets or multifactor prompts. Attackers do not need to breach the company directly. They can steal a trusted developer's session and walk through the front door using existing access.

The practical implication is that documentation, install flows, and command-line convenience have become part of the security boundary. Teams using 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 treating any browser exposed to a fake installer as a candidate for full session revocation and credential rotation.

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 reported outages 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 its cybersecurity team activated an emergency response mechanism and implemented operational measures to maintain production and delivery. The company has not confirmed whether the incident involved ransomware, whether any data was exfiltrated, or which specific plants were affected. Reporting points to disruptions at its Mount Pleasant, Wisconsin campus and a facility in Houston, Texas. Meanwhile, 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, any sustained outage or compromise at North American sites could ripple through product availability for key partners. Early reports suggest that Apple-specific schematics and quality control documentation may not have been affected, though investors and industry analysts are watching closely for signs of downstream impact.

This attack also fits 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 is a relatively new but active group that has demonstrated a willingness to pursue 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, this incident surfaces two uncomfortable realities. First, highly connected North American factories are no less attractive as ransomware targets than plants anywhere else - especially when they sit at the center of global technology supply chains. Second, even when companies manage to keep production largely stable, the question of what data was accessed or exfiltrated lingers long after the machines start running again.

As Foxconn brings its affected facilities fully back online, the real story may hinge less on downtime and more on what 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 addresses 138 vulnerabilities across Windows, Office, Edge, Azure, Dynamics 365, and other core enterprise products. What makes this month notable is not just the volume - it is the absence of any publicly disclosed or actively exploited zero-days at release time, a rare break from the emergency patch cycles defenders have contended with over the past year. That reprieve does not mean the release is light. It includes dozens of Critical-rated bugs and multiple remote code execution flaws affecting central Windows services and business applications.

Several vulnerabilities deserve immediate attention. CVE-2026-41089 is 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. Dynamics 365 On-Prem received a Critical code-injection fix, and Microsoft Word appears on the priority list again with multiple document-based RCE flaws exploitable 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: gain a foothold through phishing, an exposed service, or a malicious document, then chain a local privilege escalation flaw to reach SYSTEM-level access, disable defenses, or move laterally.

With no zero-days forcing the queue, May 2026 gives defenders a chance to patch based on business risk rather than panic. That opportunity is worth taking seriously.