Search This Blog
Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Load More
Trendy Right Now

Popular Posts

Showing posts with label Supply Chain Attack. Show all posts
Third-Party Risk
Cloud Security CRM Data Exposure Data Breach Icarus Extortion Group Klue Breach OAuth Token Theft Salesforce Security Supply Chain Attack Third-Party Risk

Klue Breach Exposes Cybersecurity Firms to Supply Chain Risk


 

Klue, which provides competitive intelligence services, has been implicated in a supply chain compromise as an example of how trusted third-party integrations can lead to high-impact attacks on enterprise systems. As a consequence of the incident, which occurred on June 11, unauthorized access to Klue's backend infrastructure allowed threat actors to deploy malicious code designed to harvest authentication tokens related to customer integrations, resulting in the theft of customer authentication tokens.

Security firms Huntress and Recorded Future confirmed that they were among the organizations affected by the breach, which has drawn attention across the cybersecurity industry. In addition, investigations found that the attackers accessed and extracted customer data through connected business platforms by leveraging compromised integrations.

An interconnected SaaS ecosystems present significant risks, where a single compromise can rapidly extend beyond the initial target and affect multiple downstream organizations, thereby increasing the risk associated with the ecosystem. 

In addition, details indicate that the compromise went beyond Klue's internal environment and into customer-connected cloud platforms via an unlawfully accessed legacy integration credential. Threat actors accessed Salesforce instances by leveraging the credential on June 12 to synchronize customer data across linked cloud environments, leading to unauthorized access to customer information. 

Despite the fact that Klue has not revealed the exact number of individuals or organizations affected, multiple organizations, including Gong, Jamf, HackerOne, Insurity, OneTrust, Snyk, Sprout Social, Tanium, Huntress, and Recorded Future, have acknowledged exposure. As a result of the hacking, the cybercrime group Icarus has claimed responsibility for the incident. If a ransom demand is not met, the stolen data will be released publicly. 

According to preliminary assessments, the accessed records primarily contain business-related information about customers, such as names, e-mail addresses, phone numbers, job titles, and some account details. There has been an increasing trend for threat actors to target middleware and integration providers as strategic aggregation points, leading to a single compromised credential or service connection being used as a gateway into the cloud data environments of many downstream companies. 

According to Klue, CrowdStrike has been engaged as part of its response efforts, and affected integrations have been suspended while containment and forensic investigations are ongoing. As containment efforts progressed, the operation footprint of the intrusion became increasingly apparent. Upon discovering the compromise, Klue revoked all customer OAuth tokens and suspended integrations with various enterprise platforms, such as Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive, and Slack, as a means to prevent further unauthorized activity from taking place. 

Upon further investigation, it was discovered that the attackers had used compromised integration access to extract extensive data through Salesforce's REST API by leveraging compromised integration access. ReliaQuest researchers observed unusually high volumes of CRM queries over a 24-hour period. These included a concentrated burst of nearly 1,000 requests within 15 minutes and sustained extraction activity that lasted over six hours. 

Salesforce mentioned that the findings caused the application Klue Battlecards to be disabled on June 17 as a result of abnormal behavior that might have exposed customer information. Huntress reported that among those organizations publicly confirming impact, accessed records contained only business-facing information like contact information, quotations, and sales communications. There was no evidence that threat intelligence, authentication credentials, payment information, or product engineering systems were exposed. 

Recorded Future stated in a similar manner that the incident affected specific customer and contractual data fields, but not its internal infrastructure and critical operational environments. According to the investigators, the activity was confined to Klue-Salesforce integration rather than the affected companies' networks, distinguishing the incident from broader enterprise compromises. 

In addition, Huntress reported receiving extortion messages from an individual whose communications referenced identifiers previously associated with the Icarus extortion group. A combination of the stolen datasets and material advertised on the Icarus-operated leak infrastructure has strengthened industry assessments linking the group to the attack, however, the intrusion appears to be distinct from other campaigns attributed to actors such as ShinyHunters or UNC6395 that were previously attributed to the group. This incident serves as another reminder that modern cybersecurity risks extend beyond an organization's own perimeter and into a wider ecosystem of trusted applications, integrations, and service providers.

A growing number of attackers are focusing on high value aggregation points within interconnected cloud environments, increasing the need for security teams to strengthen oversight of third-party access, continuously monitor privileged integrations, and swiftly revoke exposed credentials when suspicious activity occurs. 

The investigation into the breach is ongoing, but the event underscores the necessity of making supply chain security a core part of enterprise security rather than a secondary risk, especially because a single compromised connection can create consequences across multiple organizations simultaneously.
Read more »
Zero-Day Exploit
Argument Injection Credential Theft Cyber Threats Git Repository Security Gogs Vulnerability Open Source Security Remote Code Execution Supply Chain Attack Zero-Day Exploit

Gogs Zero-Day Vulnerability Raises Alarm Over Server Security


 

Researchers have discovered a zero-day vulnerability in Gogs, the widely used self-hosted Git repository management platform, that may allow authenticated users to escalate their privileges on vulnerable servers by leveraging this vulnerability to execute remote code. 

In addition to affecting current Gogs releases, this vulnerability is classified as a critical argument injection weakness that poses a particular risk to distributed software development and collaboration deployments that are Internet-accessible. As a result of security analysis, the attack can be carried out without administrative privileges and, under default configurations, the attacker may only need a standard user account to compromise the underlying host. 

The finding highlights the fact that seemingly routine source code management operations can become high-impact attack vectors when exploitable flaws intersect with permissive default settings and exposed development infrastructure, which has not been officially patched at the time of disclosure. Due to the close alignment between the attack path and Gogs' default deployment behaviour, the exposure becomes especially significant. 

A Rapid7 researcher stated that open registration of users and the creation of unrestricted repositories enable an external actor to establish the necessary conditions for exploitation without requiring privileged access or assistance from other users. An application-wide flaw exists in the application's handling of repository merge operations. If the branch name is specially crafted, malicious arguments can be injected into the git rebase process during the "Rebase before merging" workflow by using a specially crafted branch name. 

By abusing Git's --exec parameter, an attacker can force arbitrary shell commands to run on the host system under the security context of the Gogs service account. As researchers noted, the consequences of the compromise extend far beyond a single repository compromise, allowing threat actors to access private repositories belonging to other users, extract sensitive credentials such as password hashes, API tokens, SSH keys, multi-factor authentication secrets, and move laterally across connected systems, as well as alter source code stored on the system. 

While Burgess indicates that Gogs has addressed several argument injection vulnerabilities in recent years, this newly discovered vulnerability stems from a different code path within the Merge() function, which was not addressed. Moreover, users with write permissions in repositories with rebase merging are also at risk of exploiting this vulnerability, while environments which restrict repository creation remain vulnerable if attackers can obtain write access to qualifying projects. 

While the flaw was reported to the maintainer in March 2026, it remains unpatched as of the date of publication, making deployments across Windows, Linux, and macOS vulnerable to exploitation. Approximately 1,100 Gogs instances are currently exposed to the internet, according to Rapid7, but the true number is likely to be substantially greater due to the prevalence of deployments that operate behind VPNs and internal enterprise networks.

