2026-05-21 AI创业新闻

GitHub Internal Repositories Breached via Malicious Nx Console VS Code Extension

GitHub on Wednesday officially confirmed that the breach of its internal repositories was the result of a compromise of an employee device involving a poisoned version of the Nx Console Microsoft Visual Studio Code (VS Code) extension. The development comes as the Nx team revealed that the extension, nrwl.angular-console , was breached after one of its developers’ systems was hacked in the wake of the recent TanStack supply chain attack. Other companies that were impacted by the TanStack compromise include OpenAI, Mistral AI , and Grafana Labs . “We have no evidence of impact to customer information stored outside of GitHub’s internal repositories, such as our customer’s own enterprises, organizations, and repositories,” Alexis Wales, Chief Information Security Officer of GitHub, said in a statement.

“Some of GitHub’s internal repositories contain information from customers, for example, excerpts of support interactions. If any impact is discovered, we will notify customers via established incident response and notification channels.” The attack is said to have allowed the threat actor, a cybercriminal group known as TeamPCP, to exfiltrate about 3,800 repositories. GitHub said it has taken steps to contain the incident and rotated critical secrets, adding it’s continuing to monitor the situation for follow-on activity. In a post on X, Jeff Cross, co-founder of Narwhal Technologies, the company behind nx.dev, said , “this incident highlights that there need to be deeper, more fundamental changes to how we and other maintainers need to think about securing developer tooling and open source distribution.” “We’re also beginning conversations with other high-profile open source maintainers about how we can work together on some of the deeper structural problems around software supply chain security.

A lot of the assumptions the ecosystem has operated under for years no longer hold.” In recent months, TeamPCP has rapidly gained notoriety for large-scale software supply chain attacks, specifically going after widely-used open-source projects and security-adjacent tools that developers rely on. What’s notable here is that the trojanized version of the VS Code extension was live on Visual Studio Marketplace only for 18 minutes (between 12:30 p.m. and 12:48 p.m. UTC on May 18, 2026).

But this short window was enough for the attackers to distribute a credential stealer capable of harvesting sensitive data from 1Password vaults, Anthropic Claude Code configurations, npm, GitHub, and Amazon Web Services (AWS). “The extension looked and behaved like normal Nx Console, but on startup it silently ran a single shell command that downloaded and executed a hidden package from a planted commit on the official nrwl/nx GitHub repository,” OX Security researcher Nir Zadok said . “The command was disguised as a routine MCP setup task so it would not raise suspicion.” The interlinked nature of modern software has allowed TeamPCP to unleash a self-sustaining cycle of new compromises. The pattern that drives home this aspect is deceptively simple as it’s nefarious: break into one trusted tool, steal credentials from developer systems that may install it, and use those credentials to break into the next legitimate tool.

“Every popular extension marketplace ships with auto-update on by default. VS Code, Cursor, the whole lineup,” Aikido security researcher Raphael Silva said . “The reasoning makes sense in isolation, because most developers never update anything manually, so leaving it off means a long tail of editors running stale, vulnerable code.” “The trade-off stops making sense once you account for hostile/compromised publishers. Auto-update gives an attacker who controls a release a direct push channel into every machine running that extension.

Marketplaces don’t impose any review gate or waiting period between when an update is published and when installed clients pull it in.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Highly Critical Drupal Core Flaw Exposes PostgreSQL Sites to RCE Attacks

Drupal has released security updates for a “highly critical” security vulnerability in Drupal Core that could be exploited by attackers to achieve remote code execution, privilege escalation, or information disclosure. The vulnerability, now tracked as CVE-2026-9082 , carries a CVSS score of 6.5 out of 10.0, per CVE.org. Drupal said the vulnerability resides in a database abstraction API that is used in Drupal Core to validate queries and ensure they are sanitized against SQL injection attacks. “A vulnerability in this API allows an attacker to send specially crafted requests, resulting in arbitrary SQL injection for sites using PostgreSQL databases,” it said .

“This can lead to information disclosure, and in some cases privilege escalation, remote code execution, or other attacks.” Drupal noted the security flaw can be exploited by anonymous users, and impacts only sites that use PostgreSQL. The following versions address the issue - Drupal 11.3.10 Drupal 11.2.12 Drupal 11.1.10 Drupal 10.6.9 Drupal 10.5.10 Drupal 10.4.10 Drupal 7 isn’t affected. The releases for supported branches (versions 11.3, 11.2, 10.6, and 10.5) include upstream security updates for Symfony and Twig, making it essential that the latest versions are installed. As previously disclosed by Drupal, manual patches have also been released for Drupal versions 9 and 8, which have reached end-of-life - Drupal 9.5 Drupal 8.9 “Drupal 11.1.x, Drupal 11.0.x, Drupal 10.4.x, and below are end-of-life and do not receive security coverage,” Drupal said.

“Drupal 8 and Drupal 9 have both reached end-of-life. “Due to this issue’s severity, the unsupported releases and patches for unsupported versions are provided as a best effort. Those unsupported versions will still have other, previously disclosed security vulnerabilities.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Microsoft Open-Sources RAMPART and Clarity to Secure AI Agents During Development

Microsoft has unveiled two new open-source tools called RAMPART and Clarity to assist developers in better testing the security of artificial intelligence (AI) agents. RAMPART , short for Risk Assessment and Measurement Platform for Agentic Red Teaming, functions as a Pytest-native safety and security testing framework for writing and running safety and security tests for AI agents, covering both adversarial and benign issues, as well as various harm categories. Users can write test cases to attack or probe an AI agent to explore possible safety violations like cross-prompt injections, where untrusted data reaches an AI system indirectly via a data source (e.g., email, file, or a web page) processed by it, or unintended behavioral regressions and data exfiltration. RAMPART then evaluates the outcome of those tests and reports the results.

