Last week’s Sentinel ended with a warning that TeamPCP’s Mini Shai-Hulud supply chain campaign had compromised TanStack npm packages and reached OpenAI, Mistral AI, and UiPath before anyone could stop it. This week, the blast radius expanded through the developer toolchain in a direction the industry did not anticipate: a developer whose credentials were stolen by TanStack’s malicious packages became the entry point for compromising a VS Code extension with 2.2 million installs, which in turn gave attackers 11 minutes to exfiltrate credentials from thousands of developer workstations before anyone noticed. GitHub’s internal codebase followed. Grafana’s source code followed. The malicious extension was live for less time than it takes to eat lunch.
Meanwhile, suspected Iranian operators breached automatic tank gauges at gas stations across multiple US states by doing something that should not still be possible in 2026: logging into internet-facing industrial control systems that had no passwords. And Microsoft disclosed that for roughly a year, any ransomware group with a few thousand dollars and a malicious binary could purchase a Microsoft-signed certificate from an underground service and make their malware look like a legitimate Teams installer. The signing service backed Rhysida, Akira, INC, and Qilin, and it ran for twelve months before anyone disrupted it.
This week: the Mini Shai-Hulud campaign’s expansion from npm packages to VS Code extensions and GitHub’s internal repositories, why Iranian OT intrusions into fuel infrastructure are a dress rehearsal and not the main event, the malware-signing-as-a-service ecosystem that made ransomware code trusted by default, and a zero-authentication SQL injection in Drupal core with a live PoC that government and university IT teams should not have sitting in their queue past today.
Mini Shai-Hulud Expands – GitHub Internal Repositories Breached via Poisoned Nx Console VS Code Extension
What happened:
On May 18, 2026, at 12:30 UTC, a threat actor posing as a legitimate Nx maintainer published version 18.95.0 of the Nx Console VS Code extension to the Visual Studio Code Marketplace. The extension, used by over 2.2 million developers as a workspace companion for Angular and monorepo management, was live with a malicious payload for approximately 11-18 minutes before the Nx team detected the intrusion and pulled it. In that window, an estimated 6,000 or more developers installed the compromised version, with auto-updates silently delivering the malicious build to anyone who had the extension open. The Nx team confirmed on May 21 that the attacker gained the necessary GitHub credentials by compromising an Nx developer through the earlier TanStack npm supply chain attack, making this a direct second-order consequence of last week’s Mini Shai-Hulud campaign. GitHub CISO Alexis Wales confirmed on May 21 that the breach resulted in the exfiltration of approximately 3,800 GitHub internal private repositories. Grafana Labs independently confirmed that its own GitHub breach, disclosed on May 17 and claimed by the extortion group CoinbaseCartel, also traced back to the same TanStack supply chain compromise.
Technical details that matter:
- Initial Foothold: The attacker obtained a legitimate Nx contributor’s GitHub token through credential harvesting from the TanStack npm compromise, then used that token to push a malicious orphan commit to the official nrwl/nx GitHub repository
- Payload Delivery: The rogue extension version fetched a 498 KB obfuscated payload from that hidden orphan commit inside the official Nx GitHub repo at workspace open, making the download origin appear legitimate
- Credential Harvesting Scope: The payload targeted secrets from multiple sources simultaneously – HashiCorp Vault tokens at ~/.vault-token and /etc/vault/token, Kubernetes and AWS IAM auth credentials, AI coding assistant credentials, and general developer secrets stored on disk and in memory
- Persistence (macOS): A launch agent was installed at ~/Library/LaunchAgents/com.user.gh-token-monitor.plist, mirroring the persistence mechanism seen in the original Mini Shai-Hulud npm payloads
- GitHub Lateral Movement: Harvested GitHub tokens were used to enumerate and clone internal repositories, resulting in approximately 3,800 private GitHub repos exfiltrated before the token window closed
- Grafana Branch: A separate credential path from TanStack gave attackers access to a GitHub token with read access to Grafana’s GitHub environment; the attacker downloaded Grafana’s complete private codebase and four additional private repositories, then deleted the malicious fork to remove forensic artifacts, before adding Grafana to the CoinbaseCartel extortion portal. Grafana publicly declined to pay the ransom
- Attribution: TeamPCP has now been confirmed responsible for three sequential supply chain attacks this year: the Bitwarden CLI npm compromise in April, the TanStack/Mini Shai-Hulud campaign on May 11, and this Nx Console VS Code extension compromise on May 18
Why critical institutions should care:
The Nx Console incident compressed the detection-to-damage timeline to under 20 minutes because the attack did not require exploiting a vulnerability. The extension had a verified publisher badge, 2.2 million installs, and a legitimate marketplace presence. Auto-update was enabled for most users. The attacker needed only a single contributor’s GitHub token – stolen not by attacking Nx, but by attacking a library Nx used. The GitHub breach that followed was not a direct attack on GitHub. It was credential reuse from a tool that GitHub’s own developers had installed on their workstations.
For organizations consuming Grafana in observability pipelines – and Grafana has confirmed over 7,000 paying customers including 70% of Fortune 50 companies – the immediate risk is not that Grafana’s source code is public. It is that attackers who possess the full source code of a production monitoring and observability platform can perform deep, offline analysis for zero-day vulnerabilities in that platform before they are ever disclosed. Any organization running Grafana should treat the next two to six months as an elevated window for targeted exploitation of Grafana-specific flaws and should ensure Grafana versions are kept current through patch cycles. Additionally, any developer who had Nx Console installed with auto-updates enabled on May 18 should audit credential stores, check for launch agent persistence, and rotate all secrets that were accessible from that workstation.
Key sources:
- https://thehackernews.com/2026/05/github-internal-repositories-breached.html
- https://www.helpnetsecurity.com/2026/05/21/github-grafana-breach-root-cause-nx-console/
- https://www.infosecurity-magazine.com/news/github-breach-nx-console-vs-code/
- https://www.securityweek.com/grafana-confirms-breach-after-hackers-claim-they-stole-data/
- https://gbhackers.com/nx-console-vs-code-extension/
Iranian ATG Campaign – Suspected Iranian Operators Breach US Gas Station Fuel Monitoring Infrastructure
What happened:
On May 15, 2026, CNN reported that US officials suspect Iranian-linked threat actors breached automatic tank gauge (ATG) systems monitoring underground fuel storage tanks at gas stations across multiple states. The systems were sitting on public-facing internet connections with no password protection. Attackers were able to modify the display readings shown on monitoring screens, though they did not alter actual fuel volumes or cause physical damage to storage or dispensing infrastructure. Officials cautioned that definitive attribution may be difficult because the attackers left limited forensic evidence. The attack coincides with a period of heightened US-Iran geopolitical tension and comes after the Israel Defense Forces claimed in March to have struck a compound housing Iran’s cyber warfare headquarters. PwC threat intelligence director Allison Wikoff characterized the current phase of Iranian cyber operations as accelerating with faster iteration, more layered hacktivist personas, and AI-assisted reconnaissance and phishing at scale.
Technical details that matter:
- Access Vector: Internet-exposed ATG systems (automatic tank gauges manufactured by vendors including Veeder-Root and Franklin Fueling) running no authentication, reachable via direct HTTP or proprietary protocol on standard TCP ports. CISA and NIST have flagged internet-accessible ATG systems as a persistent unmitigated risk since at least 2015
- Techniques Observed: Display value manipulation through direct protocol interaction with the ATG interface, consistent with prior documented Iranian intrusions against US water and gas infrastructure rather than sophisticated exploitation
- Attribution Context: Iranian IRGC-affiliated groups have previously targeted Veeder-Root ATG systems in documented 2023-2024 campaigns. FBI and CISA issued joint advisories in 2023 warning specifically about IRGC Cyber Command targeting ATG systems at US water and energy facilities
- Threat Boundary: While attackers in this campaign modified display values only, ATG access in a more aggressive operation can mask real fuel leaks by suppressing low-level alarms, trigger false inventory readings that cause distributors to halt deliveries to specific stations, and provide persistent access into fuel supply chain operations during geopolitically sensitive periods
- Intelligence vs. Disruption: The US officials’ description of the activity as display manipulation rather than physical disruption is consistent with an intelligence-gathering or capability-positioning operation rather than a destructive attack, a pattern also documented in Volt Typhoon’s pre-positioning in US critical infrastructure
Why critical institutions should care:
This incident is most accurately understood as a capability demonstration and terrain-mapping exercise, not an endpoint attack. Iranian cyber operations documented by CISA have consistently targeted OT environments to position for potential future disruption rather than to cause immediate damage, with the actual disruptive use of access preserved for periods of geopolitical escalation. The ATG systems targeted here have no authentication because their operators either do not know they are internet-facing, do not believe they represent a meaningful attack surface, or cannot justify the operational overhead of securing legacy ICS hardware with modern access controls.
For critical infrastructure operators in energy, utilities, water, and fuel distribution: the operational lesson is not the specific ATG vulnerability, which has been documented for years. It is that threat actors are actively cataloguing which of your OT and ICS systems are accessible before you need them to be unreachable. A passive internet-facing ATG with no authentication is not a low-risk device. It is an entry point into a fuel supply monitoring network during a period when adversaries have documented motivation to disrupt US infrastructure. The time to remove that exposure is before the disruption event, not after it.
Key sources:
- https://www.cnn.com/2026/05/15/politics/iran-hackers-tank-readers-gas-stations
- https://energynewsbeat.co/cyber-warfare/cnn-reports-gas-system-hacked-suspected-iranian-cyber-intrusions-target-u-s-gas-station-fuel-tank-monitors/
- https://www.wionews.com/world/is-iran-hacking-us-fuel-systems-cyber-breaches-hit-gas-station-tank-monitors-across-states-1778933758793/amp
- https://resistthemainstream.org/iran-unleashes-scathing-us-attack/
OpFauxSign – Microsoft Dismantles Fox Tempest’s Malware-Signing-as-a-Service Platform
What happened:
On May 19, 2026, Microsoft’s Digital Crimes Unit, working with the FBI and Europol, disclosed the disruption of Fox Tempest, a threat actor that operated a commercial Malware-Signing-as-a-Service (MSaaS) platform at signspace[.]cloud. Active since May 2025, Fox Tempest abused the Microsoft Artifact Signing platform to create short-lived digital certificates allowing cybercriminals to upload malicious binaries and receive back copies signed with certificates that Windows and security software would recognize as legitimate. Microsoft unsealed a civil lawsuit in the Southern District of New York and named the Vanilla Tempest ransomware group as a co-conspirator. The operation shut down hundreds of virtual machines and blocked backend infrastructure. Fox Tempest’s customers included affiliates of the Rhysida, Akira, INC, Qilin, and BlackByte ransomware families, as well as operators of Lumma Stealer, Vidar, and the Oyster/Broomstick backdoor. The service also appeared in campaigns attributed to MuddyWater, an IRGC-linked espionage group, connecting the platform to both financially motivated ransomware and state-sponsored intrusion operations.
Technical details that matter:
- Business Model: Customers uploaded malicious binaries directly to Fox Tempest-controlled infrastructure and received signed versions in return. After February 2026, Fox Tempest shifted to providing pre-configured virtual machines hosted through Cloudzy to further reduce operational friction and improve Fox Tempest’s own OPSEC by limiting direct contact with customer files
- Signing Mechanism: Fox Tempest obtained certificates through Microsoft’s Artifact Signing program, which issues short-lived certificates intended for legitimate software publishers. By cycling through fraudulently obtained publisher accounts, Fox Tempest maintained a continuous supply of fresh, trusted certificates
- Delivery Chain: Vanilla Tempest distributed signed malware via legitimately purchased search advertisements redirecting users searching for Microsoft Teams to fake download pages. Execution of the counterfeit installer deployed Oyster (also known as Broomstick or CleanUpLoader), a modular backdoor providing persistent remote access before staging additional payloads including Rhysida ransomware
- Victim Profile: Rhysida – whose deployment was enabled by this service – has been linked to attacks on schools, hospitals, and critical infrastructure organizations between 2023 and April 2026, including the British Library in October 2023 and Seattle-Tacoma International Airport in September 2024
- Detection Gap: Endpoint security tools that rely on code-signing status as a trust signal would have treated Fox Tempest-signed malware as legitimate software from a recognized publisher. Traditional signature-based detection of unsigned or self-signed malware does not apply to output from this service
Why critical institutions should care:
The Fox Tempest operation is the second known case this year of a criminal infrastructure provider deliberately targeting one of the security industry’s most relied-upon trust signals – after TeamPCP invalidated SLSA provenance attestation in the Mini Shai-Hulud campaign. Code signing exists because operating systems and endpoint security tools use certificate validity as a proxy for software legitimacy. Fox Tempest’s model did not break cryptography. It purchased the same legitimate signing pathway that every enterprise software vendor uses and sold access to it as a subscription service. The result was that Rhysida ransomware, Lumma Stealer, and Vidar arrived on victim machines carrying the same technical legitimacy markers as a signed Teams installer or Adobe Reader update.
The practical impact for critical institutions is not theoretical. Rhysida has specifically targeted hospitals, universities, and government agencies at scale. Its operators had access to a signing service that made their delivery mechanism pass security controls designed to catch unsigned or suspicious executables. Organizations that have deployed application allowlisting or trust-based execution controls based on certificate validation should audit whether their controls distinguish between certificate validity and certificate authenticity of the signer, because Fox Tempest demonstrated that these are not the same thing. Microsoft has taken down the specific infrastructure, but the model – fraudulent certificates issued through legitimate channels – will be replicated.
Key sources:
- https://www.microsoft.com/en-us/security/blog/2026/05/19/exposing-fox-tempest-a-malware-signing-service-operation/
- https://blogs.microsoft.com/on-the-issues/2026/05/19/disrupting-fox-tempest-a-cybercrime-service/
- https://www.bleepingcomputer.com/news/security/cybercrime-service-disrupted-for-abusing-microsoft-platform-to-sign-malware/
- https://therecord.media/microsoft-disrupts-fox-tempest-malware-signing-service
- https://www.infosecurity-magazine.com/news/microsoft-takes-down-fox-tempest/
CVE-2026-9082 / SA-CORE-2026-004 – Unauthenticated SQL Injection in Drupal Core, PoC Live
What happened:
On May 20, 2026, the Drupal Security Team released emergency patches for CVE-2026-9082, a highly critical SQL injection vulnerability in Drupal core’s database abstraction API affecting all Drupal sites using PostgreSQL as their backend database. The flaw scores 20/25 on Drupal’s security risk model with zero access complexity and no authentication required – an anonymous attacker can trigger arbitrary SQL injection by sending specially crafted HTTP requests. Successful exploitation can lead to information disclosure, data modification or deletion, privilege escalation, and in some configurations remote code execution. The patches cover supported branches 11.3, 11.2, 10.6, and 10.5, with exceptional best-effort patches also released for end-of-life Drupal 8.9 and 9.5 given the severity. Drupal’s own pre-release advisory warned that exploits could emerge within hours of disclosure. That timeline materialized: Searchlight Cyber published working proof-of-concept code on the same day the advisory went live, and a patch diff was publicly available within hours of release. As of publication, no confirmed in-the-wild exploitation has been reported, but the combination of a live PoC, no authentication requirement, and Drupal’s deployment density across government, university, and public-sector infrastructure makes this a narrow window.
Technical details that matter:
- Root Cause: The vulnerability exists in Drupal’s EntityQuery condition handler for PostgreSQL. User-controlled PHP array keys can reach SQL placeholder construction without sanitization on the case-insensitive IN query path. The fix applies array_values() to strip attacker-supplied keys and replace them with numeric indexes before they reach the SQL layer
- Exploitation: An unauthenticated attacker sends a specially crafted HTTP request with array keys manipulated to inject SQL syntax. On PostgreSQL backends, this allows arbitrary SQL to execute in the context of the Drupal database user account
- Impact Range: Information disclosure (full database read), integrity violation (data modification or deletion), and in environments where the database user has FILE privileges or the web server has write access to exploitable paths, potential remote code execution
- Scope Limitation: The SQL injection component is specific to PostgreSQL backends. MySQL and MariaDB backends are not affected by this specific code path. However, the same release includes Symfony and Twig dependency security updates that apply to all Drupal environments regardless of database
- PoC Status: Searchlight Cyber published a technical breakdown and two working PoC variants on May 20, making this a patch-now, not patch-soon scenario for every organization running Drupal on PostgreSQL
Why critical institutions should care:
Drupal is the CMS of record for a significant portion of US federal agency websites, state government portals, university public-facing infrastructure, and healthcare information sites. Many of these deployments run PostgreSQL. The combination of no authentication, a live PoC, and government/university deployment density makes this a high-priority target for actors who conduct intrusion campaigns against government and educational infrastructure, including the same ShinyHunters/CoinbaseCartel ecosystem that breached Instructure and Grafana this month.
The practical exposure window is real: the Drupal Security Team’s own advisory predicted exploitation within hours of disclosure. Searchlight Cyber confirmed that prediction by publishing PoC code the same day. For any organization with an internet-facing Drupal installation on PostgreSQL that has not yet applied the May 20 patch, that system should be treated as potentially compromised and patched immediately, not during the next maintenance window. The fix itself is low-complexity – a one-line change in the database abstraction layer – which means there is no technical reason to defer. The operational risk of not patching significantly exceeds the operational risk of an emergency core update.
Key sources:
- https://www.drupal.org/sa-core-2026-004
- https://www.tenable.com/blog/cve-2026-9082-highly-critical-sql-injection-vulnerability-in-drupal-core-sa-core-2026-004
- https://slcyber.io/research-center/keys-to-the-kingdom-anonymous-sql-injection-in-drupal-core-cve-2026-9082/
- https://thehackernews.com/2026/05/drupal-to-release-urgent-core-security.html
- https://www.drupal.org/psa-2026-05-18
The Pattern This Week
Last week, adversaries bypassed evidence generation. The TanStack attackers compromised CI/CD pipelines so that SLSA attestation certified malicious packages as legitimate. UAT-8616 wiped SD-WAN logs after achieving root. West Pharmaceutical’s ransomware operators exfiltrated data before encryption.
This week, the same adversaries – and new ones – are targeting the trust relationships that security teams use to decide what to act on. TeamPCP did not need to break VS Code’s extension system. They needed one developer whose npm credentials were stolen to become the credential source for a separate supply chain attack on a different platform. Fox Tempest did not exploit Microsoft’s signing infrastructure. They purchased access to it the same way legitimate vendors do and sold that access downstream. The Iranian ATG operators did not need sophisticated ICS malware. They needed gas station operators to have left industrial monitoring equipment on the internet with no passwords.
Three different trust models failed this week: the assumption that a verified VS Code extension from a known publisher is safe to auto-update, the assumption that code-signing certificates map to publisher legitimacy, and the assumption that internet-accessible OT infrastructure without password protection represents an acceptable risk level. None of these failures required novel attack techniques. They required patient, systematic targeting of assumptions that defenders have not revisited.
See you next week.
What Your Business Can Do This Week
These four incidents describe distinct threat categories, but they share a common defensive gap: insufficient visibility into the trust assumptions embedded in your current controls. Here is what each incident tells you to do now.
1. Audit VS Code extensions across your developer population and disable auto-update for marketplace extensions. The Nx Console compromise was live for under 20 minutes. Auto-update delivered the malicious version silently to any developer who had the extension installed and VS Code open. Most organizations do not have a process for inventorying VS Code extensions across engineering workstations, let alone alerting on extension version changes. Start by establishing a baseline: know which extensions your developers use, which have access to credentials and cloud configuration files, and which auto-update by default. Consider managing VS Code extension deployments through a private extension marketplace or policy-controlled allowlist rather than relying on individual developers’ installation decisions. For any developer who had Nx Console installed on May 18, treat that workstation as a potential credential-compromise event and rotate secrets that were accessible from that machine before investigating further.
2. Run your OT/ICS asset inventory against Shodan or a similar internet-scanning tool today. The Iranian ATG intrusion was enabled entirely by internet exposure. ATG systems, building management systems, SCADA interfaces, and legacy industrial controllers sit on networks in nearly every energy, healthcare, manufacturing, and utilities environment – and in many cases, nobody knows they are internet-facing. Use a free Shodan account to search your organization’s IP ranges for devices responding on ports associated with ATG protocols (Veeder-Root TLS-350/450, SCI/Unitec, Franklin Fueling), BACnet, Modbus, DNP3, and Ethernet/IP. If any results come back, treat them as compromised until proven otherwise. The goal is not to immediately secure every OT device – it is to know which ones can be reached from the internet before an adversary uses that access for something more damaging than display manipulation.
3. Validate that your endpoint execution controls do not rely solely on code-signing certificate validity. Fox Tempest’s malware carried valid Microsoft-issued certificates. Any endpoint security product or application allowlisting system that trusts executables based on certificate validity – rather than certificate validity combined with publisher identity verification and behavioral analysis – would have permitted Fox Tempest-signed malware to execute. Check your EDR and application control configurations. If your rule set allows execution of signed Microsoft binaries without further inspection, you have the same gap that Fox Tempest exploited for a year. Specifically: confirm whether your controls distinguish between “signed by a certificate issued by Microsoft” and “signed by a certificate issued to a verified and known publisher through Microsoft.” These are not the same check, and only the second one would have blocked Fox Tempest.
4. Patch Drupal core to SA-CORE-2026-004 on any PostgreSQL-backed instance before your next working day. This is not discretionary. CVE-2026-9082 is a no-authentication, no-precondition SQL injection with a working PoC published the same day as the advisory. Drupal powers a substantial share of government, university, and nonprofit web infrastructure. If your organization runs Drupal on PostgreSQL – including through managed hosting environments – contact your hosting provider today if you have not done so already and confirm the patch has been applied. If you manage Drupal directly, upgrade to 11.3.10, 11.2.12, 10.6.9, or 10.5.10 depending on your branch. If you are on end-of-life versions (Drupal 8 or 9), apply the manual patch files Drupal released as a special exception given the severity – and use this event as the forcing function to begin migration to a supported branch. A patched Drupal instance is the minimum. If your site was internet-facing and on PostgreSQL between May 20 and now without the patch applied, assume you need to review access logs for the SQL injection signatures Searchlight Cyber published.