Additionally, the disclosure has brought to the vendor's attention concerns relating to its response timeframe. In March 2026, Burgess reported the vulnerability to the Gogs maintainers and received an acknowledgement on March 28, but no security update has been released since then. Given the platform's existing exposure footprint, this delay is particularly noteworthy. 

Data from Shadowserver indicates that more than 2,400 publicly accessible Gogs instances are currently located in Asia and Europe, with the highest concentrations occurring in the region, while Shodan indexes over 1,000 internet-facing systems that exhibit identifiable Gogs signatures. An incident of this type is reminiscent of one that occurred with CVE-2025-8110, another remote code execution vulnerability that was exploited by hackers before patches were available. 

A vulnerability discovered by Wiz Research during an investigation into a compromised Gogs deployment ultimately led to the U.S. Government's Cybersecurity and Infrastructure Security Agency (CISA), which classified it as actively exploited and directed federal agencies to secure affected systems, resulting in a significant threat model. 

In addition, this new flaw undermines the trust boundaries underlying shared Git hosting environments, making it a similar serious threat model. It is common for businesses, universities, and development teams to deploy multi-user software environments, where a single, authenticated account can control the underlying server infrastructure without having to gain access to another user's repository. 

If code execution is achieved, an attacker will be able to access all repository files hosted on the instance, extract authentication credentials stored within the backend databases, enter adjacent network resources, and manipulate source code on the file system. 

Gogs service accounts usually maintain unrestricted read and write rights across repositories that are stored under the same repository root; therefore, malicious modifications can bypass platform-level audit mechanisms and are difficult to identify in environments where commit-signing enforcement does not exist. It was also noted that exploitation can be highly practical and automated using publicly available tools, enabling attacks to be carried out within seconds with minimal forensic evidence remaining. 

Gogs' implementation of the "Rebase before merging" feature has resulted in the issue, as it internally invokes the git rebase command to create a linear project history by replaying commits. With the --exec parameter, Git executes shell commands after each replayed commit, creating the exploitation primitive when malicious input is incorrectly handled. 

While the rebase merge functionality is disabled by default, the repository can enable the feature through the project owner's settings, and new repositories are automatically assigned ownership to their creators, ensuring that abuse does not occur. Despite deployments that restrict repository creation, vulnerable code paths can still be exploited to execute remote commands by users who have access to repositories that support rebase merging.

Newly disclosed vulnerabilities in development platforms such as Gogs serve as a timely reminder that these platforms can magnify the impact of a single security weakness across entire software ecosystems. Considering the lack of a patch and the requirement for limited user privileges to exploit Gogs in common deployment configurations, organisations relying on Gogs should carefully evaluate repository permissions, disable unnecessary registration and repository creation features, and closely monitor merging activity. 

In light of the continued reliance on software supply chains as a critical component of business operations, the security of source code infrastructure has become more than an issue of development it has become a fundamental security priority that requires continuous monitoring, prompt remediation, and proactive defence.
Read more »
Supply Chain Attack
Backdoor GitHub malware Megalodon Supply Chain Attack

Megalodon Malware Backdoors 5,500+ GitHub Repos in 6-Hour Supply-Chain Attack

 

On May 18, 2026, a massive automated supply-chain attack codenamed Megalodon struck GitHub, injecting malicious CI/CD backdoors into more than 5,500 repositories in under six hours. Security firm SafeDep discovered the campaign, which pushed 5,718 malicious commits to 5,561 distinct repositories using throwaway accounts with randomized eight-character usernames, marking one of the most aggressive GitHub Actions poisoning campaigns ever recorded. 

The attackers forged bot-like author identities—build-bot, auto-ci, ci-bot, and pipeline-bot—using emails build-system@noreply.dev and ci-bot@automated.dev to mimic routine automated CI maintenance. Between approximately 11:36 and 17:48 UTC on May 18, these fake commits slipped into repositories without triggering immediate suspicion, as they appeared to be ordinary build optimization updates. 

Megalodon deployed two distinct GitHub Actions workflow variants sharing the same command-and-control server at 216.126.225.129:8443. The SysDiag variant added a new ci.yml file triggering on every push and pull_request_target, ensuring automated execution on any commit across all branches. The Optimize-Build variant replaced existing workflows with a workflow_dispatch trigger, creating a dormant backdoor that attackers can silently activate on demand via the GitHub API, producing zero visible CI runs and no failed builds. 

The base64-encoded 111-line bash payload conducted aggressive credential harvesting, exfiltrating all CI environment variables, AWS credentials, GCP access tokens, Azure credentials, SSH private keys, Docker and Kubernetes configurations, API keys, database connection strings, GitHub Actions tokens, GitLab CI/CD tokens, and dozens of other secrets while scanning source code for more than 30 secret regex patterns. 

The attack's most critical downstream impact targeted Tiledesk, an open-source live chat platform, where the attacker compromised the repository and replaced the legitimate Docker build workflow. The unsuspecting maintainer published @tiledesk/tiledesk-server versions 2.18.6 through 2.18.12 to npm, propagating the backdoor to the package registry. Organizations should immediately revert malicious commits from build-system@noreply.dev or ci-bot@automated.dev, rotate all secrets, audit cloud logs for anomalous OIDC requests, check Actions tabs for unexpected workflow_dispatch executions, and pin GitHub Actions to specific commit SHAs.
Read more »
TanStack
Cyber Attacks GitHub Report Breach Supply Chain Attack TanStack

GitHub Repo Breach Traced to TanStack NPM Supply-Chain Attack

 

GitHub has confirmed that a breach of its internal repositories is directly linked to the TanStack npm supply-chain attack, demonstrating how a single compromised developer tool can cascade into a major security incident. The company stated that the intrusion began when an employee installed a malicious version of the Nx Console Visual Studio Code extension, which had been poisoned during the wider TanStack compromise. This attack chain allowed threat actors to gain initial access to GitHub's internal infrastructure, ultimately exposing approximately 3,800 internal repositories to unauthorized access. 

The original TanStack attack occurred on May 11, 2026, when the TeamPCP threat group compromised 42 npm packages and published 84 malicious versions in just six minutes. The attackers exploited a sophisticated combination of GitHub Actions vulnerabilities, including a "Pwn Request" attack using pull_request_target abuse, cache poisoning across fork-to-base trust boundaries, and OIDC token extraction from runner memory. This technique produced the first npm supply-chain attack with valid SLSA Build Level 3 attestations, making the malicious packages appear completely legitimate to security scanners and developers. 

The malicious Nx Console extension version 18.95.0 was available on the Visual Studio Marketplace for approximately 18 minutes and on OpenVSX for another 36 minutes before being removed. Despite the short window, the poisoned extension deployed a payload designed to steal credentials and secrets from developer environments, targeting npm, AWS, Kubernetes, GitHub, GCP, and Docker platforms. The Nx development team confirmed that one of their developers was compromised through the TanStack supply-chain leak, which exposed GitHub credentials through the GitHub CLI, allowing attackers to run workflows on their repository as a contributor. 