All it needs is an adapter that connects an agent to the test suite. The tool builds on PyRIT (short for Python Risk Identification Tool), which Microsoft released more than two years ago as a way to test AI systems. Clarity , on the other hand, has been described by the tech giant as a “structured sounding board” to help developers arrive at the right approach even before writing a single line of code. It’s an “AI thinking partner that pushes back,” guiding them through problem clarification, solution exploration, failure analysis, and decision tracking.

In publicly releasing these tools, Microsoft said the idea is to address why certain decisions are incorporated at an early stage of software development so that any potential issue - for example, an agent’s access to a tool - is addressed well before the system is built. “We wanted to give product managers and engineers a way to pressure-test their assumptions at the start of a project, when changing course is cheap and the right conversation can save months of rework,” Ram Shankar Siva Kumar , a Data Cowboy and founder of Microsoft’s AI Red Team, said in a blog shared with The Hacker News. Microsoft noted that a secondary motivation behind investing in these tools is to make incidents reproducible and mitigations verifiable and scale the learnings from red teaming exercises by turning them into runnable engineering assets. “Where PyRIT is optimized for black-box discovery by security researchers after the system is built, RAMPART is built for engineers as the system is being built,” Siva Kumar added.

“Clarity helps teams clarify design intent and capture assumptions. Together, these approaches move AI safety from a one-time review to a set of living artifacts that developers can use throughout the lifecycle.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Microsoft Takes Down Malware-Signing Service Behind Ransomware Attacks

Microsoft on Tuesday said it disrupted a malware-signing-as-a-service (MSaaS) operation that weaponized the company’s Artifact Signing system to deliver malicious code and conduct ransomware and other attacks, compromising thousands of machines and networks across the world. The tech giant attributed the activity to a threat actor it calls Fox Tempest , which it said offered the MSaaS scheme to allow cybercriminals to disguise malware as legitimate software. The threat actor has been active since May 2025. The seizure effort has been codenamed OpFauxSign .

“To disrupt the service, we seized Fox Tempest’s website signspace[.]cloud, took offline hundreds of the virtual machines running the operation, and blocked access to a site hosting the underlying code,” Steven Masada, assistant general counsel at Microsoft’s Digital Crimes Unit, said . Microsoft noted that the operation enabled the deployment of Rhysida ransomware by threat actors such as Vanilla Tempest, along with other malware families like Oyster, Lumma Stealer, and Vidar, illustrating the crucial role played by Fox Tempest within the cybercrime ecosystem. In addition, connections have been uncovered between the threat actor and affiliates associated with several prominent ransomware strains, including INC, Qilin, BlackByte, and Akira. Attacks mounted by these operations have targeted healthcare, education, government, and financial services located across the U.S., France, India, and China.

Artifact Signing (formerly Azure Trusted Signing) is Microsoft’s fully managed, end-to-end signing solution that allows developers to easily build and distribute applications, while ensuring that the software is legitimate and hasn’t been modified by unauthorized parties. Fox Tempest is said to have leveraged this mechanism to generate short-lived, fraudulent code-signing certificates and use them to deliver trusted, signed malware and slip past security controls. The certificates were valid for only 72 hours. “To obtain legitimate signed certificates through Artifact Signing, the requestor must pass detailed identify validation processes in keeping with industry standard verifiable credentials (VC), which suggests the threat actor very likely used stolen identities based in the United States and Canada to masquerade as a legitimate entity and obtain the necessary digital credentials for signing,” Microsoft explained .

“The SignSpace website was built on Artifact Signing and enabled secure file signing through an admin panel and user page, leveraging Azure subscriptions, certificates, and a structured database for managing users and files.” The service allowed paying cybercriminal customers to upload malicious files for code-signing using certificates fraudulently obtained by Fox Tempest. This, in turn, allowed malware and ransomware to masquerade as legitimate software like AnyDesk, Microsoft Teams, PuTTY, and Cisco Webex. The service cost between $5,000 and $9,000. Starting February 2026, the threat actor is said to have shifted to providing customers with pre-configured virtual machines (VMs) hosted on Cloudzy , thereby making it possible to directly upload the necessary artifacts to the attacker-controlled infrastructure and receive signed binaries in return.

“This infrastructure evolution reduced friction for customers, improved operational security for Fox Tempest, and further streamlined the delivery of malicious but trusted, signed malware at scale,” Microsoft said. Threat actors like Vanilla Tempest have been found to distribute binaries signed through the service via legitimately purchased advertisements that redirected users searching for Microsoft Teams to bogus download pages, paving the way for the deployment of Oyster (aka Broomstick or CleanUpLoader), a modular implant and loader that’s responsible for delivering Rhysida ransomware. Microsoft said Fox Tempest has continually adapted its tradecraft as the company enacted countermeasures, such as disabling fraudulent accounts and revoking the illicitly obtained certificates, with the threat actor even attempting to shift to a different code-signing service. Court documents reveal that Microsoft worked with a “cooperative source” to purchase and test the service between February and March 2026.

“When attackers can make malicious software look legitimate, it undermines how people and systems decide what’s safe,” Redmond said. “Disrupting that capability is key to raising the cost of cybercrime.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Webworm Deploys EchoCreep and GraphWorm Backdoors Using Discord and MS Graph API