GitHub's Chief Information Security Officer Alexis Wales confirmed that the company secured the compromised device and rotated critical secrets, prioritizing the highest-impact credentials first. While GitHub has not officially attributed the attack to a specific group, TeamPCP claimed access to GitHub source code and approximately 4,000 repositories of private code on the Breached forum, demanding at least $50,000 for the stolen data. The incident also affected other organizations, including UiPath, Guardrails AI, OpenSearch, and Grafana Labs, which confirmed its GitHub environment breach originated from the same TanStack attack. 

This incident highlights the severe risks of modern software supply chains, where one compromised dependency can ripple across thousands of developers and organizations faster than security teams can respond. The attack demonstrates that even organizations with strong security practices, including two-factor authentication, remain vulnerable to sophisticated supply-chain attacks that exploit trust relationships between packages, build tools, and automated workflows. Developers and security teams must now prioritize hardening CI/CD pipelines,Token rotation, extension verification, and continuous monitoring of package updates as potential attack vectors.
Read more »
WordPress Security
Admin Account Compromise Cyber Threats Data Breach Payment Card Skimmer Plugin Vulnerability Supply Chain Attack Website Takeover WooCommerce Security WordPress Security

WordPress Plugin Security Failure Opens Door to Payment Data Theft


 

Cybercriminals have been actively exploiting a critical flaw in the widely deployed Funnel Builder plugin in order to harvest customer payment information during online transactions in a newly uncovered attack campaign, once again highlighting the security risks that face the WordPress e-commerce ecosystem. 

According to security researchers, attackers are exploiting this vulnerability to silently inject malicious code into WooCommerce checkout pages, transforming legitimate payment workflows into points of data collection that are used to steal payment card information. 

Approximately 40,000 websites are reported to have been infected with the plugin, posing a serious threat to online retailers as the vulnerability exposes sensitive customer data, including payment card information, CVV number, billing information, and other personal identifiers, to unauthorized access. Linked to the discovery was an extensive security incident affecting the WordPress ecosystem, in which researchers discovered malicious code embedded within several widely used plugins, allowing attackers to gain access to vulnerable sites at an administrator level. 

The full scope of the attack is still being investigated, but early indications indicate that a number of plugins with significant installations may have been affected, thereby expanding the attack surface substantially. 

A threat actor may be able to bypass conventional authentication controls by create privileged accounts covertly and gain persistence over website environments. This allows them to manipulate content, exfiltrate sensitive business and customer data, deploy additional malware payloads, or take full control of the affected platform by manipulating site content. It is important to understand how a single compromised plugin component can quickly become a source of global supply chain security concerns, presenting a heightened risk to both website operators and their users. 

Based on further analysis, it was found that the vulnerability emerged from an unauthenticated flaw in Funnel Builder versions before 3.15.0.3, which enabled attackers to manipulate key plugin settings without requiring valid credentials.

More than 40,000 WordPress websites are hosting the plugin, which is widely used by WooCommerce merchants to create customized checkout experiences, landing pages, and sales funnels focused on conversions, amplifying the impact of exploitation. According to Sansec researchers, the malicious activity was associated with a deceptive JavaScript payload disguised as Google Analytics or Google Tag Manager components. 

A WebSocket connection is established between the script and the attacker-controlled infrastructure, and the script abuses a vulnerable checkout endpoint to inject arbitrary code into the plugin's External Scripts configuration. 

By loading malicious JavaScript automatically during checkout pages, a tailored payment skimmer silently captures the customer's credit card numbers, CVV codes, billing details, and other information provided by the customer. It is common for stolen payment data to be monetized through fraudulent purchases or traded on underground carding markets.

FunnelKit has addressed the issue by releasing version 3.15.0.3, and acknowledges unauthorized script injection activity has been reported. The security update must be deployed immediately, but administrators should also inspect checkout-related script configurations for unauthorized entries that may have been introduced prior to the security update implementation. 

A review of software supply chain security within the WordPress ecosystem has also been initiated following the incident. Investigations are underway to determine whether the compromise resulted from vulnerabilities within plugin development workflows, third-party dependencies, or supporting infrastructure utilized during software development. 

The threat actors are increasingly targeting the development environment and shared code libraries, since a successful intrusion can propagate malicious functionality across a wide range of downstream deployments. There are indications that the injected code in this case is intended to circumvent standard authentication controls in order to establish privileged access to the account, perhaps by manipulating back end data structures or abusing application logic responsible for account provisioning.

After gaining access to the administrator-level accounts, attackers have broad control over the affected environment, allowing them to deface the website, steal customer records, and deploy additional malware, as well as maintain persistent access to the environment. As a consequence of the compromise, there are also opportunities for secondary abuse, including the insertion of phishing content, malicious redirects, and SEO spam intended to manipulate search engine rankings without being noticed by site operators. 

Aside from the immediate technical impact, organizations may be liable for considerable recovery costs, regulatory obligations relating to data exposure, incident response expenses, and long-term reputational damage, particularly if customer trust and online transactions form an integral part of their business model. WordPress plugin compromises serve as a reminder that cyber threats are increasingly targeting trusted components that support digital businesses rather than the businesses themselves. 

A number of websites can become entry points for large-scale abuse as attackers continue weaponizing software dependencies, plugin ecosystems, and checkout infrastructure. Organizations which rely on WordPress and WooCommerce require security management that transcends patching vulnerabilities as soon as they are discovered; it is imperative to continuously monitor third-party components, implement strict access controls, detect proactive threats, and regularly review the integrity of the website.

Keeping visibility across the entire application supply chain remains one of the most effective ways to combat emerging threats, particularly in an environment where a single compromised plugin may compromise sensitive customer information.
Read more »
Supply Chain Attack
Backdoor Malware Cyber Attacks cybersecurity threat DAEMON Tools information stealer Malware Campaign PowerShell Attack QUIC RAT Software Compromise Supply Chain Attack

Trojanized DAEMON Tools Used to Deploy Persistent Backdoor Malware


 

An innocent routine software update mechanism has been weaponized by attackers in order to distribute malware through official distribution channels, enabling a stealthy global supply-chain compromise. AVB Disc Soft authenticated digital certificates were used to sign trojanized builds as part of the operation that remained undetected for nearly a month. 

By bypassing conventional trust and endpoint security mechanisms, these malicious packages were able to avoid triggering immediate suspicion. Kaspersky discovered that the campaign began on April 8, 2026, and resulted in thousands of infections in over 100 countries before the breach was detected on May 1, 2026. 

Almost all infections were characterized by reconnaissance malware intended to gather system intelligence and establish persistence. However, a comparatively small number of carefully selected victims received advanced second-stage backdoors, suggesting a targeted attack on Russian, Belarusian, and Thai organizations involved in government, science, retail, and manufacturing.

Multiple core components of DAEMON Tools were modified, including DTHelper.exe, DiscSoftBusServiceLite.exe, and DTShellHlp.exe, and malicious functionality was embedded in versions 12.5.0.2421 through 12.5.0.2434, ensuring that execution occurs at startup while maintaining the appearance of legitimate software functionality.

According to the forensic analysis, the attackers had embedded their malicious framework within several trusted DAEMON Tools binaries, including the DTHelper.exe, DiscSoftBusServiceLite.exe, and DTShellHlp.exe that can be found within the installation directory of the application. Because the compromised binaries were signed by authentic AVB Disc Soft signing certificates, operating systems and endpoint security products perceived the compromised binaries as trustworthy, reducing the probability of immediate detection. 

It has been determined that every time the affected binaries are executed during system startup, the CRT initialization routine initiates hidden backdoor functionality, initiating a dedicated background thread aimed at quietly establishing outbound communication with attacker-controlled infrastructure during system startup. 

Throughout the attack, the malware repeatedly sent HTTP GET requests to a typosquatted domain that closely mimicked the legitimate DAEMON Tools download portal, as a method of mixing malicious traffic with expected software communications. According to WHOIS records, the fraudulent domain was registered on March 27, approximately one week before the supply chain intrusion occurred, indicating deliberate preparation of infrastructure prior to the attack by the campaign's operators. 

Based on an analysis of the command-and-control infrastructure, it appeared that compromised systems were able to receive remotely issued shell commands via cmd.exe and PowerShell, which would allow attackers to download and execute additional payloads dynamically. 

PowerShell's WebClient functionality was utilized to retrieve executable files from an Internet server located at 38.180.107[.]76 before silently executing them from temporary system directories and deleting all traces afterwards. In the course of the investigation, envchk.exe, a .NET-based information collector that researchers determined was intended to perform extensive reconnaissance on infected machines, was identified as one of the primary secondary payloads. 

In the malware's source code, embedded Chinese-language strings suggest that the malware's operators are probably Chinese-speaking, but no official affiliation has yet been established for the threat group. This reconnaissance utility collected a broad range of information regarding the host, including MAC addresses, hostnames, DNS domains, installed software inventories, running process lists, system locale configurations, and other host information. 

Following data collection, the collected data is transmitted back to attacker-controlled infrastructure via structured HTTP POST requests, providing the operators with a detailed profile of the compromised environment before deciding whether to escalate the intrusion. Unsuspecting users were infected when they downloaded and installed trojanized yet legitimately signed installers for DAEMON Tools, which executed malicious code contained within trusted application components without the user knowing it. 

After activation, the implanted payload established persistence mechanisms intended to survive reboots, as well as enabled the installation of a covert backdoor capable of communicating with remote attackers when the system is started. 

The command infrastructure was also capable of dynamically delivering additional malware stages based on the victim’s profile and operational significance. It is generally considered to have functioned as a reconnaissance-oriented information stealer tasked with gathering system identifiers, including hostnames, MAC addresses, running processes, installed applications, and locale configurations, before transmitting the harvested telemetry to the operators for the purpose of assessing the environment and prioritizing victims. 

The first-stage profiling phase of the investigation resulted in an evaluation of selected systems for further compromise. Using a lightweight backdoor that is capable of executing arbitrary commands, downloading files, and running malicious code directly in memory, selected systems were escalated to a second-stage compromise.

The attack on a Russian educational institution was escalated by the attackers by using QUIC RAT, a remote access malware strain capable of supporting a variety of communication protocols, as well as injecting malicious code into legitimate processes so that they could operate stealthily after the compromise. 

Despite utilizing software distributed through official channels, the DAEMON Tools breach remained undetected for nearly a month as a highly coordinated and technically mature supply-chain intrusion. An investigation into DAEMON Tools installations conducted on or after April 8 was advised to conduct extensive threat-hunting operations to monitor for abnormal system behavior and unauthorized network activity related to the compromise period. 

Researchers have avoided formally identifying the threat actor behind the campaign, but linguistic artifacts embedded within its first stage strongly suggest that Chinese-speaking operators were responsible. Following earlier compromises involving eScan, Notepad++, and CPU-Z, the incident also illustrates the rising trend of software supply-chain attacks throughout 2026. In parallel with these campaigns, the increasing importance of trusted software ecosystems becoming high-value attack surfaces for sophisticated threat groups continues to be demonstrated, including Trivy, Checkmarx, and Glassworm, which target software repositories, development packages, and browser extensions. 

The DAEMON Tools compromise proves that modern supply-chain attacks are not limited to niche targets or underground software ecosystems, but are increasingly exploiting widely used consumer and enterprise applications. The attackers developed their attack strategy by leveraging trusted software certificates and official distribution channels in order to disguise malicious activity as legitimate software behavior while quietly gaining access to potentially high-value environments across multiple countries. 

Security researchers have concluded that organizations must evolve beyond traditional trust-based security models and embrace continuous monitoring, behavioral detection, and software integrity validation practices that will enable them to identify malicious activity, even within applications that appear legitimate and have been signed. A contemporary supply-chain intrusion illustrates how a single compromised software update can quickly escalate into a global cyber risk with far-reaching operational and national security consequences.
Read more »
Supply Chain Attack
Cloud Credential Exposure Credential Theft Developer Security GitHub Exploit malware Npm Security Open Source Security PyPI Compromise Supply Chain Attack

PyTorch Lightning and Intercom Client Users Exposed to Credential Stealing Campaign


 

Python's software supply chain has been compromised, which targeted the popular PyPI package Lightning and exposed downstream machine learning environments to covert credential theft through a sophisticated software supply chain compromise. 

In conjunction with Aikido Security, OX Security, Socket, and StepSecurity researchers, versions 2.6.2 and 2.6.3, both published on April 30, 2026, have been modified maliciously as part of a broader intrusion related to the "Mini Shai-Hulud" campaign. 

A day earlier, the attack emerged through compromised SAP-related npm packages, underlining an ongoing trend of coordinated cross-ecosystem supply chain threats targeting high-value development environments. As a result of this compromise, organizations that utilize PyTorch Lightning, an open-source abstraction layer over PyTorch with over 31,000 stars on Github, face significant risk. 

In addition to being frequently embedded in dependency trees facilitating image classification, fine-tuning of large language models, diffusion workloads, and forecasting, Lightning's ubiquity increased the scope of the attack. 

A standard pip install lightning command was sufficient for the activation of the malicious chain exploitation did not require a sophisticated trigger. Upon installation of the compromised package, a hidden _runtime directory containing obfuscated JavaScript was created and executed automatically upon module import. This behavior was embedded within the package's initialization logic, ensuring that no additional user interaction was required to execute the script. 

Upon receiving the payload, a Python script (start.py) downloaded the Bun JavaScript runtime from external sources, followed by an 11 MB obfuscated file (router_runtime.js) which carried out the attack sequence in stages. An execution model utilizing JavaScript within a Python package utilizing cross-language JavaScript marks a significant evolution in attacker tradecraft. This complicates detection mechanisms focusing on single-language threats.

The malware's primary objective was credential harvesting. Analysis indicates that the malware targeted GitHub tokens, cloud service credentials spanning Amazon Web Services (AWS), Google Cloud Platform (GCP), and Azure, SSH keys, NPM tokens, Kubernetes configurations, Docker credentials, and environment variables systematically. Moreover, it was also capable of accessing cryptocurrency wallets and developer secrets stored within local and continuous integration/continuous delivery environments. 

By exploiting compromised credentials, stolen data was exfiltrated, often by automating commits to attacker-controlled GitHub repositories, which effectively concealed malicious activity within legitimate developer workflows, effectively masking malicious activity. There were distinctive markers that linked the campaign to the "Shai-Hulud" identity. 