Cybersecurity researchers have flagged fresh activity from a China-aligned threat actor known as Webworm in 2025, deploying custom backdoors that employ Discord and Microsoft Graph API for command-and-control (C2 or C&C) communications. Webworm, first publicly documented by Broadcom-owned Symantec in September 2022, is assessed to be active since at least 2022, targeting government agencies and enterprises spanning IT services, aerospace, and electric power sectors in Russia, Georgia, Mongolia, and several other Asian nations. Attacks mounted by the group have leveraged remote access trojans (RATs) like Trochilus RAT, Gh0st RAT, and 9002 RAT (aka Hydraq and McRat). The threat actor is said to overlap with China-nexus clusters tracked as FishMonger (aka Aquatic Panda), SixLittleMonkeys , and Space Pirates .

SixLittleMonkeys is best known for deploying Gh0st RAT and a RAT called Mikroceen targeting entities in Central Asia, Russia, Belarus, and Mongolia. “In recent years, it has started moving toward both existing and custom proxy tools, which are more stealthy than full-fledged backdoors,” ESET researcher Eric Howard said . “In 2025, Webworm also added two new backdoors to its toolset: EchoCreep, which uses Discord for C&C communication, and GraphWorm, which uses Microsoft Graph API for the same purpose.” Underlying these efforts is the use of a GitHub repository impersonating a WordPress fork (“github[.]com/anjsdgasdf/WordPress”) as a staging ground for malware and tools like SoftEther VPN in an effort to blend in and fly under the radar. The reliance on SoftEther VPN is a tried-and-tested approach adopted by several Chinese hacking groups .

Over the past two years, the adversary has been observed shifting away from traditional backdoors to (semi-)legitimate utilities such as SOCKS proxies, while also increasingly focusing on European countries, including governmental organizations in Belgium, Italy, Serbia, Poland, and Spain, and a local university in South Africa. The discovery of EchoCreep and GraphWorm marks an expansion of Webworm’s arsenal, even as Trochilus and 9002 RAT appear to have been abandoned by the threat actor. Other tools of note are iox and custom proxy solutions such as WormFrp, ChainWorm, SmuxProxy, and WormSocket. WormFrp has been found to retrieve configurations from a compromised Amazon S3 bucket.

“These custom proxy tools are not only capable of encrypting communications, but also support chaining across multiple hosts both internally and externally to a network,” ESET said. “We believe that the operators use these tools in conjunction with SoftEther VPN to better cover their tracks and increase the stealth of their activities.” EchoCreep supports file upload/download and command execution via “cmd.exe” capabilities, while GraphWorm is a more advanced backdoor that can spawn a new “cmd.exe” session, execute a newly created process, upload and download files to and from Microsoft OneDrive, and stop its own execution after receiving a signal from the operators. An analysis of the Discord channel leveraged by EchoCreep as C2 shows that the earliest commands were sent as far back as March 21, 2024. In all, 433 Discord messages have been sent via the C2 server.

Exactly how these backdoors are delivered, and the initial access pathway used by Webworm, is presently unknown. However, it has emerged that the attacker utilizes open-source utilities like dirsearch and nuclei to brute-force victim web server files and directories, and search for vulnerabilities within. As for tradecraft overlaps, ESET told The Hacker News that Webworm’s links to Space Pirates is tenuous at best, citing the use of open-source RATs and a lack of concrete evidence tying the two clusters. “The relation on which Webworm and Space Pirates is built is on behalf of RATs which are open sourced,” Howard told The Hacker News via email.

“Unfortunately, due to the open-source nature of these RATs, several China-aligned groups make use of these tools. It’s not relevant enough to say that the two groups are related.” “In addition, we have not recently observed any indication that there are overlaps with the group known as Space Pirates. From the recent activity we’ve reported on, we do not believe any other groups were involved.” The disclosure comes as Cisco Talos shed light on a BadIIS variant that’s likely sold or shared among multiple Chinese-speaking cybercrime groups under a malware-as-a-service (MaaS) model designed for continuous monetization. The offering is believed to have been under development since at least September 30, 2021.

The same malware author, who operates under the alias “lwxat,” has also made available a set of supplementary tools, including service-based installers, droppers, and persistence mechanisms that automate deployment, ensure survivability across IIS server restarts, and sidestep detection. The service offers a dedicated builder tool that “allows threat actors to generate configuration files, customize payloads, and inject parameters into BadIIS binaries - enabling capabilities including traffic redirection to illicit sites, reverse proxying for search engine crawler manipulation, content hijacking, and backlink injection for malicious search engine optimization (SEO) fraud,” Talos researcher Joey Chen said. (The story was updated after publication to include a response from ESET.) Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Agent AI is Coming. Are You Ready?

New Industry Data Just Released Suggests Not. On May 19th, 2026, Orchid Security released the results of our Identity Gap: Snapshot 2026. Among the findings, “identity dark matter” (the unseen, unmanaged elements of identity) now overshadows the visible elements 57% vs. 43%.

And it couldn’t have occurred at a worse time, with enterprises embracing Agent AI with both arms (and unfortunately, as Orchid co-founder Robert Wiseman explains, more than one eye closed). Why the concern, you may ask? AI agents are shortcut-seekers by design . When given a task, they are trained to find the most efficient way to complete it, with the speed of machines and the creativity of humans.

Denied access to a necessary system? Use a hard-coded credential stored in plaintext within the application. Need information they aren’t entitled to read? “Borrow” a credential with higher privilege.

Constantly being challenged across many different systems? Grab a broadly accepted token. Truly, Agent AI’s creativity is remarkable. It just cuts both ways.

Just because an AI Agent can find a way to access an application, a system, a database, doesn’t mean that they should do so. But where coding would restrict a traditional nonhuman actor and conscience should give a human pause, in most cases, AI Agents have no such constraints or compunctions. That’s why well-managed identity and access management is a critical foundation to keeping Agent AI activity within authorized bounds. Look no further than the cloud outages reported at the start of the year to understand this importance.