Infected environments were observed creating public repositories with unusual naming conventions, including EveryBoiWeBuildIsaWormBoi and descriptions such as "A Mini Shai-Hulud has appeared." Attackers seem to be able to track compromised systems using these artifacts both as infection indicators and as signalling mechanisms. 

An effort has been made to link the activity to a financial motivated threat group referred to as TeamPCP, who has consistently demonstrated a focus on credential-rich development environments. According to OX Security, approximately 8.3 million downloads are likely to have been exposed as a result of the incident. 

As a result of the attack, Intercom-Client was compromised on the same day, further demonstrating the coordinated nature of the campaign. These incidents are the culmination of a series of supply chain breaches affecting npm, PyPI, and Docker Hub occurring between April 21 and 23 that suggest that a deliberate and sustained effort was made to infiltrate widely trusted software distribution channels between April 21 and 23.

The router_runtime.js payload was further examined in order to uncover extensive obfuscation and a clear focus on credential access and repository manipulation. Approximately 700 references were found to process and environment variables, over 460 references were identified to authentication tokens, and approximately 330 references were found to code repositories. 

Shai-Hulud operations are closely related to these patterns, which emphasize code reuse and iterative refinement of attack techniques. Furthermore, the payload was also capable of poisoning GitHub repositories and propagating through npm packages, raising concerns about secondary infection vectors beyond data exfiltration. 

The Lightning-AI GitHub repository became aware of the compromise when a user reported suspicious behavior under issue #21689 titled “Possible supply chain attack on version 2.6.3.” The report described a hidden execution chain that involved downloading the Bun runtime and executing a large obfuscated payload during module import. Despite this, the issue was later closed without clarification, thereby creating uncertainty concerning the project's initial response to the matter. 

Following Socket's disclosure in the Lightning-AI/pytorch-lightning repository, an even more unusual outcome occurred. In a matter of seconds, an account identified as pl-ghost closed the issue warning about compromised versions, and then posted a meme entitled "SILENCE DEVELOPER." This behavior has raised immediate concerns about potential account compromise since it was seen as anomalous. 

It was discovered that additional suspicious activity was related to the same account, including six rapid branch creations and deletions across multiple repositories within approximately 70 minutes, which were associated with this account. Several of these branches followed random 10-character lowercase naming conventions, which is consistent with the behavior of the Shai-Hulud worm, which probes for write access. 

As well as the branch impersonating Dependabot, another contained inconsistencies such as a misspelled identifier and incorrect naming structure, and all branches were deleted within seconds of being created, and none of them triggered workflows, indicating that automated probing was not being used in development. This combined evidence strongly suggests that the maintainer account may have been compromised, possibly using the same stolen credentials that enabled the malicious package publication on PyPI to be published. 

Upon learning of the incident, Python Package Index administrators quarantined Lightning versions that may have been affected. According to the maintainers, an investigation is underway in order to determine the cause, as the compromised releases introduced functionality that was consistent with credential harvesting methods. 

In the meantime, it is highly recommended that developers remove versions 2.6.2 and 2.6.3 from their environments, downgrade to version 2.6.1, and rotate any potentially exposed credentials across multiple cloud and development platforms, including API keys, tokens, and access credentials. Besides Python, the campaign is evolving beyond Python.

Researchers have confirmed that version 7.0.4 of the intercom-client package within the Node ecosystem has also been compromised, using a preinstall hook to execute credentials-stealing malware. Packagist also has been affected by the attack, where the intercom/intercom-php package (version 5.0.2) has been altered to include a Composer plugin that downloads the Bun runtime using a shell script (setup-intercom.sh) and executes the same obfuscated payload during installation and updates. 

As a result of encryption and exfiltration of stolen data to a remote server endpoint, the campaign's adaptability across ecosystems was further demonstrated. It has been determined that the GitHub account "nhur" has likely been compromised, and that the malicious intercom-client package was published through an automated Continuous Integration workflow triggered by a now-deleted branch of GitHub.

It appears that technical overlap exists among the npm, PyPI, and PHP ecosystems, with similarities in exfiltration techniques based on GitHub, credential targeting patterns, and payload structures. Furthermore, researchers have found similarities between these attacks and previous ones affecting organizations such as Checkmarx, Bitwarden, Telnyx, LiteLLM, and Aqua Security's Trivy, which supports the hypothesis that a single threat actor is responsible. 

Upon suspension from mainstream platforms, TeamPCP reportedly launched an onion-based platform on the dark web to expand its presence. Additionally, the actors have publicly referenced their ties with other cybercriminal groups, including LAPSUS$, while marketing their own tooling infrastructure. 

The developments suggest that the threat landscape is becoming increasingly organized and persistent, with supply chain attacks not just isolated incidents but a broader strategy for infiltrating and monetizing developer ecosystems. Lightning and Intercom compromises remain a stark reminder of the fragility of modern software supply chains as investigations continue. 

In light of the increasingly capable of pivoting across ecosystems and exploiting trusted distribution channels by attackers, organizations operating in cloud-native environments and AI-based environments have become increasingly reliant on robust dependency auditing, real-time monitoring, and rapid incident response. 

The incident highlights a critical juncture in software supply chain security, at which trusted ecosystems are increasingly being weaponised through stealthy, cross-language attack chains that are emerging from across the globe. The coordinated compromises of PyPI, npm, and Packagist packages, together with evidence of maintainer account abuse and automated propagation techniques, demonstrate a high level of operational maturity that challenges traditional methods of detection and response. 

It is now necessary to take proactive measures to guard against threats such as TeamPCP, who have demonstrated their capability to infiltrate developer workflows on a large scale. These include rigorous dependency auditing, tighter access controls, and continuous monitoring of build environments. 

It is imperative to safeguard the integrity of open-source components in order to maintain confidence in modern software development in the present threat landscape.
Read more »
Supply Chain Attack
Cybercrime India Data Theft Risks Firmware Attack malware MediaTek Vulnerability Mobile Security Threats Remote Access Trojan Smartphone Security Supply Chain Attack

Hidden Android Malware Capable of Controlling Devices Raises Security Concerns


 

Smartphones have become increasingly important as repositories of identity, finances, and daily communications. The recent identification of a new Android malware strain, recently flagged by the National Cybercrime Threat Analytics Unit and ominously dubbed "God Mode", is indicative of a worrying escalation in mobile security threats. 

As opposed to conventional scams that employ visible deception or user interaction, this variant is designed to persist silently, enabling attackers to gain an unsettling degree of control without prompting immediate suspicion. 

The name of the program is not accidental; it reflects its ability to assume a wide range of permissions and surveillance capabilities once deployed, reducing users to the position of unaware bystanders.  It is noteworthy that this development coincides with an increase in sophisticated malware campaigns throughout India, where cybercriminals are increasingly utilizing the perception of legitimacy of digital services to exploit public trust, mimicking official government platforms. 

Often deployed through widely used messaging channels, these operations take advantage of urgency and limited verification by utilizing carefully orchestrated social engineering tactics, resulting in a seamless illusion of authenticity that has already led to widespread identity theft and financial fraud. In view of these concerns, researchers have identified a threat class that is more deeply ingrained into the Android operating system.

The Oblivion Remote Access Trojan, observed recently, signals the shift from surface-level compromise to systemic invasion. Based on reports, the malware is being distributed through subscription-based distribution models across a wide range of Android devices running versions 8 through 16 and is designed to operate across a broad range of devices.

Using Certo's analysis, it appears that the toolkit is not simply a standalone payload, but rather a structured package with a configurable builder that enables operators to create malicious applications that resemble legitimate applications. As a complement, a dropper mechanism was developed to mimic routine system update prompts, a tactic that blends seamlessly with user expectations and greatly increases the likelihood of execution. 

Kaspersky has found parallel evidence linking this activity to a strain they call "Keenadu," discovered during deeper investigations into firmware-level threats that resembled the earlier Triada threat. It is noteworthy that this variant is persistent: instead of being installed solely by the user, it has been observed embedded within the device firmware itself, indicating a compromise within the supply chain. 

The researchers claim that a tainted dependency introduced during firmware development enabled the malware to be integrated into the core system environment by allowing the malware to persist. Upon attachment to Android’s Zygote process, the malicious code replicates across all running applications on the device, resulting in widespread and difficult to detect control. Because affected devices may reach end users already compromised, manufacturers may be unaware of the intrusion prior to their products being distributed, which has significant consequences. 

There is a deceptively simple entry point into the infection chain associated with such threats: the link or application file is delivered via messaging platforms under the guise of legitimate notifications, often posing as bank alerts, service updates, or time-sensitive announcements. As soon as the application is executed, it strategically requests access to the Accessibility Service an Android feature intended to make the application more usable for people who are differently abled. 

A systemic abuse of this permission occurs in the context described above in order to establish extensive control over device operations. By gaining access to this level of access, the malware can monitor on-screen activity, intercept text communications, and perform autonomous user interactions. The ability to capture one-time passwords, navigate applications, and authorize transactions without explicit user awareness is included in this category. 

Most of the times observed, the initial payload is distributed via widely used communication channels such as instant messaging platforms as an APK file, where it appears as a routine application or system update via widely used communication channels. As a result of its outward appearance, the malware is often not suspected and is more likely to succeed during installation.

The malicious process embeds itself within the device and is designed to maintain persistence and stealth. By avoiding visibility within the standard application interface, the malicious process is evading casual detection while remaining silently operating in the background. The degree of risk introduced by this level of compromise is substantial. 

Through the malware's ability to access sensitive inputs, such as OTPs, personal messages, and contact databases, conventional authentication procedures are effectively bypassed. Further, by utilizing its ability to initiate or redirect calls, overlay fraudulent interfaces over legitimate banking applications, and simulate genuine user behavior, sophisticated financial exploitation and data exfiltration can be accomplished. 

Additionally, the threat is lowly visible; the lack of overt indicators, combined with its ability to avoid basic scrutiny, make it difficult for users to become aware of a breach until tangible damage has already occurred - financial or otherwise. Because the vulnerability does not uniformly impact all Android devices, assessing exposure becomes an important first step when confronted with this backdrop. 

According to current findings, the risk is primarily confined to smartphones equipped with MediaTek system-on-chip architectures, although devices that are powered by Qualcomm Snapdragon or Google Tensor are not affected. 

Users can verify their device's status by verifying its exact model in system settings and referencing its hardware specifications using manufacturer documentation. It becomes more urgent when the MediaTek chipset is identified to ensure that the latest security patches are applied as soon as possible. 

While a fix has been reportedly issued at the chipset level, its effectiveness is determined by the timely distribution by individual device manufacturers, making timely system updates a decisive factor in preventing exposures. A broader defensive posture requires a combination of technical safeguards and user discipline in addition to identification and patching. 

Security applications can not directly address firmware-level vulnerabilities, but they still play an important role in detecting secondary payloads, such as spyware or malicious applications, which may be deployed following a compromise. It is also important to minimize sensitive data stored locally on devices, particularly credentials, recovery keys, and financial information that could be accessed if access is obtained. Also highlighted in this case is the importance of physical security, as certain exploit vectors may require direct device access, which makes unattended or improperly handled devices potentially vulnerable. 

Additionally, complementary measures add essential layers of resistance against unauthorised activity, such as robust screen locks, shorter auto-lock intervals, and multi-factor authentication across critical accounts. In addition to reducing credential exposure, using encrypted password managers will help reduce device-level control capabilities, such as USB-restricted mode, when available, to limit data transfer capabilities while locked. 

As a result of these measures, the underlying vulnerability remains, however a layered security framework is established that significantly reduces the likelihood and impact of exploitation in the real world. As a result, these deeply embedded Android threats highlight a significant shift in the mobile security landscape, where risks are no longer restricted to user-level interactions, but extend to the underlying architecture of the device itself. 

With this evolving technology, users and manufacturers need to remain vigilant and informed, emphasizing proactive security hygiene, timely software maintenance, and carefully examining digital interactions. As threat actors continue to refine their methods, resilience will be determined by the development of layered, adaptive defense strategies that anticipate compromise and limit its impact, rather than a single safeguard.
Read more »
Supply Chain Attack
CI CD Pipeline Cloud Security Credential Theft Cyber Attacks Kubernetes Security Malware Persistence Open Source Risk PyPI Compromise Python security Supply Chain Attack

Security Flaw in Popular Python Library Threatens User Machines


 

The software ecosystem experienced a brief but significant breach on March 24, 2026 that went almost unnoticed, underscoring how fragile even well-established development pipelines have become. As a result of a threat actor operating under the name TeamPCP successfully compromising the PyPI credentials of the maintainer, malicious code has been quietly seeded into newly published versions of the popular LiteLLM Python package versions 1.82.7 and 1.82.8.

LiteLLM itself was not the victim of the intrusion, but rather a previous breach involving Trivy, an open source security scanner integrated into the project's CI/CD pipeline, which effectively made a defensive tool into a channel for an attack. 

PyPI quarantined the tainted packages only after a limited period of approximately three hours when they were live, but the extent of potential exposure was significant due to the staggering number of downloads and installs of LiteLLM, which exceeds 3.4 million per day and 95 million per month, respectively. 

A powerful and unified interface for interacting with multiple large language model providers is provided by LiteLLM, a tool deeply embedded within modern artificial intelligence development environments. LiteLLM frequently operates in environments containing highly sensitive assets such as API credentials, cloud configurations, and proprietary information. 

The incident illustrates not only a fleeting compromise; it also illustrates a broader and increasingly urgent reality that the open source supply chain remains vulnerable to exactly the types of indirect, multi-stage attacks that are the most difficult to detect and the most damaging when they are successful in a global software development environment. This incident was not simply the result of code tampering; it was a carefully designed, multi-stage intrusion intended to exploit environments that are heavily automated and trusted. 

The threat group TeamPCP leveraged its access in order to introduce two trojanized versions of LiteLLM - versions 1.82.7 and 1.82.8 - which contained obfuscated payloads embedded in core components of the package, namely within the module litellm/proxy/proxy_server.py. 

While the insert was subtle, positioned between legitimate code paths, and encoded so as to evade immediate attention, it ensured execution at import, an important point in the development lifecycle that virtually ensures activation in production environments. 