Of course, IAM shortcuts, gaps, and exceptions have built up over the years. Even decades. So it’s not reasonable to expect everything to be cleaned up at once. That’s why the findings from this year’s Identity Gap Snapshot- the exposures most common across North American and European enterprises- are so important and timely.

Top 3 Findings Invisible Non-Human Accounts: Two out of every three nonhuman accounts are set up locally in the application itself. That makes them unseen and unmanaged by the central IAM program. Understandable for machine and service accounts. Dangerous for autonomous AI agents.

Excessive Permissions: Seventy percent of all applications have an excessive number of privileged accounts. Far more than expected in the area of “least privilege” access and a major risk given today’s threat actors, as well as those AI agents mentioned above. Orphan Accounts: Forty percent of all accounts, across enterprise environments, were found to have outlived their authorized user. These “orphan” accounts are clearly unmanaged and likely unseen, and are ripe for the picking by threat actors and AI agents.

Those are just a few highlights from the full Identity Gap Snapshot. We encourage you to read the full report. What You Can Do If you are uncertain about how to address these (and similar) issues within your organization, or even how prevalent each one might be in your environment, our security researcher team has also published an Identity Security Readiness Checklist. If your organization is preparing for (or already participating in) the Agent AI transformation, the time to act is now.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

GitHub Breached — Employee Device Hack Led to Exfiltration of 3,800+ Internal Repos

GitHub on Tuesday said it’s investigating unauthorized access to its internal repositories after the notorious threat actor known as TeamPCP listed the platform’s source code and internal organizations for sale on a cybercrime forum. “While we currently have no evidence of impact to customer information stored outside of GitHub’s internal repositories (such as our customers’ enterprises, organizations, and repositories), we are closely monitoring our infrastructure for follow-on activity,” the Microsoft-owned subsidiary said . The company also noted that it will notify customers via established incident response and notification channels if any impact is discovered. The development comes after TeamPCP, a threat actor behind a string of software supply chain attacks targeting open-source packages, listed GitHub’s source code for sale for an asking price of no less than $50,000.

The alleged data dump is said to include about 4,000 repositories. “As always, this is not a ransom,” the group said in a post, according to screenshots shared by Dark Web Informer. “We do not care about extorting GitHub, 1 buyer and we shred the data on our end, it looks like our retirement is soon so if no buyer is found, we leak it for free.” In a follow-up update shared on X, GitHub said it detected and contained a compromise of an employee device involving a poisoned Microsoft Visual Studio Code extension. As a risk mitigation measure, the company has rotated critical secrets, while prioritizing highest-impact credentials.

“Our current assessment is that the activity involved exfiltration of GitHub-internal repositories only,” GitHub
said
. “The attacker’s current claims of ~3,800 repositories are directionally consistent with our investigation so far.”
GitHub did not disclose the name of the VS code extension, although it’s worth noting that
Nx Console
recently suffered a compromise that allowed threat actors to push a multi-stage credential stealer and a supply chain poisoning tool. The Nx team has since
acknowledged
that “very few users were compromised.”
Following the incident, an X account linked to TeamPCP,
xploitrsturtle2
,
stated: “GitHub knew for hours, they delayed telling you and they won’t be honest in the future. What an amazing run, it’s been an honor to play around with the cats over the past few months.” TeamPCP Compromises durabletask PyPI Package News of the sale comes as TeamPCP’s self-replicating malware campaign, known as Mini Shai-Hulud , continues to expand in reach with the compromise of durabletask, an official Microsoft Python client for the Durable Task workflow execution framework.

Three malicious package versions have been identified: 1.4.1, 1.4.2, and 1.4.3. “The attacker compromised a GitHub account via a previous attack, dumped GitHub secrets from a repository to which the user had access, and from there had access to the PyPi token to publish directly,” Google-owned Wiz said . The payload embedded into the package is a dropper, which is configured to fetch and run a second-stage payload (“rope.pyz”) from an external server (“check.git-service[.]com”). The malware is assessed to be an evolution of the payload deployed in connection with the compromise of the guardrails-ai package last week.

Specifically, it’s designed to activate a full-featured infostealer that’s capable of harvesting credentials associated with major cloud providers, password managers, and developer tools, and exfiltrating the data to the attacker-controlled domain. It’s worth noting that the stealer is configured to execute only on Linux systems. According to SafeDep , the 28KB Python stealer also attempts to read HashiCorp Vault KV secrets, unlock and dump 1Password and Bitwarden password vaults, and access SSH keys, Docker credentials, VPN configurations, and shell history. “If the machine is running inside AWS, it propagates itself to other EC2 instances using SSM.