An even more durable mechanism was introduced in the subsequent version by the attackers as a malicious .pth file directly embedded within the site-packages directory, which was used to extend their foothold. As a result of exploiting Python's internal initialization behavior, the payload executed automatically upon every interpreter startup, regardless of whether LiteLLM itself was ever invoked again. Using detached subprocess calls, the malicious logic was able to operate without visibility, effectively bypassing conventional monitoring tools which focus on application execution. 

Designing the payload reflected an in-depth understanding of cloud-native architectures and the dense concentrations of sensitive information contained within them. When activated, the code acted as a comprehensive orchestration layer capable of conducting reconnaissance, credential harvesting, and environment mapping.

Through a systematic process of traversing the host system, SSH keys, cloud provider credentials, Kubernetes configurations, container registry secrets, and environment variables were extracted. Additionally, managed services were probed further for information.

Cloud-based environments utilize native authentication mechanisms, such as AWS instance metadata, to generate signed requests and retrieve secrets directly from services such as Secrets Manager and Parameter Store, extending its reach beyond traditional disk-based storage or network access. 

A comprehensive collection process was conducted, including infrastructure-as-code artifacts, continuous integration and continuous delivery configurations as well as cryptographic material, database credentials, and developer shell histories, effectively turning each compromised device into an extensive repository of exploitable information. 

Data exfiltration was highly sophisticated, utilizing layered encryption and infrastructure that blended seamlessly into legitimate traffic patterns to exfiltrate data. After compression, encryption, and asymmetric key wrapping, stolen data was transmitted to a domain fabricated to resemble legitimate LiteLLM infrastructure before being encrypted.

As a consequence, even intercepted traffic would be of little value without access to the attacker's private key, complicating the forensic analysis and response process. Furthermore, the operation demonstrated a clear emphasis on persistence and lateral expansion, particularly within Kubernetes environments. 

As service account tokens were present in the payload, it initiated cluster-wide reconnaissance, deployed privileged pods across all nodes, including control-plane systems, and mounted host filesystems and bypassed scheduling restrictions. It then introduced a secondary persistence layer that was disguised as a benign system telemetry service within user-level configurations of systemd.

During periodic communication with a remote command-and-control endpoint, this component provided operators with the ability to deliver additional payloads, update tooling, or terminate the activity by using a built-in kill switch. In summary, the incident indicates that operational maturity extends beyond opportunistic exploitation, demonstrating a level of operational maturity. 

The team PCP successfully maximized the return on each compromised host by targeting LiteLLM, a gateway technology at the intersection of multiple artificial intelligence providers. This allowed them access not only to infrastructure credentials, but also to a wide variety of API keys that cover numerous large language model platforms. 

As a result, the compromise of one, widely trusted component can have alarming ripple effects across entire development and production environments with alarming speed and precision in an ecosystem increasingly characterized by interconnected dependencies. Organizations must reevaluate trust boundaries within their software supply chains in the aftermath of the incident, as remediation is no longer the only priority for organizations.

As security teams are increasingly being encouraged to adopt a zero-trust approach towards third-party dependencies, verification does not end when the product is installed, but continues throughout the entire execution lifecycle. 

Among these measures are the enforcing of strict version pins, verifying package integrity using trusted sources, and developing continuous monitoring mechanisms that will detect anomalous behavior at runtime as opposed to simply relying on static analysis. 

The strengthening of continuous integration/continuous delivery pipelines—especially their tools—has emerged as a critical control point, as this attack demonstrated how upstream compromise can cascade downstream without significant resistance. 

An institutionalization of rapid response playbooks is equally important in order to ensure that credentials are rotated, systems are isolated, and forensic validation is conducted without delay when anomalies are discovered. 

As the use of interconnected AI frameworks continues to increase, security responsibilities are shifting from reactive patching to proactive resilience, where detection, containment, and recovery of supply chain intrusions become as essential as preventing them.
Read more »
Vulnerabilities and Exploits
GitHub Supply Chain Attack Trivy Scanner Vulnerabilities and Exploits

Trivy Scanner Hit by Major Supply Chain Attack

 

Aqua Security's popular open-source vulnerability scanner, Trivy, has been compromised in an ongoing supply chain attack that began in late February 2026 and escalated dramatically by mid-March. Threat actors exploited misconfigurations in Trivy's GitHub Actions workflows, stealing privileged tokens to gain persistent access to repositories and release processes. 

This breach turned a trusted DevSecOps tool—boasting over 32,000 GitHub stars—into a vector for credential theft across countless CI/CD pipelines worldwide. The attack unfolded in phases, starting with a token theft from a misconfigured GitHub Action on February 28, allowing initial foothold establishment. By March 19, attackers force-pushed malicious code to 76 of 77 tags in aquasecurity/trivy-action and all 7 in setup-trivy, repointing versions like v0.69.4 to infostealer payloads.

The malware executed stealthily: it harvested GitHub tokens, cloud credentials, and SSH keys, encrypted them in tpcp.tar.gz archives, exfiltrated to scan.aquasecurtiy[.]org, then ran legitimate Trivy scans to avoid detection. Malicious Docker images under tags like latest, 0.69.5, and 0.69.6 further spread the threat via container registries. Despite Aqua Security's credential rotations after the initial incident, incomplete measures let attackers reestablish access, leading to repository tampering detected on March 22. This persistence mirrors trends in SaaS supply chain attacks, from SolarWinds to recent exploits, where upstream compromises cascade downstream.

The "Team PCP" actors have struck Trivy three times in under a month, highlighting eviction challenges in automated environments. Trivy's vast adoption amplifies the blast radius, potentially exposing secrets in thousands of organizations' pipelines. Microsoft and others urge auditing workflows using compromised tags, as successful scans masked the theft. This incident underscores vulnerabilities in mutable tags and over-privileged runners, eroding trust in open-source security tools. 

To mitigate, pin GitHub Actions to immutable commit SHAs instead of tags, rotate all exposed secrets, and adopt OIDC for short-lived credentials. Harden CI/CD privileges, monitor SaaS integrations continuously, and audit Trivy executions since March 1. Aqua Security continues remediation with partners like Sygnia, but organizations must proactively secure their supply chains against such "side door" threats.
Read more »
Web SDK vulnerability
AppsFlyer SDK hack crypto wallet hijacking cryptocurrency theft malware Cyber Security Supply Chain Attack Web SDK vulnerability

AppsFlyer Web SDK Breach Used to Divert Cryptocurrency in Supply Chain Attack

 

 

The Web SDK of AppsFlyer was briefly compromised earlier this week, allowing attackers to inject malicious code as part of a supply chain attack aimed at stealing cryptocurrency.

The malicious payload was capable of intercepting cryptocurrency wallet addresses entered by users on affected websites. It would then swap these addresses with ones controlled by the attackers, redirecting funds without the user’s knowledge.

AppsFlyer’s SDK is widely integrated across thousands of platforms for marketing analytics, including tracking user engagement and retention. The company reports that over 15,000 businesses rely on its SDK across more than 100,000 mobile and web applications, making it a prominent “mobile measurement partner” (MMP) solution for campaign attribution and in-app activity tracking.