If it’s inside Kubernetes, it propagates through kubectl exec,” Aikido Security said . “And if it detects Israeli or Iranian system settings, there’s a 1-in-6 chance it plays audio and then runs rm -rf /*.” “After enumerating SSM-managed instances, it uses SendCommand with the AWS-RunShellScript document to execute the rope.pyz payload on up to 5 other EC2 instances per profile,” per StepSecurity . “The propagation script downloads the payload from the primary C2, falling back to the secondary domain t.m-kosche[.]com, and runs it in the background.” Also notable is the use of the FIRESCALE mechanism to identify a backup command-and-control (C2) address in the event the primary domain is unreachable. It does this by searching GitHub’s public commit messages for the pattern “FIRESCALE ." and extracting the C2 information from it.

Details of this technique were previously highlighted by Hunt.io. Because the worm propagates using tokens stolen from infected environments, the number of affected packages is expected to grow. Any machine or pipeline that installed an affected version of the package should be treated as fully compromised. “The package is downloaded roughly 417,000 times a month, and the malicious code runs automatically the moment the package is imported, with no error messages and no visible signs of compromise,” Endor Labs researcher Peyton Kennedy said .

Update The LAPSUS$ cybercrime group has teamed up with TeamPCP for a joint sale of GitHub repositories for $95,000. “Everything for the main platform is there,” says an accompanying statement, per screenshots from Dark Web Informer. “No ransom, we do not care about extorting GitHub. If no buyer is found, we leak for free.” According to security researcher Rakesh Krishnan, the leaked repositories are related to GitHub Actions, agentic workflows, Copilot internal projects, CodeQL tools, internal infrastructure, security tools, marketing, and GitHub-related programs like Codespaces and Dependabot.

Also included is a Rails controller and a Pull Requests Controller that are responsible for managing organizations and every pull request. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Typosquatting Is No Longer a User Problem. It’s a Supply Chain Problem

AI-generated lookalike domains are now embedded inside the third-party scripts running on your web properties. Here’s why your current stack can’t see them, and what detection actually requires. Download the CISO Expert Guide to Typosquatting in the AI Era → TL;DR Typosquatting is no longer a user problem. Attackers now embed lookalike domains inside legitimate third-party scripts.

No mistyped URL required, no server breach needed. AI broke the economics of defense. LLMs generate thousands of convincing domain variants in minutes; full campaign deployment takes under ten. Malicious package uploads jumped 156% last year.

Manual vetting is dead. Your security stack can’t see this. Firewalls, WAFs, EDR, and CSP have no visibility into what approved scripts do once they execute in the browser. The Trust Wallet attack proved it.

$8.5M stolen in 48 hours through a trojanized Chrome extension. No alert fired, not because something failed, but because nothing was watching. This isn’t a crypto story On December 24, 2025, Trust Wallet users started losing money. Not because they clicked a phishing link.

Not because they reused a weak password. Not because they did anything wrong at all. A self-replicating npm worm called Shai-Hulud had spent months harvesting developer credentials: GitHub tokens, npm publishing keys, and Chrome Web Store API credentials. Those keys allowed attackers to push a trojanized version of the Trust Wallet Chrome extension through official channels.

Chrome’s verification passed it. The malicious extension executed entirely inside users’ browsers, silently capturing seed phrases and transmitting them to the attacker’s infrastructure at a domain disguised as Trust Wallet’s own analytics endpoint. Within 48 hours, 2,500 wallets had been drained. Total loss: $8.5 million.

No server was breached. No alert ever fired. Strip away the seed phrases and what remains is this: a trusted browser-delivered asset was silently modified to intercept sensitive user data before the legitimate application could process it, invisible to server logs, firewalls, WAFs, and EDR. Not because those controls were misconfigured, but because they were never designed to observe what happens inside a browser session, even a poisoned one.

Swap seed phrases for payment card data. Swap the Chrome extension for a marketing pixel, a support widget, or an A/B testing framework. The attack is identical. A typical e-commerce checkout page runs 40-60 third-party scripts.

Each is a trusted connection. The same thing could happen there. How typosquatting got here: three phases What makes Phase 3 a genuine evolution isn’t just sophistication, it’s economics. LLMs can generate thousands of convincing domain variations in minutes.

Homograph attacks combine Latin, Cyrillic, and Greek characters to produce domains that appear visually identical in browser address bars while evading string-distance detection. Domain registration, SSL issuance, and full campaign deployment now take under ten minutes. Sonatype’s data shows malicious package uploads to open-source repositories jumped 156% year-over-year, so volume alone has made manual vetting structurally impossible. Three attacks that show the pattern Typosquatting targets the domain layer, package compromise targets the supply chain, and browser-runtime abuse targets what trusted code does after it executes.

Trust Wallet Chrome Extension (December 2025) Shai-Hulud harvested developer credentials over months before pushing a trojanized extension through official Chrome Web Store channels. The malicious extension captured seed phrases and transmitted them to a lookalike analytics domain. 2,500 wallets drained.

$8.5M lost. Detection time: zero. No server-side visibility exists for browser-runtime execution. 2.

chalk/debug npm attack (September 2025) A phishing email targeting a single package maintainer gave attackers access to 18 trusted JavaScript libraries , including chalk and debug, with over two billion combined weekly downloads. Within 16 minutes, malicious code was injected across all of them, hooking browser APIs to silently intercept network traffic and wallet interactions. Fast containment limited direct losses to around $500. The exposure window wasn’t the story.

Two billion downloads was. 3. Solana Web3.js Library Attack (December 2024) Attackers compromised a publish-access account for the @solana/web3.js npm library through a phishing campaign, then published malicious versions containing a hidden function that intercepted private keys mid-transaction and exfiltrated them to an attacker-controlled domain registered just days before the attack. Any application that auto-updated within the five-hour window shipped the backdoor directly to its users.

Nearly $200,000 drained before discovery. How the compromise happens: trust replaces deception Classic social engineering needed a human in the loop, someone to mistype a URL, click a link, approve a prompt, trust a sender. The attacker’s job was to manufacture trust in the moment. The current generation of attacks skips that step entirely.

Trust is no longer manufactured, it’s inherited. Your build pipeline already trusts npm. Your vendor already trusts their CDN. Your browser already trusts the vendor.

The attacker doesn’t need to deceive anyone; they only need to insert themselves anywhere along a chain of trust that’s already been granted. Call it supply chain subversion - the deception isn’t aimed at a person; it’s aimed at the dependency graph. The blind spot in your security stack A marketing vendor integrated into your web properties references a JavaScript CDN registered six weeks ago. Valid SSL.

Recognizable domain. Then the script is quietly updated. On your payment page, the browser silently loads the modified script. An invisible overlay intercepts keystrokes before they reach your application.

Your server logs record a normal session. No alert fires. CSP is the control most often cited as the defense. But CSP is a guest list, not a behavior monitor.

An allowlisted script that reads your payment form fields and exfiltrates the data is still fully permitted, because the origin is trusted. CSP handles the connection. It cannot handle the execution. Malicious behavior in 2026 is deferred to runtime by design.

Shai-Hulud’s packages remained dormant during automated scanning, only activating under specific runtime conditions. Static analysis cannot catch payloads loaded dynamically after execution begins. What detection actually requires IBM’s 2025 Cost of a Data Breach Report found that the average breach takes 241 days to identify. In supply chain attacks where malicious behavior executes silently in browser memory, that window can be significantly longer, unless you’re watching the runtime.

Detection requires observing what scripts actually do after they execute: which domains they communicate with, which page elements they access, and how their behavior deviates from established baselines. That’s runtime behavioral monitoring, the one layer most enterprise security stacks currently lack. The characteristics to monitor for: Unexpected data exfiltration: Scripts reading form fields and transmitting values to domains outside your approved list Dynamic domain resolution: Scripts calling domains registered recently or resolving differently than their baseline Behavioral drift: A script that behaved normally last week is now accessing different page elements this week. Detecting a suspicious domain in your dependency tree is necessary, but not sufficient.

The harder problem is understanding what the script loaded from that domain actually does. AI-generated obfuscation is now specifically engineered to defeat static analysis: the code passes linting, mimics legitimate minified libraries, and produces no signature matches. Closing that gap requires behavioral deobfuscation at runtime, executing the script in an instrumented environment and tracing its actual behavior, not attempting to read its source. That means surfacing what a script actually accesses: form fields, cookies, network endpoints - regardless of how heavily obfuscated the source is.

It’s the approach Reflectiz built its AI deobfuscator around, and it’s detailed in the guide below. Your action plan If you’re not sure where to start, prioritize by exposure: payment pages first, authentication pages second, everything else after. Here’s a practical sequence: This week: Audit third-party scripts for recently registered CDN domains in your dependency chain Review CSP reports, not just violations, but what your approved origins are actually doing Identify which pages handle sensitive data (payment, login, PII forms) and prioritize monitoring there first This month: Deploy runtime behavioral monitoring for payment and authentication pages Establish behavioral baselines for all approved third-party scripts Implement subresource integrity (SRI) checks where scripts are self-hosted or cacheable Proactive domain registration, strict CSP, and enforced DMARC are necessary. They cover domain registration, script delivery, and email impersonation.

None of them covers what happens after an approved vendor script is silently modified. That’s the gap most teams don’t see until it’s too late. The controls above tell you what to do. Mapping them to your actual environment, vendor inventory, and compliance obligations is where execution stalls.

Reflectiz has published a CISO Expert Guide with the complete framework: domain governance, foundational controls, runtime behavioral monitoring, and a phased implementation roadmap built around that gap. Download the guide here → Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Microsoft Releases Mitigation for YellowKey BitLocker Bypass CVE-2026-45585 Exploit

Microsoft on Tuesday released a mitigation for a BitLocker bypass vulnerability named YellowKey following its public disclosure last week. The zero-day flaw, now tracked as CVE-2026-45585 , carries a CVSS score of 6.8. It has been described as a BitLocker security feature bypass. “Microsoft is aware of a security feature bypass vulnerability in Windows publicly referred to as ‘YellowKey,’” the tech giant said in an advisory.

“The proof of concept for this vulnerability has been made public, violating coordinated vulnerability best practices.” The issue impacts Windows 11 version 26H1 for x64-based Systems, Windows 11 Version 24H2 for x64-based Systems, Windows 11 Version 25H2 for x64-based Systems, Windows Server 2025, and Windows Server 2025 (Server Core installation). YellowKey was disclosed by a security researcher named Chaotic Eclipse (aka Nightmare-Eclipse). It essentially involves placing specially crafted ‘FsTx’ files on a USB drive or EFI partition, plugging the USB drive into the target Windows computer with BitLocker protections turned on, rebooting into the Windows Recovery Environment (WinRE), and triggering a shell with unrestricted access by holding down the CTRL key. “If you did everything properly, a shell will spawn with unrestricted access to the BitLocker protected volume,” the researcher noted in a GitHub post.

Redmond noted that successful exploitation could permit an attacker with physical access to sidestep the BitLocker Device Encryption feature on the system storage device and gain access to encrypted data. “To break encryption, YellowKey abuses a behavioral trust assumption in the recovery interface, allowing attackers to spawn an unrestricted shell with full access to the encrypted volume during the pre-boot recovery sequence,” LevelBlue said . “And because YellowKey doesn’t require software installation, existing credentials, or network access to break encryption, any machine that has a USB port and can be rebooted can be a target.” To address the risk, the following mitigations have been outlined: Mount the WinRE image on each device. Mount the system registry hive of the mounted WinRE image.

Modify BootExecute by removing “autofstx.exe” value from Session Manager’s BootExecute REG_MULTI_SZ value. Save and unload Registry hive . Unmount and commit the updated WinRE image. Reestablish BitLocker trust for WinRE.

“Specifically, you prevent the FsTx Auto Recovery Utility, autofstx.exe, from automatically starting when the WinRE image launches,” security researcher Will Dormann said . “With this change, the Transactional NTFS replaying that deletes winpeshl.ini no longer happens. It also recommends switching from TPM-only to TPM+PIN.” Microsoft also emphasized that users can be safeguarded against exploitation by configuring BitLocker on already encrypted devices with “TPM-only” protector by switching to “TPM+PIN” mode via PowerShell, the command line, or the control panel. This will require a PIN to decrypt the drive at startup, effectively backing YellowKey attacks.

On devices that are not encrypted, administrators are advised to enable the “Require additional authentication at startup” option via Microsoft Intune or Group Policies and ensure that “Configure TPM startup PIN” is set to “Require startup PIN with TPM.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Grafana GitHub Breach Exposes Source Code via TanStack npm Attack

Grafana Labs, on May 19, 2026, said an investigation into its recent breach found no evidence of customer production systems or operations being compromised. It said the scope of the incident is limited to the Grafana Labs GitHub environment, which includes public and private source code along with internal GitHub repositories. “After the initial assessment, we found that in addition to source code, the downloaded content included GitHub repositories that some Grafana Labs teams use to collaborate on and store internal operational information and other details about our business,” it said . “This includes business contact names and email addresses that would be exchanged in a professional relationship context, not information pulled from or processed through the use of production systems or the Grafana Cloud platform.” The open-source visualization software maker also noted that the breach originated from the TanStack npm supply chain attack orchestrated by TeamPCP, which also hit OpenAI and Mistral AI, and that it detected the activity on May 11, 2026.

“We performed analysis and quickly rotated a significant number of GitHub workflow tokens, but a missed token led to the attackers gaining access to our GitHub repositories,” it said. “A subsequent review confirmed that a specific GitHub workflow we originally deemed not impacted had, in fact, been compromised.” The company said it subsequently received an extortion demand from an unnamed threat actor on May 16, but opted against paying the ransom as there is no guarantee that the stolen data would actually be deleted, and could act as a catalyst for future campaigns. Since then, Grafana has taken steps to rotate automation tokens, implement enhanced monitoring, audit all commits for signs of malicious activity, and bolster its overall GitHub security posture. It’s worth mentioning here that a data extortion crew named CoinbaseCartel listed Grafana Labs on its dark web site on May 15, 2026.

The Hacker News has contacted Grafana for comment, and we will update the story if we hear back. The development comes as GitHub said it’s investigating unauthorized access to its internal repositories after the notorious threat actor known as TeamPCP listed the platform’s source code and internal organizations for sale on a cybercrime forum. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Trapdoor Android Ad Fraud Scheme Hit 659 Million Daily Bid Requests Using 455 Apps

Cybersecurity researchers have disclosed details of a new ad fraud and malvertising operation dubbed Trapdoor targeting Android device users. The activity, per HUMAN’s Satori Threat Intelligence and Research Team, encompassed 455 malicious Android apps and 183 threat actor-owned command-and-control (C2) domains, turning the infrastructure into a pipeline for multi-stage fraud. “Users unwittingly download a threat actor-owned app, often a utility-style app like a PDF viewer or device cleanup tool,” researchers Louisa Abel, Ryan Joye, João Marques, João Santos, and Adam Sell detailed in a report shared with The Hacker News. “These apps trigger malvertising campaigns that coerce users into downloading additional threat actor-owned apps.

The secondary apps launch hidden WebViews, load threat actor-owned HTML5 domains, and request ads.” The campaign, the cybersecurity company added, is self-sustaining in that an organic app install turns into an illicit revenue generation cycle that can be used to fund follow-on malvertising campaigns. One notable aspect of the activity is the use of HTML5-based cashout sites, a pattern observed in prior threat clusters tracked as SlopAds , Low5 , and BADBOX 2.0 . At the peak of the operation, Trapdoor accounted for 659 million bid requests a day, with Android apps linked to the scheme downloaded more than 24 million times. Traffic associated with the campaign primarily originated from the U.S., which took up more than three-fourths of the traffic volume.

“The threat actors behind Trapdoor also abuse install attribution tools (technology designed to help legitimate marketers track how users discover apps) to enable malicious behavior only in users acquired through threat actor-run ad campaigns, while suppressing it for organic downloads of the associated apps,” HUMAN said. Trapdoor combines two disparate approaches, malvertising distribution and hidden ad-fraud monetization, where unsuspecting users end up downloading bogus apps masquerading as seemingly harmless utilities that act as a conduit for serving malicious ads for other Trapdoor apps, which are designed to perform automated touch fraud, as well as launch hidden WebViews, load threat actor-controlled washout domains, and request ads. It’s worth noting that only the second-stage app is used to trigger fraud. Once the organically downloaded app is launched, it serves fake pop-up alerts that mimic app update messages to trick users into installing the next-stage app.

This behavior also indicates that the payload is activated only for those who fall victim to the advertising campaign. In other words, anybody who downloads the app directly from the Play Store or sideloads it will not be targeted. Besides this selective activation technique, Trapdoor employs various anti-analysis and obfuscation techniques to sidestep detection. “This operation uses real, everyday software and multiple obfuscation and anti-analysis techniques - such as impersonating legitimate SDKs to blend in - to help fuse malvertising distribution, hidden ad fraud monetization, and multi-stage malware distribution,” Lindsay Kaye, vice president of threat intelligence at HUMAN, said.

Following responsible disclosure, Google has taken steps to remove all identified malicious apps from the Google Play Store, effectively neutralizing the operation. The complete list of Android apps is available here . “Trapdoor shows how determined fraudsters turn everyday app installs into a self-funding pipeline for malvertising and ad fraud,” Gavin Reid, chief information security officer at HUMAN, said. “This is another instance of threat actors co-opting legitimate tools - such as attribution software - to aid in their fraud campaigns and help them evade detection.” “By chaining together utility apps, HTML5 cashout domains, and selective activation techniques that hide from researchers, these actors are constantly evolving, and our Satori team is committed to tracking and disrupting them at scale.” Found this article interesting?

DirtyDecrypt PoC Released for Linux Kernel CVE-2026-31635 LPE Vulnerability

Proof-of-concept (PoC) exploit code has now been released for a recently patched security flaw in the Linux kernel that could allow for local privilege escalation (LPE). Dubbed DirtyDecrypt (aka DirtyCBC), the vulnerability was discovered and reported by the Zellic and V12 security team on May 9, 2026, only to be informed by the maintainers that it was a duplicate of a vulnerability that had already been patched in the mainline. “It’s a rxgk pagecache write due to missing COW [copy-on-write] guard in rxgk_decrypt_skb,” Zellic co-founder Luna Tong (aka cts and gf_256) said in a description shared on GitHub. Although the CVE identifier was not disclosed, the vulnerability in question is CVE-2026-31635 (CVSS score: 7.5) based on the fact that the NIST National Vulnerability Database (NVD) includes a link to the DirtyDecrypt PoC in its CVE record.

“The specific fault sits in rxgk_decrypt_skb(), the function that decrypts an incoming sk_buff (socket buffer) on the receive side,” Moselwal said . “In this code path the kernel handles memory pages that are partly shared with the page cache of other processes – a normal Linux optimisation protected by copy-on-write: as soon as a write to a shared page happens, a private copy is made beforehand so that the write doesn’t bleed into another process’s data.” The absence of this COW guard in rxgk_decrypt_skb means that data gets written to the memory of privileged processes or, depending on the exploit path, to the page cache of privileged files, such as etc/shadow, /etc/sudoers, or a SUID binary, leading to local privilege escalation. DirtyDecrypt impacts only distributions with CONFIG_RXGK enabled, such as Fedora, Arch Linux, and openSUSE Tumbleweed. In containerized environments, worker nodes running a vulnerable version of Linux could provide a pathway to escape the pod.

The vulnerability, per Zellic, is assessed to be a variant of Copy Fail (CVE-2026-31431), Dirty Frag aka Copy Fail 2 (CVE-2026-43284 and CVE-2026-43500), and Fragnesia (CVE-2026-46300), all of which grant root access on vulnerable systems. Copy Fail , a local privilege escalation flaw in the AF_ALG cryptographic socket interface, was disclosed by researchers at Theori on April 29, 2026. It was followed by Dirty Frag a week later. Dirty Frag expands on Copy Fail with two page-cache write primitives.

However, security researcher Hyunwoo Kim was forced to go ahead with public disclosure after the agreed-upon embargo window ended prematurely when a merged patch for CVE-2026-43284 on May 5 led another researcher, who was unaware of the embargo, to analyze and independently publish details of the defect. “I read the commit, recognized the xfrm ESP-in-UDP MSG_SPLICE_PAGES no-COW path against shared pipe pages as an LPE primitive, and built a PoC,” the researcher, who goes by the online aliases 0xdeadbeefnetwork and afflicted.sh, noted . “The work is n-day weaponization from a public upstream commit, which is standard practice once a security-relevant fix lands in a public tree.” Fragnesia is another variant of Dirty Frag and impacts the XFRM ESP-in-TCP subsystem. But the outcome is the same: it allows unprivileged local attackers to modify read-only file contents in the kernel page cache and obtain root privileges.

The development dovetails with the discovery of an LPE flaw in the Linux PackageKit daemon ( CVE-2026-41651 aka Pack2TheRoot, CVSS score: 8.8) and an improper privilege management flaw in the kernel ( CVE-2026-46333 aka ssh-keysign-pwn , CVSS score: 5.5), which allows an unprivileged local user to read root-owned secrets like SSH private keys. Various Linux distributions have released advisories for CVE-2026-46333 - AlmaLinux Amazon Linux CloudLinux Fedora Gentoo Red Hat SUSE Ubuntu Kernel Killswitch? The flurry of new disclosures within a span of a few weeks has prompted Linux kernel developers to review a proposal for an emergency “killswitch” that would allow administrators to disable vulnerable kernel functions at runtime until a patch for a zero-day vulnerability becomes available. “Killswitch lets a privileged operator make a chosen kernel function return a fixed value without executing its body, as a temporary mitigation for a security bug while a real fix is being prepared,” according to a proposal submitted by Linux kernel developer and maintainer Sasha Levin.

“The function returns the operator-supplied value and nothing else runs in its place. There is no allowlist, no return-type check; if the kprobe layer accepts the symbol, killswitch engages it. Once engaged, the change is in effect on every CPU until disengage is written or the system reboots.” Rocky Linux Debuts Security Repository Rocky Linux, for its part, has introduced an optional security repository that allows the distribution to ship urgent security fixes quickly, particularly in scenarios where severe vulnerabilities become public knowledge before coordinated upstream fixes arrive. “The repository is disabled by default.

That’s intentional,” the maintainers said . “The default Rocky Linux experience stays exactly what it has always been: predictable, stable, and fully upstream-compatible. Administrators who want access to accelerated fixes can opt in when they need it.” The security repository specifically caters to “specific, narrow” cases where a significant vulnerability is public, exploit code exists, and upstream patches are not available yet. Rocky Linux has emphasized that it’s not a replacement for the regular release process.

“If we push a fix and upstream decides not to address it, the next upstream kernel release will supersede our patched version,” the maintainers added. “Users who haven’t version-locked their kernel will, at that point, no longer have our fix. That’s the trade-off we accepted when building this.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.