The issue was initially identified by researchers at Profero, who "confirmed the presence of obfuscated attacker-controlled JavaScript being delivered to users visiting websites and applications that loaded the AppsFlyer SDK." However, AppsFlyer has only acknowledged a domain availability issue that appeared on its status page on March 10, 2026.

Profero detected the malicious activity on March 9, when the compromised SDK, hosted on its official domain ‘websdk.appsflyer.com,’ began distributing harmful code. Multiple users also flagged the suspicious behavior.

“While the full scope, duration, and root cause of the incident remain unverified, the activity highlights how threat actors can abuse trust in widely deployed third-party SDKs to impact downstream websites, applications, and end users,” Profero explains.

The injected JavaScript was engineered to keep the SDK functioning normally while secretly executing malicious actions. It dynamically decoded hidden instructions and intercepted browser network requests.

Once active, the malware monitored web pages for cryptocurrency wallet inputs. Upon detecting a wallet address, it replaced it with an attacker-controlled one and simultaneously transmitted the original address along with related data to external servers.

The attack targeted several major cryptocurrencies, including Bitcoin, Ethereum, Solana, Ripple, and TRON, potentially affecting a broad range of digital transactions.

Researchers estimate the exposure window lasted from March 9 at 22:45 UTC to March 11, although it remains unclear whether the compromise extended beyond this timeframe.

In response to inquiries, AppsFlyer confirmed that unauthorized code had been delivered through its SDK.

"AppsFlyer detected and contained a domain registrar incident on March 10 that temporarily exposed the AppsFlyer Web SDK running on a segment of customer websites to unauthorized code.

"The mobile SDK was not affected, and our investigation to date has not identified evidence that customer data on AppsFlyer systems was accessed. We take this incident very seriously and have been actively communicating with customers," AppsFlyer told BleepingComputer.

The company added that the issue has now been resolved and that affected customers were directly notified with updates.

"The mobile SDK has remained safe to use throughout the process, and the web SDK is safe to use."

AppsFlyer stated that the investigation is still ongoing in collaboration with external forensic specialists, with further details expected once the analysis is complete.

Due to uncertainties surrounding the extent and root cause of the breach, security experts recommend that organizations using the SDK examine telemetry logs for unusual API activity linked to websdk.appsflyer.com, revert to verified safe SDK versions, and assess any potential compromise.

This incident follows another cybersecurity concern earlier in the year, when the hacking group ShinyHunters alleged exploiting the SDK in a supply chain attack targeting Match Group, reportedly exposing over 10 million user records from platforms like Hinge, Match.com, and OkCupid.
Read more »
Supply Chain Attack
AI Tool GlassWorm malware Open VSX Supply Chain Attack

GlassWorm Abuses 72 Open VSX Extensions in Bold Supply-Chain Assault

 

GlassWorm has resurfaced with a more aggressive supply‑chain campaign, this time weaponizing the Open VSX registry at scale to target developers. Security researchers say the latest wave represents a significant escalation in both scope and stealth compared to earlier activity. 

Since January 31, 2026, at least 72 new malicious Open VSX extensions have been identified, all masquerading as popular tools like linters, formatters, code runners, and AI‑powered coding assistants. These look and behave like legitimate utilities at first glance, making it easy for busy developers to trust and install them. Behind the scenes, however, they embed hidden logic designed to pull in additional malware once inside a development environment.

The attackers now abuse trusted Open VSX features such as extensionPack and extensionDependencies to spread their payloads transitively. An extension can appear harmless on installation but later pull in a malicious dependency via an update or a bundled pack. This approach allows the threat actor to minimize obviously suspicious code in each listing while still maintaining a broad infection path.

Once executed, GlassWorm behaves as a multi‑stage infostealer and remote access tool targeting developer systems. It focuses on harvesting credentials for npm, GitHub, Git, and other services, then uses those stolen tokens to compromise additional repositories and publish more infected extensions. This creates a self‑reinforcing loop that can quickly expand across ecosystems if not promptly contained. 

Beyond credentials, GlassWorm aggressively targets financial data by going after more than 49 different cryptocurrency wallet browser extensions, including popular wallets like MetaMask, Coinbase, and Phantom. Stolen cookies and session tokens can enable account takeover, while drained wallets provide immediate monetization for the attackers. In later stages, the malware deploys a hidden VNC component and SOCKS proxy, effectively converting developer machines into nodes within a criminal infrastructure. 

For developers and organizations, this campaign underscores how extension ecosystems have become high‑value attack surfaces. Teams should enforce strict extension allowlists, monitor unusual repository activity, and rotate credentials if any suspicious Open VSX extensions were recently installed. Security tooling that inspects extension metadata, dependency chains, and post‑install behavior is now essential to counter evolving threats like GlassWorm.
Read more »
Supply Chain Attack
Crypto Exchange Cyber Attacks dYdX PyPI Package Supply Chain Attack

Malicious dYdX Packages Drain User Wallets in Supply Chain Attack

 

Malicious open-source packages targeting the dYdX cryptocurrency exchange have enabled attackers to drain user wallets, exposing once again how fragile software supply chains can be in the crypto ecosystem. Researchers found that legitimate-looking libraries on popular repositories were quietly stealing seed phrases and other sensitive data from both developers and end users, turning everyday development workflows into vectors for wallet compromise. The incident shows that even reputable projects using standard tooling are not immune when upstream dependencies are poisoned.

The attack focused on npm and PyPI packages associated with dYdX’s v4 trading stack, specifically the JavaScript package @dydxprotocol/v4-client-js and the Python package dydx-v4-client in certain versions. These libraries are widely used to build trading bots, automated strategies, and backend services that interact with the exchange and therefore routinely handle mnemonics and private keys needed to sign transactions. By compromising such central components, attackers gained access not just to individual wallets but to any application that pulled in the tainted releases.

Inside the malicious npm package, attackers added a surreptitious function that executed whenever a wallet seed phrase was processed, quietly exfiltrating it along with a fingerprint of the device running the code. The fingerprinting allowed the threat actors to correlate stolen credentials across multiple compromises and track victims over time. Stolen data was sent to a typosquatted domain crafted to resemble legitimate dYdX infrastructure, increasing the chances that network defenders would overlook the outbound connections.

The PyPI package carried similar credential-stealing behavior but escalated the threat by bundling a remote access Trojan capable of executing arbitrary Python code on infected systems. Running as a background daemon, this RAT regularly contacted a command‑and‑control server, fetched attacker-supplied code, and executed it in an isolated subprocess using a hard-coded authorization token. With this access, adversaries could steal keys and source code, plant persistent backdoors, and broadly surveil developer environments beyond just wallet data.

This is not the first time dYdX has faced targeted abuse of its ecosystem, following prior incidents involving malicious npm uploads and website hijacking campaigns aimed at draining user funds. For the broader industry, the episode underlines how high‑value crypto platforms and their developer tooling have become prime targets for supply-chain attacks. Developers are urged to rigorously audit dependencies, verify package integrity and publishers, and avoid using real wallet credentials in testing environments, while users should quickly review any apps or bots that rely on the affected dYdX client libraries.
Read more »
Subscribe to: Posts (Atom)