Search/CVE-2025-55182 vulnerability in React and Next.js | Kaspersky official blog
● Story

CVE-2025-55182 vulnerability in React and Next.js | Kaspersky official blog

A critical vulnerability (CVE-2025-55182) in React Server Components (RSC) may allow unauthenticated attackers to achieve remote code exection on the application server, the React development team warned on Wednesday. The maximum-severity vulnerability was privately reported by Lachlan Davidson and has been fixed. At this moment, there are no public reports of it being exploited by attackers and no confirmed public PoC exploits (for now). Nevertheless, affected users have been advised to upgrade to a non-vulnerable … More → The post Max-severity vulnerability in React, Node.js patched, update ASAP (CVE-2025-55182) appeared first on Help Net Security .

CVEs
0
Highest CVSS
—
In KEV
0
Sources
3
Connections
6 relationships
China-nexus cyber threat groups rapidly exploit React2Shell vulnerability (CVE-2025-55182)
China-nexus cyber threat groups rapidly exploit React2Shell vulnerability (CVE-2025-55182) December 29, 2025: The blog post was updated to add options for AWS Network Firewall. December 12, 2025: The blog post was updated to clarify when customers need to update their ReactJS version. Within hours of the public disclosure of CVE-2025-55182 (React2Shell) on December 3, 2025, Amazon threat intelligence teams observed active exploitation attempts by multiple China state-nexus threat groups, including Earth Lamia and Jackpot Panda. This critical vulnerability in React Server Components has a maximum Common Vulnerability Scoring System (CVSS) score of 10.0 and affects React versions 19.x and Next.js versions 15.x and 16.x when using App Router. While this vulnerability doesn’t affect AWS services, we are sharing this threat intelligence to help customers running React or Next.js applications in their own environments take immediate action. China continues to be the most prolific source of state-sponsored cyber threat activity, with threat actors routinely operationalizing public exploits within hours or days of disclosure. Through monitoring in our AWS MadPot honeypot infrastructure, Amazon threat intelligence teams have identified both known groups and previously untracked threat clusters attempting to exploit CVE-2025-55182. AWS has deployed multiple layers of automated protection through Sonaris active defense, AWS WAF managed rules (AWSManagedRulesKnownBadInputsRuleSet version 1.24 or higher), and perimeter security controls. However, these protections aren’t substitutes for patching. Regardless of whether customers are using a fully managed AWS service, if customers are running an affected version of React or Next.js in their environments, they should update to the latest patched versions immediately. Customers running React or Next.js in their own environments (Amazon Elastic Compute Cloud (Amazon EC2), containers, and so on) must update vulnerable applications immediately. Understanding CVE-2025-55182 (React2Shell) Discovered by Lachlan Davidson and disclosed to the React Team on November 29, 2025, CVE-2025-55182 is an unsafe deserialization vulnerability in React Server Components. The vulnerability was named React2Shell by security researchers. Key facts: CVSS score: 10.0 (Maximum severity) Attack vector: Unauthenticated remote code execution Affected components: React Server components in React 19.x and Next.js 15.x/16.x with App Router Critical detail: Applications are vulnerable even if they don’t explicitly use server functions, as long as they support React Server Components The vulnerability was responsibly disclosed by Vercel to Meta and major cloud providers, including AWS, enabling coordinated patching and protection deployment prior to the public disclosure of the vulnerability. Who is exploiting CVE-2025-55182? Our analysis of exploitation attempts in AWS MadPot honeypot infrastructure has identified exploitation activity from IP addresses and infrastructure historically linked to known China state-nexus threat actors. Because of shared anonymization infrastructure among Chinese threat groups, definitive attribution is challenging: Infrastructure associated with Earth Lamia: Earth Lamia is a China-nexus cyber threat actor known for exploiting web application vulnerabilities to target organizations across Latin America, the Middle East, and Southeast Asia. The group has historically targeted sectors across financial services, logistics, retail, IT companies, universities, and government organizations. Infrastructure associated with Jackpot Panda: Jackpot Panda is a China-nexus cyber threat actor primarily targeting entities in East and Southeast Asia. The activity likely aligns to collection priorities pertaining to domestic security and corruption concerns. Shared anonymization infrastructure: Large-scale anonymization networks have become a defining characteristic of Chinese cyber operations, enabling reconnaissance, exploitation, and command-and-control activities while obscuring attribution. These networks are used by multiple threat groups simultaneously, making it difficult to attribute specific activities to individual actors. This is in addition to many other unattributed threat groups that share commonality with Chinese-nexus cyber threat activity. The majority of observed autonomous system numbers (ASNs) for unattributed activity are associated with Chinese infrastructure, further confirming that most exploitation activity originates from that region. The speed at which these groups operationalized public proof-of-concept (PoC) exploits underscores a critical reality: when PoCs hit the internet, sophisticated threat actors are quick to weaponize them. Exploitation tools and techniques Threat actors are using both automated scanning tools and individual PoC exploits. Some observed automated tools have capabilities to deter detection such as user agent randomization. These groups aren’t limiting their activities to CVE-2025-55182. Amazon threat intelligence teams observed them simultaneously exploiting other recent N-day vulnerabilities, including CVE-2025-1338. This demonstrates a systematic approach: threat actors monitor for new vulnerability disclosures, rapidly integrate public exploits into their scanning infrastructure, and conduct broad campaigns across multiple Common Vulnerabilities and Exposures (CVEs) simultaneously to maximize their chances of finding vulnerable targets. The reality of public PoCs: Quantity over quality A notable observation from our investigation is that many threat actors are attempting to use public PoCs that don’t actually work in real-world scenarios. The GitHub security community has identified multiple PoCs that demonstrate fundamental misunderstandings of the vulnerability: Some of the example exploitable applications explicitly register dangerous modules (fs ,child_process ,vm ) in the server manifest, which is something real applications should never do. Several repositories contain code that would remain vulnerable even after patching to safe versions. Despite the technical inadequacy of many public PoCs, threat actors are still attempting to use them. This demonstrates several important patterns: Speed over accuracy: Threat actors prioritize rapid operationalization over thorough testing, attempting to exploit targets with any available tool. Volume-based approach: By scanning broadly with multiple PoCs (even non-functional ones), actors hope to find the small percentage of vulnerable configurations. Low barrier to entry: The availability of public exploits, even flawed ones, enables less sophisticated actors to participate in exploitation campaigns. Noise generation: Failed exploitation attempts create significant noise in logs, potentially masking more sophisticated attacks. Persistent and methodical attack patterns Analysis of data from MadPot reveals the persistent nature of these exploitation attempts. In one notable example, an unattributed threat cluster associated with IP address 183[.]6.80.214 spent nearly an hour (from 2:30:17 AM to 3:22:48 AM UTC on December 4, 2025) systematically troubleshooting exploitation attempts: 116 total requests across 52 minutes Attempted multiple exploit payloads Tried executing Linux commands (whoami ,id ) Attempted file writes to /tmp/pwned.txt Tried to read/etc/passwd This behavior demonstrates that threat actors aren’t just running automated scans, but are actively debugging and refining their exploitation techniques against live targets. How AWS helps protect customers AWS deployed multiple layers of protection to help safeguard customers: Sonaris Active DefenseOur Sonaris threat intelligence system automatically detected and restricted malicious scanning attempts targeting this vulnerability. Sonaris analyzes over 200 billion events per minute and integrates threat intelligence from our MadPot honeypot network to identify and block exploitation attempts in real time. MadPot IntelligenceOur global honeypot system provided early detection of exploitation attempts, enabling rapid response and threat analysis. AWS WAF Managed RulesThe default version (1.24 or higher) of the AWS WAF AWSManagedRulesKnownBadInputsRuleSet now includes updated rules for CVE-2025-55182, providing automatic protection for customers using AWS WAF with managed rule sets. AWS Network Firewall Rule OptionsManagedThe Active Threat Defense managed rules for AWS Network Firewall are automatically updated with the latest threat intelligence from MadPot so customers can get proactive protection for their VPCs. CustomThe following AWS Network Firewall custom L7 stateful rule blocks HTTP connections made directly to IP addresses on non-standard ports (any port other than 80). This pattern has been commonly observed by Amazon Threat Intelligence in post-exploitation scenarios where malware downloads additional payloads or establishes command-and-control communications by connecting directly to IP addresses rather than domain names, often on high-numbered ports to evade detection. While not necessarily specific to React2Shell, many React2Shell exploits include this behavior, which is usually anomalous in most production environments. You can choose to block and log these requests or simply alert on them so you can investigate systems that are triggering the rule to determine whether they have been affected. reject http $HOME_NET any -> any !80 (http.host; content:"."; pcre:"/^(?:[0-9]{1,3}\.){3}[0-9]{1,3}$/"; msg:"Direct to IP HTTP on non-standard port (common post exploitation malware download technique)"; flow:to_server; sid:2025121801;) Amazon Threat IntelligenceAmazon threat intelligence teams are actively investigating CVE-2025-55182 exploitation attempts to protect AWS infrastructure. If we identify signs that your infrastructure has been compromised, we will notify you through AWS Support. However, application-layer vulnerabilities are difficult to detect comprehensively from network telemetry alone. Do not wait for notification from AWS. Important: These protections are not substitutes for patching. Customers running React or Next.js in their own environments (EC2, containers, etc.) must update vulnerable applications immediately. Immediate recommended actions Update vulnerable React/Next.js applications. See the AWS Security Bulletin (https://aws.amazon.com/security/security-bulletins/AWS-2025-030/) for affected and patched versions. Deploy the custom AWS WAF rule as interim protection (rule provided in the security bulletin). Review application and web server logs for suspicious activity. Look for POST requests with next-action orrsc-action-id headers. Check for unexpected process execution or file modifications on application servers. If you believe your application may have been compromised, open an AWS Support case immediately for assistance with incident response. Note: Customers using managed AWS services are not affected and require no action. Indicators of compromise Network indicators HTTP POST requests to application endpoints with next-action orrsc-action-id headers Request bodies containing $@ patterns Request bodies containing "status":"resolved_model" patterns Host-based indicators Unexpected execution of reconnaissance commands (whoami ,id ,uname ) Attempts to read /etc/passwd Suspicious file writes to /tmp/ directory (for example,pwned.txt ) New processes spawned by Node.js/React application processes Threat actor infrastructure IP Address, Date of Activity, Attribution 206[.]237.3.150, 2025-12-04, Earth Lamia 45[.]77.33.136, 2025-12-04, Jackpot Panda 143[.]198.92.82, 2025-12-04, Anonymization Network 183[.]6.80.214, 2025-12-04, Unattributed threat cluster Additional resources AWS Security Bulletin: CVE-2025-55182 https://aws.amazon.com/security/security-bulletins/AWS-2025-030/ AWS WAF Documentation: https://docs.aws.amazon.com/waf/ React Team Security Advisory: https://react.dev/blog/2025/12/03/react-server-components-security-advisory If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
aws.amazon.comDec 5, 2025extracted
CVE-2025-55182 vulnerability in React and Next.js | Kaspersky official blog
On December 3, the coordinated elimination of the critical vulnerability CVE-2025-55182 (CVSSv3 — 10) became known. It was found in React server components (RSC), as well as in a number of derivative projects and frameworks: Next.js, React Router RSC preview, Redwood SDK, Waku, and RSC plugins Vite and Parcel. The vulnerability allows any unauthenticated attacker to send a request to a vulnerable server and execute arbitrary code. Considering that tens of millions of websites, including Airbnb and Netflix, are built on React and Next.js, and vulnerable versions of the components were found in approximately 39% of cloud infrastructures, the scale of exploitation could be very serious. Measures to protect your online services must be taken immediately. A separate CVE-2025-66478 was initially created for the Next.js vulnerability, but it was deemed a duplicate, so the Next.js defect also falls under CVE-2025-55182. Where and how does the React4Shell vulnerability work? React is a popular JavaScript library for creating user interfaces for web applications. Thanks to RSC components, which appeared in React 18 in 2020, part of the work of assembling a web page is performed not in the browser, but on the server. The web page code can call React functions that will run on the server, get the execution result from them, and insert it into the web page. This allows some websites to run faster — the browser doesn’t need to load unnecessary code. RSC divides the application into server and client components, where the former can perform server operations (database queries, access to secrets, complex calculations), while the latter remains interactive on the user’s machine. A special lightweight HTTP-based protocol called Flight is used for fast streaming of serialized information between the client and server. CVE-2025-55182 lies in the processing of Flight requests, or to be more precise — in the unsafe deserialization of data streams. React Server Components versions 19.0.0, 19.1.0, 19.1.1, 19.2.0 — or, more specifically, the react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack packages — are vulnerable. Vulnerable versions of Next.js are: 15.0.4, 15.1.8, 15.2.5, 15.3.5, 15.4.7, 15.5.6, and 16.0.6. To exploit the vulnerability, an attacker can send a simple HTTP request to the server, and even before authentication and any checks, this request can initiate the launch of a process on the server with React privileges. There’s no data on the exploitation of CVE-2025-55182 in the wild yet, but experts agree that it’s possible, and will most likely be large-scale. Wiz claims that its test RCE exploit works with almost 100% reliability. A prototype of the exploit is already available on GitHub, so it won’t be difficult for attackers to adopt it and launch mass attacks. React was originally designed to create client-side code that runs in a browser; server-side components containing vulnerabilities are relatively new. Many projects built on older versions of React, or projects where React server-side components are disabled, are not affected by this vulnerability. However, if a project doesn’t use server-side functions, this doesn’t mean it’s protected — RSCs may still be active. Websites and services built on recent versions of React with default settings (for example, an application on Next.js built using create-next-app) will be vulnerable. Protective measures against exploitation of CVE-2025-55182 Updates. React users should update to the versions 19.0.1, 19.1.2 or 19.2.1. Next.js users should update to versions 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7. Detailed instructions for updating the react-server component for React Router, Expo, Redwood SDK, Waku, and other projects are provided in the React blog. Cloud provider protection. Major providers have released rules for their application-level web filters (WAF) to prevent exploitation of vulnerabilities: Akamai (rules for App & API Protector users); AWS (AWS WAF rules are included in the standard set, but require manual activation); Cloudflare (protects all customers, including those on the free plan. Works if traffic to the React application is proxied through Cloudflare WAF. Customers on professional or enterprise plans should verify that the rule is active); Google Cloud (Cloud Armor rules for Firebase Hosting and Firebase App Hosting are applied automatically); Vercel (rules are applied automatically). However, all providers emphasize that WAF protection only buys time for scheduled patching, and RSC components still need to be updated on all projects. Protecting web services on your own servers. The least invasive solution would be to apply detection rules that prevent exploitation to your WAF or firewall. Most vendors have already released the necessary rule sets, but you can also prepare them yourself — for example, based on our list of dangerous POST requests. If granular analysis and filtering of web traffic isn’t possible in your environment, identify all servers on which RSC (server function endpoints) are available, and significantly restrict access to them. For internal services, you can block requests from all untrusted IP ranges; for public services, you can strengthen IP reputation filtering and rate limiting. An additional layer of protection will be provided by an EPP/EDR agent on servers with RSC. It will help detect anomalies in react-server behavior after the vulnerability has been exploited, and prevent the attack from developing. In-depth investigation. Although information about exploitation of the vulnerability in the wild hasn’t been confirmed yet, it cannot be ruled out that it’s already happening. It’s recommended to study the logs of network traffic and cloud environments, and if suspicious requests are detected, to carry out a full response — including the rotation of keys and other secrets available on the server. Signs of post-exploitation activity to look for first: reconnaissance of the server environment, searches for secrets (.env, CI/CD tokens, etc.), and installation of web shells.
kaspersky.comDec 4, 2025extracted
Max-severity vulnerability in React, Node.js patched, update ASAP (CVE-2025-55182)
Max-severity vulnerability in React, Node.js patched, update ASAP (CVE-2025-55182) A critical vulnerability (CVE-2025-55182) in React Server Components (RSC) may allow unauthenticated attackers to achieve remote code exection on the application server, the React development team warned on Wednesday. The maximum-severity vulnerability was privately reported by Lachlan Davidson and has been fixed. At this moment, there are no public reports of it being exploited by attackers and no confirmed public PoC exploits (for now). Nevertheless, affected users have been advised to upgrade to a non-vulnerable version of React, and of various libraries, frameworks and bundlers depending on it. About CVE-2025-55182 (and CVE-2025-66478) React is a free and open-source JavaScript library that allows developers to build fast, interactive user interfaces for web, mobile and desktop apps, single-page applications, and dashboards. React Server Components (RSC) are a feature that lets parts of React apps run on the server instead of in the browser. RSC were introduced in React v19, in late 2024. CVE-2025-55182 (also dubbed “React2Shell”) is an unsafe deserialization vulnerability in React Server Components versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0, including these packages: react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack. It’s been patched in React v19.2.1. Specific details about the flaw have been witheld for now. “React Server Functions allow a client to call a function on a server. React provides integration points and tools that frameworks and bundlers use to help React code run on both the client and the server. React translates requests on the client into HTTP requests which are forwarded to a server. On the server, React translates the HTTP request into a function call and returns the needed data to the client,” the React Team explained. “[CVE-2025-55182 may allow] an unauthenticated attacker [to] craft a malicious HTTP request to any Server Function endpoint that, when deserialized by React, achieves remote code execution on the server. Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components.” The vulnerability also affects other frameworks and packages that depend on React or include the vulnerable React packages: Next.js, React Router, Waku, Redwood SDK, Expo, Vite, Parcel, and others. Vercel has assigned another CVE for the vulnerability as it impacts Next.js applications using the App Router – CVE-2025-66478. Next.js releases 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7 include the fix. Apps that don’t use a server or a framework, bundler, or bundler plugin that supports React Server Components are not affected. Available mitigations and patches “Wiz data indicates that 39% of cloud environments contain instances of Next.js or React in versions vulnerable to CVE-2025-55182 and/or CVE-2025-66478,” Wiz threat researchers say. “Regarding Next.js, the framework itself is present in 69% of environments. Notably, 61% of those environments have public applications running Next.js, meaning that 44% of all cloud environments have publicly exposed Next.js instances (regardless of the version running).” Cloudflare and Google Cloud have implemeted new rules that should protect customers that use its web application firewalls, though they should update to the latest version of React 19.2.1 and Next.js as soon as possible. The React Team has outlined update instructions for users of React, Node.js, and other vulnerable frameworks. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!
helpnetsecurity.comDec 4, 2025extracted
Related Stories
6
Analyzing Sharepoint Exploits (CVE-2025-53770, CVE-2025-53771), (Wed, Jul 23rd)
On July 19–20, 2025, various security companies and national CERTs published alerts about active exploitation of on-premise SharePoint servers. According to the reports, observed attacks did not require authentication, allowed attackers to gain full control over the infected servers, and were performed using an exploit chain of two vulnerabilities: CVE-2025-49704 and CVE-2025-49706, publicly named “ToolShell”. Additionally, on the same dates, Microsoft released out-of-band security patches for the vulnerabilities CVE-2025-53770 and CVE-2025-53771, aimed at addressing the security bypasses of previously issued fixes for CVE-2025-49704 and CVE-2025-49706. The release of the new, “proper” updates has caused confusion about exactly which vulnerabilities attackers are exploiting and whether they are using zero-day exploits. Kaspersky products proactively detected and blocked malicious activity linked to these attacks, which allowed us to gather statistics about the timeframe and spread of this campaign. Our statistics show that widespread exploitation started on July 18, 2025, and attackers targeted servers across the world in Egypt, Jordan, Russia, Vietnam, and Zambia. Entities across multiple sectors were affected: government, finance, manufacturing, forestry, and agriculture. While analyzing all artifacts related to these attacks, which were detected by our products and public information provided by external researchers, we found a dump of a POST request that was claimed to contain the malicious payload used in these attacks. After performing our own analysis, we were able to confirm that this dump indeed contained the malicious payload detected by our technologies, and that sending this single request to an affected SharePoint installation was enough to execute the malicious payload there. Our analysis of the exploit showed that it did rely on vulnerabilities fixed under CVE-2025-49704 and CVE-2025-49706, but by changing just one byte in the request, we were able to bypass those fixes. In this post, we provide detailed information about CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771, and one related vulnerability. Since the exploit code is already published online, is very easy to use, and poses a significant risk, we encourage all organizations to install the necessary updates. The exploit Our research started with an analysis of a POST request dump associated with this wave of attacks on SharePoint servers. We can see that this POST request targets the “/_layouts/15/ToolPane.aspx” endpoint and embeds two parameters: “MSOtlPn_Uri” and “MSOtlPn_DWP”. Looking at the code of ToolPane.aspx, we can see that this file itself does not contain much functionality and most of its code is located in the ToolPane class of the Microsoft.SharePoint.WebPartPages namespace in Microsoft.SharePoint.dll. Looking at this class reveals the code that works with the two parameters present in the exploit. However, accessing this endpoint under normal conditions is not possible without bypassing authentication on the attacked SharePoint server. This is where the first Microsoft SharePoint Server Spoofing Vulnerability CVE-2025-49706 comes into play. CVE-2025-49706 This vulnerability is present in the method PostAuthenticateRequestHandler, in Microsoft.SharePoint.dll. SharePoint requires Internet Information Services (IIS) to be configured in integrated mode. In this mode, the IIS and ASP.NET authentication stages are unified. As a result, the outcome of IIS authentication is not determined until the PostAuthenticateRequest stage, at which point both the ASP.NET and IIS authentication methods have been completed. Therefore, the PostAuthenticateRequestHandler method utilizes a series of flags to track potential authentication violations. A logic bug in this method enables an authentication bypass if the “Referrer” header of the HTTP request is equal to “/_layouts/SignOut.aspx”, “/_layouts/14/SignOut.aspx”, or “/_layouts/15/SignOut.aspx” using case insensitive comparison. The code displayed in the image above handles the sign-out request and is also triggered when the sign-out page is specified as the referrer. When flag6 is set to false and flag7 is set to true, both conditional branches that could potentially throw an “Unauthorized Access” exception are bypassed. On July 8, 2025, Microsoft released an update that addressed this vulnerability by introducing additional checks to detect the usage of the “ToolPane.aspx” endpoint with the sign-out page specified as the referrer. The added check uses case insensitive comparison to verify if the requested path ends with “ToolPane.aspx”. Is it possible to bypass this check, say, by using a different endpoint? Our testing has shown that this check can be easily bypassed. CVE-2025-53771 We were able to successfully bypass the patch for vulnerability CVE-2025-49706 by adding just one byte to the exploit POST request. All that was required to bypass this patch was to add a “/” (slash) to the end of the requested “ToolPane.aspx” path. On July 20, 2025, Microsoft released an update that fixed this bypass as CVE-2025-53771. This fix replaces the “ToolPane.aspx” check to instead check whether the requested path is in the list of paths allowed for use with the sign-out page specified as the referrer. This allowlist includes the following paths: “/_layouts/15/SignOut.aspx”, “/_layouts/15/1033/initstrings.js”, “/_layouts/15/init.js”, “/_layouts/15/theming.js”, “/ScriptResource.axd”, “/_layouts/15/blank.js”, “/ScriptResource.axd”, “/WebResource.axd”, “/_layouts/15/1033/styles/corev15.css”, “/_layouts/15/1033/styles/error.css”, “/_layouts/15/images/favicon.ico”, “/_layouts/15/1033/strings.js”, “/_layouts/15/core.js”, and it can contain additional paths added by the administrator. While testing the CVE-2025-49706 bypass with the July 8, 2025 updates installed on our SharePoint debugging stand, we noticed some strange behavior. Not only did the bypass of CVE-2025-49706 work, but the entire exploit chain did! But wait! Didn’t the attackers use an additional Microsoft SharePoint Remote Code Execution Vulnerability CVE-2025-49704, which was supposed to be fixed in the same update? To understand why the entire exploit chain worked in our case, let’s take a look at the vulnerability CVE-2025-49704 and how it was fixed. CVE-2025-49704 CVE-2025-49704 is an untrusted data deserialization vulnerability that exists due to improper validation of XML content. Looking at the exploit POST request, we can see that it contains two URL encoded parameters: “MSOtlPn_Uri” and “MSOtlPn_DWP”. We can see how they are handled by examining the code of the method GetPartPreviewAndPropertiesFromMarkup in Microsoft.SharePoint.dll. A quick analysis reveals that “MSOtlPn_Uri” is a page URL that might be pointing to an any file in the CONTROLTEMPLATES folder and the parameter “MSOtlPn_DWP” contains something known as WebPart markup. This markup contains special directives that can be used to execute safe controls on a server and has a format very similar to XML. While this “XML” included in the “MSOtlPn_DWP” parameter does not itself contain a vulnerability, it allows attackers to instantiate the ExcelDataSet control from Microsoft.PerformancePoint.Scorecards.Client.dll with CompressedDataTable property set to malicious payload and trigger its processing using DataTable property getter. Looking at the code of the ExcelDataSet’s DataTable property getter in Microsoft.PerformancePoint.Scorecards.Client.dll, we find the method GetObjectFromCompressedBase64String, responsible for deserialization of CompressedDataTable property contents. The data provided as Base64 string is decoded, unzipped, and passed to the BinarySerialization.Deserialize method from Microsoft.SharePoint.dll. Attackers use this method to provide a malicious DataSet whose deserialized content is shown in the image above. It contains an XML with an element of dangerous type "System.Collections.Generic.List1[[System.Data.Services.Internal.ExpandedWrapper2[...], System.Data.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]", which allows attackers to execute arbitrary methods with the help of the well-known ExpandedWrapper technique aimed at exploitation of unsafe XML deserialization in applications based on the .NET framework. In fact, this shouldn’t be possible, since BinarySerialization.Deserialize in Microsoft.SharePoint.dll uses a special XmlValidator designed to protect against this technique by checking the types of all elements present in the provided XML and ensuring that they are on the list of allowed types. However, the exploit bypasses this check by placing the ExpandedWrapper object into the list. Now, to find out why the exploit worked on our SharePoint debugging stand with the July 8, 2025 updates installed, let’s take a look at how this vulnerability was fixed. In this patch, Microsoft did not really fix the vulnerability but only mitigated it by adding the new AddExcelDataSetToSafeControls class to the Microsoft.SharePoint.Upgrade namespace. This class contains new code that modifies the web.config file and marks the Microsoft.PerformancePoint.Scorecards.ExcelDataSet control as unsafe. Because SharePoint does not execute this code on its own after installing updates, the only way to achieve the security effect was to manually run a configuration upgrade using the SharePoint Products Configuration Wizard tool. Notably, the security guidance for CVE-2025-49704 does not mention the need for this step, which means at least some SharePoint administrators may skip it. Meanwhile, anyone who installed this update but did not manually perform a configuration upgrade remained vulnerable. CVE-2025-53770 On July 20, 2025, Microsoft released an update with a proper fix for the CVE-2025-49704 vulnerability. This patch introduces an updated XmlValidator that now properly validates element types in XML, preventing exploitation of this vulnerability without requiring a configuration upgrade and, more importantly, addressing the root cause and preventing exploitation of the same vulnerability through controls other than Microsoft.PerformancePoint.Scorecards.ExcelDataSet. CVE-2020-1147 Readers familiar with previous SharePoint exploits might feel that the vulnerability CVE-2025-49704/CVE-2025-53770 and the exploit used by the attackers looks very familiar and very similar to the older .NET Framework, SharePoint Server, and Visual Studio Remote Code Execution Vulnerability CVE-2020-1147. In fact, if we compare the exploit for CVE-2020-1147 and an exploit for CVE-2025-49704/CVE-2025-53770, we can see that they are almost identical. The only difference is that in the exploit for CVE-2025-49704/CVE-2025-53770, the dangerous ExpandedWrapper object is placed in the list. This makes CVE-2025-53770 an updated fix for CVE-2020-1147. Conclusions Despite the fact that patches for the ToolShell vulnerabilities are now available for deployment, we assess that this chain of exploits will continue being used by attackers for a long time. We have been observing the same situation with other notorious vulnerabilities, such as ProxyLogon, PrintNightmare, or EternalBlue. While they have been known for years, many threat actors still continue leveraging them in their attacks to compromise unpatched systems. We expect the ToolShell vulnerabilities to follow the same fate, as they can be exploited with extremely low effort and allow full control over the vulnerable server. To stay better protected against threats like ToolShell, we as a community should learn lessons from previous events in the industry related to critical vulnerabilities. Specifically, the speed of applying security patches nowadays is the most important factor when it comes to fighting such vulnerabilities. Since public exploits for these dangerous vulnerabilities appear very soon after vulnerability announcements, it is paramount to install patches as soon as possible, as a gap of even a few hours can make a critical difference. At the same time, it is important to protect enterprise networks against zero-day exploits, which can be leveraged when there is no available public patch for vulnerabilities. In this regard, it is critical to equip machines with reliable cybersecurity solutions that have proven effective in combatting ToolShell attacks before they were publicly disclosed. Kaspersky Next with its Behaviour detection component proactively protects against exploitation of these vulnerabilities. Additionally, it is able to detect exploitation and the subsequent malicious activity. Kaspersky products detect the exploits and malware used in these attacks with the following verdicts: UDS:DangerousObject.Multi.Generic PDM:Exploit.Win32.Generic PDM:Trojan.Win32.Generic HEUR:Trojan.MSIL.Agent.gen ASP.Agent.* PowerShell.Agent.*
2 shared
Jul 28, 2025
Chinese state hackers use rootkit to hide ToneShell malware activity
The Chinese hacking group known as Mustang Panda has leveraged a previously undocumented kernel-mode rootkit driver to deliver a new variant of backdoor dubbed TONESHELL in a cyber attack detected in mid-2025 targeting an unspecified entity in Asia. The findings come from Kaspersky, which observed the new backdoor variant in cyber espionage campaigns mounted by the hacking group targeting
2 shared
Dec 30, 2025
TeamPCP deploys Iran-targeted wiper in Kubernetes attacks
The TeamPCP hacking group has expanded its open source software campaign from the Trivy supply chain attack to NPM, Docker Hub, VS Code, and PyPI, and likely partnered with the Lapsus$ gang for monetization purposes. The attack on Aqua Security’s widely used Trivy vulnerability scanner started with the compromise of an access token in late February. Because the maintainers did not rotate all credentials and secrets simultaneously, the hackers were able to maintain access to the compromised environment. OpenSourceMalware reports with high confidence that the attackers compromised the Argon-DevOps-Mgt service account token, which provided them with write/admin access to both Aqua Security’s internal and public-facing repositories. The attack has been attributed to TeamPCP (also known as DeadCatx3, PCPcat, and ShellForce), which was behind a December worm-driven campaign that targeted Docker, Kubernetes, Ray, and Redis, and which also exploited the React2Shell vulnerability, according to Flare. In the Trivy supply chain attack, now tracked as CVE-2026-33634 (CVSS score of 9.4), the hackers released malicious package versions and modified GitHub Actions tags to push information-stealing malware that would harvest credentials, keys, tokens, and other sensitive data. In early March, a similar attack hit Xygeni: compromised credentials linked to repository automation were used to introduce malicious code. Initially, the attackers relied on pull requests, but when that failed, they modified a mutable tag to reference a malicious commit, leading to downstream infections. “While the attack leveraged a known GitHub Actions vulnerability involving mutable tags, the incident also highlights the importance of comprehensive repository protection, strict credential management, and defense-in-depth across CI/CD systems,” Xygeni notes in its incident report. The Trivy attack and blast radius TeamPCP started pushing malware to the Trivy repositories on March 19, but the multi-stage supply chain attack has been contained and is now in the remediation and documentation phase, Aqua said on Wednesday. However, it took five days to fully evict the attackers. Three days after the containment and remediation efforts started, the attackers published malicious Trivy Docker Hub images (v0.69.5 and v0.69.6), confirming that their access had not been blocked, Trivy’s maintainers revealed. “Working closely with Sygnia, we are developing formal documentation that includes the confirmed timeline, actions taken to remediate the incident, and supporting materials for customer assurance and attestation. This effort is informed by a comprehensive review of credentials, access controls, and affected systems,” Aqua says. What made the attack stand out was the use of modified GitHub Action tags to reference malware without any visible changes to the tag name, published dates, or the release page, allowing the attackers to operate under the radar. According to a SANS Institute report seen by SecurityWeek, more than 10,000 CI/CD workflows were affected by the Trivy incident. Every CI/CD pipeline referencing the modified GitHub Actions automatically executed the malicious code, dropping TeamPCP’s information stealer and exposing secrets, credentials, and infrastructure. To evade detection on the infected systems, malicious code contains instructions to remove all its temporary files after performing its multi-stage credential theft and exfiltration operation, CrowdStrike explains. “The remainder of the script is a functional copy of the real trivy-action entry point. It downloads and runs Trivy normally, producing expected scanner output. To an operator reviewing workflow logs, the step appears to have completed successfully,” the cybersecurity company notes. The Checkmarx attack On March 23, TeamPCP hit Checkmarx’s KICS open-source project, publishing malicious versions of the checkmarx.cx-dev-assist and checkmarx.ast-results VS Code plugins to the OpenVSX marketplace. Like the Trivy attack, the hackers injected malicious payloads into the plugins by force-pushing tags that were pointing to malicious commits. A total of 35 GitHub Action version tags were hijacked, SANS Institute says. Checkmarx has since updated GitHub Actions to ast-github-action v2.3.33 and kics-github-action v2.1.20 and permanently removed all previous versions from its repositories. The malicious plugin iterations, namely ast-results 2.53.0 and cx-dev-assist 1.7.0, should be immediately removed. “Upon discovery, we removed the malicious artifacts, pinned our workflows to safe verified commit SHAs, revoked and rotated all exposed credentials, blocked outbound access to the attacker-controlled domain, and reviewed our environments for any signs of further compromise,” Checkmarx says. The cybersecurity firm warns all organizations that downloaded or ran a compromised version of the two plugins from Open VSX to rotate all secrets and environment variables. GitHub credentials, Personal Access Tokens (PATs), repository and organization secrets, SSH keys, Docker registry credentials, Kubernetes service account tokens, and GitHub, Microsoft Azure, Google Cloud (GCP), and AWS access tokens should be considered compromised and immediately rotated. As ReversingLabs points out, the two VS Code extensions have a combined download count of over 36,000 and are designed for use within VS Code and compatible integrated development environments (IDEs), such as Cursor, Kiro, and Windsurf, making the attack’s blast radius large. CanisterWorm and the NPM attacks Last week, TeamPCP’s campaign also targeted the NPM ecosystem, using read/write access tokens to push malware downstream and using the same infostealer from the Trivy attack. The NPM supply chain attack hit at least 64 unique packages and affected more than 140 package artifacts, injecting install-time malware that relies on an Internet Computer Protocol (ICP) canister dead drop to deliver follow-on binaries. Dubbed CanisterWorm, the final payload contains a component that uses compromised NPM publishing credentials to inject the payload into additional packages. To evade detection, it preserves the legitimate README files, Socket explains. As the attack unfolded, the hackers were seen updating their code, moving from using a postinstall hook to write a Python payload, install it as a systemd –user service, and execute it, to using a hardcoded Python dropper and using the service name pgmon for persistence. According to Aikido, the malware was initially similar to the one used in the Trivy attack, but was later updated with the worm component that allowed it to use harvested NPM tokens and environment variables and spawn a persistent background process using them, to infect additional packages. “Every developer or CI pipeline that installs this package and has an NPM token accessible becomes an unwitting propagation vector. Their packages get infected, their downstream users install those, and if any of them have tokens, the cycle repeats,” Aikido notes. The Kubernetes wiper targeting Iran The same ICP canister used in the CanisterWorm attack on NPM was also used in a campaign targeting Kubernetes. The main difference was that the code included a wiper aimed at Iran-based clusters. The payload contains standard Kubernetes pod detection, deploys privileged DaemonSets across every node, and drops the CanisterWorm backdoor on them as a systemd service, achieving persistence as PostgreSQL tooling. In more recent iterations of the attack, the malware added network-based lateral movement, using SSH via compromised keys and auth log parsing, and exploiting exposed Docker APIs, Aikido reports. The code also checks the system timezone and locale and, if it detects machines configured for Iran, drops a DaemonSet to wipe the entire cluster. Dubbed “kamikaze”, the wiper mounts the host’s root filesystem, erases the top-level content, and then forces a reboot. The operation is performed on all nodes, including the control plane, destroying the entire cluster. “The Kubernetes-native lateral movement via DaemonSets is consistent with TeamPCP’s known playbook, but this variant adds something we haven’t seen from them before: a geopolitically targeted destructive payload aimed specifically at Iranian systems,” Aikido notes. On non-Kubernetes systems configured for Iran, if root access is available, the malware wipes everything. If it does not have root access, it “tries passwordless sudo, then tries anyway. Even without root, it’ll destroy everything the user owns,” Aikido notes. The PyPI attack and LiteLLM compromise In its most recent phase, TeamPCP’s campaign moved to the PyPI ecosystem, compromising LiteLLM, an open source Python library and proxy server that has more than 95 million monthly downloads. LiteLLM versions 1.82.7 and 1.82.8 were injected with the same information-stealing and dropper malware observed in the other TeamPCP attacks, with the same goal: the compromise of valuable credentials for broad access. The malicious code in LiteLLM 1.82.8 “fires on every Python invocation in the environment” and “runs silently in the background without delaying Python startup,” EndorLabs explains. Used as a unified interface between applications and AI service providers such as Anthropic, Google, and OpenAI, LiteLLM supports over 100 LLM APIs and typically has access to sensitive information such as API keys and environment variables. “Additionally, the breadth of data targeted by the malware underscores how modern development environments — spanning local machines, CI/CD pipelines, and cloud infrastructure — are deeply interconnected. A single compromised dependency can expose credentials across multiple systems, dramatically increasing the potential blast radius,” Sonatype notes. LiteLLM compromise has provided the attackers with access to all the secrets the library touches, and the impact from the attack is broad: approximately 300GB of data was exfiltrated from around 500,000 infected machines, threat intelligence and research project Vx-Underground says. ReversingLabs says that the hackers likely compromised the GitHub account of LiteLLM co-founder and CEO Krish Dholakia on March 23 and then defaced the LiteLLM GitHub repositories in an automated manner the next day. Organizations that installed or executed the malicious LiteLLM versions should immediately remove the packages, rotate all credentials, and investigate the affected systems for suspicious connections, persistence mechanisms, and potentially affected packages. According to cybersecurity outfit Wiz, LiteLLM is present in 36% of all cloud environments, providing hackers with a foothold in highly sensitive parts of the development lifecycle. “In many cases, rebuilding affected systems from a known clean state may be the safest course of action,” Sonatype notes. The Lapsus$ connection In addition to expanding across multiple OSS communities, TeamPCP’s campaign has escalated to a monetization phase. The group is openly taking credit for the attacks and appears to have partnered with the Lapsus$ extortion group for financial gain. TeamPCP has boasted on its Telegram account about the Trivy compromise, the GitHub Actions attacks, the OpenVSX extensions incident, and the PyPI hack, stating a clear focus on security tools and high-leverage points within the OSS ecosystem. The group also claims its operation is still unfolding, saying that it will be “stealing terabytes of trade secrets with our new partners”, Socket reports. While the ‘partners’ were not named, it appears that the hacking group was hinting at Lapsus$, which boasted on its Telegram account about an upcoming supply chain attack from TeamPCP. According to Wiz, this explicit collaboration between the two threat actors is an ecosystem-wide ‘cascade’ aimed at the modern cloud-native and AI ecosystems. “We are seeing a dangerous convergence between supply chain attackers and high-profile extortion groups like Lapsus$,” Wiz lead researcher Ben Read told SecurityWeek. “By moving horizontally across the ecosystem – hitting tools like LiteLLM that are present in over a third of cloud environments – they are creating a ‘snowball effect.’ This isn’t an isolated incident; it’s a systemic campaign that requires security teams to take action and will likely continue to expand,” Read added. The partnership between the two groups also appears to explain why some security researchers linked the AstraZeneca data breach to TeamPCP’s campaign, while Lapsus$ has claimed responsibility for it. Related: Polyfill Supply Chain Attack Impacting 100k Sites Linked to North Korea Related: New ‘Sandworm_Mode’ Supply Chain Attack Hits NPM Related: Autonomous AI Agents Provide New Class of Supply Chain Attack Related: ‘PackageGate’ Flaws Open JavaScript Ecosystem to Supply Chain Attacks
2 shared
Mar 25, 2026
TeamPCP deploys Iran-targeted wiper in Kubernetes attacks
This is the second update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). Update 001 covered developments through March 26. This update covers developments from March 26-27, 2026. CRITICAL: Telnyx Python SDK Compromised on PyPI -- New WAV Steganography TTP TeamPCP compromised the telnyx Python SDK (670,000+ monthly downloads) on PyPI, publishing malicious versions 4.87.1 and 4.87.2 at approximately 03:51 UTC on March 27, 2026. No corresponding GitHub releases or tags exist for these versions -- the attacker used stolen PyPI credentials rather than a repository compromise. The most significant technical finding is a new TTP: WAV audio file steganography. Payloads are embedded inside .wav files, which blend naturally with Telnyx's purpose as a voice and telecom API provider. Platform-specific payloads are delivered: Windows: A persistent binary dropped to the Startup folder as msbuild.exe Linux/macOS: A credential harvester following the same pattern as the LiteLLM compromise Forensic analysis by Aikido Security, JFrog, and SafeDep confirms the same RSA-4096 public key and tpcp.tar.gz exfiltration pattern seen in the LiteLLM compromise. Both malicious versions have been quarantined by PyPI. Recommended action: Check your Python environments and CI/CD pipelines for telnyx versions 4.87.1 or 4.87.2. If found, treat all credentials accessible to that environment as compromised and rotate immediately. The last known-safe version is 4.87.0. Also search for .wav files in unexpected locations, msbuild.exe in Windows Startup folders, and outbound connections to known TeamPCP exfiltration domains. This confirms the "expansion to additional PyPI packages" watch item from Update 001. TeamPCP's PyPI campaign is not limited to LiteLLM -- they are actively working through stolen credentials to compromise additional high-value packages. CRITICAL: TeamPCP Partners with Vect Ransomware and BreachForums for Mass Affiliate Program TeamPCP has formally partnered with the Vect ransomware-as-a-service operation and BreachForums. Per Cybernews and Infosecurity Magazine, the announcement states that all approximately 300,000 registered BreachForums users will receive personal Vect affiliate keys. The operational model: TeamPCP provides initial access via compromised supply chain packages and stolen credentials, Vect provides encryption and extortion tooling, and BreachForums provides the operator base. Analysts assess this represents a fundamental shift from supply chain credential theft to industrialized ransomware deployment. If even a small fraction of 300,000 users activate, this could become one of the largest coordinated ransomware affiliate mobilizations observed. The convergence of supply chain compromise, ransomware-as-a-service, and dark web forum mobilization at this scale is, to the best of our knowledge, unprecedented. Recommended action: Organizations that were exposed to any phase of the TeamPCP campaign (Trivy, Checkmarx, LiteLLM, Telnyx) should assume their stolen credentials may now be distributed to a large affiliate network. Credential rotation is no longer optional -- it is urgent. Monitor for Vect ransomware indicators. HIGH: LAPSUS$ Claims 3GB AstraZeneca Breach Using TeamPCP Credentials LAPSUS$ is publicly claiming a 3GB breach of AstraZeneca, as reported by SecurityWeek and CSO Online. The claimed data includes internal code repositories, cloud infrastructure configurations (AWS, Azure, Terraform), Spring Boot configs, GitHub Enterprise user information, and employee data. LAPSUS$ is selling access via Session encrypted messaging. This is the first named victim claim from the TeamPCP/LAPSUS$ partnership, confirming the "named victim breach disclosures" watch item from Update 001. AstraZeneca has not confirmed or denied the breach as of publication time. Recommended action: Organizations should not wait for public victim disclosures to take action. If you were exposed to any TeamPCP-compromised component, assume credential theft occurred and rotate proactively. The extortion timeline is accelerating. HIGH: LiteLLM CEO's Personal GitHub Account Was the Compromise Vector ReversingLabs has published new intelligence identifying the specific mechanism behind the LiteLLM PyPI compromise: TeamPCP compromised Krish Dholakia's personal GitHub account (LiteLLM co-founder and CEO) on March 23-24. This was not a generic CI/CD token sweep -- the attacker specifically identified and targeted a named executive's account from the stolen credential trove harvested during the Trivy/Checkmarx phase. This detail refines the attack chain narrative. TeamPCP appears to be triaging stolen credentials for maximum impact, targeting package maintainers with PyPI publishing privileges rather than indiscriminately using every credential they harvested. MEDIUM: CISA KEV Remediation Deadline Correction -- April 8, Not April 3 Update 001 reported the CISA KEV remediation deadline for CVE-2026-33634 as April 3, 2026. The official CISA KEV catalog entry shows the actual deadline is April 8, 2026. This update corrects the previously reported date. Additionally, Help Net Security reports that CISA simultaneously added CVE-2026-33017 (Langflow unauthenticated RCE, affecting versions prior to 1.8.2) alongside the Trivy CVE in the same KEV update. The pairing of two AI/ML infrastructure tool vulnerabilities in a single KEV addition signals that CISA is treating AI toolchain supply chain security as a systemic risk category. Federal agencies now face remediation deadlines of April 8 for CVE-2026-33634 (Trivy) and April 9 for CVE-2026-33017 (Langflow). INFO: LiteLLM's Compliance Certifications Performed by Embattled Auditor TechCrunch reported on March 26 that LiteLLM's SOC2 and ISO 27001 certifications were performed by Delve, a YC startup currently under scrutiny for allegations of "rubber-stamped" compliance audits. This intersection of two Silicon Valley scandals raises questions about the effectiveness of third-party compliance certifications in the AI/ML supply chain ecosystem. HIGH: First Responder Publishes Full Attack Transcript With New IOCs FutureSearch has published the full forensic transcript from Callum McMahon, the engineer who first discovered the compromised LiteLLM package and coordinated the PyPI quarantine on March 24. McMahon used Claude Code to perform real-time forensic analysis of the malicious litellm==1.82.8 package in an isolated Docker environment, producing what is likely the most detailed public record of this attack's execution. Key technical findings not previously documented in the campaign report: .pth file exploitation: The payload (litellm_init.pth , 34 KB) exploited Python's automatic.pth site-packages execution, triggering on every Python interpreter startup -- not just when LiteLLM was imported. This is a persistence mechanism that runs across all Python processes in the environment. C2 domain: models.litellm.cloud -- a typosquat of LiteLLM's legitimate infrastructure, used for HTTPS exfiltration with RSA encryption. Persistence path: ~/.config/sysmon/sysmon.py with systemd service registration. In McMahon's case, the write was interrupted at 0 bytes by a forced reboot. Kubernetes lateral movement: The payload attempted to create privileged alpine:latest pods and harvest service account tokens from/var/run/secrets/kubernetes.io/serviceaccount/token , usingnode-setup-* pod naming to blend with legitimate infrastructure. Multi-cloud credential sweep: A single payload targeted SSH keys, AWS/GCP/Azure credentials, Kubernetes tokens, .env files, database passwords, crypto wallets, and shell history simultaneously. Accidental fork bomb: The .pth auto-execution combined with subprocess spawning created exponential process multiplication -- each child Python process re-triggered the payload, causing resource exhaustion that inadvertently exposed the attack. The 72-minute timeline from detection to public PyPI quarantine demonstrates how AI-assisted forensic analysis dramatically accelerated incident response. This transcript is highly instructive for defenders studying the attack mechanics and should be reviewed by any team performing forensic analysis of TeamPCP-compromised environments. Recommended action: Search environments for the C2 domain models.litellm.cloud, the persistence path ~/.config/sysmon/sysmon.py, unexpected .pth files in site-packages directories, and node-setup-* pods in Kubernetes clusters. These IOCs supplement the indicators in the parent report. INFO: GitHub Announces Actions Security Roadmap in Response to Supply Chain Attacks GitHub has published a 2026 security roadmap for GitHub Actions that directly references the TeamPCP campaign. The blog post states: "incidents targeting projects like tj-actions/changed-file, Nx, and trivy-action show a clear pattern: attackers are targeting CI/CD automation itself." The roadmap introduces three categories of controls that, if implemented at the time of the Trivy compromise, would have materially altered the attack surface: Workflow dependency locking: A new dependencies: section in workflow YAML pins all direct and transitive action references to immutable commit SHAs. Hash mismatches stop execution before jobs run. This directly addresses the tag-rewriting TTP that TeamPCP used to redirect 76 trivy-action tags and all 91 ast-github-action tags to malicious commits. Public preview in 3-6 months. Policy-driven execution controls: Rulesets-based policies that restrict which actors can trigger workflows, which events are permitted, and which execution contexts can access secrets. Scoped secrets prevent a single compromised token from accessing all repository secrets. Public preview in 3-6 months. Egress firewall for hosted runners: Layer 7 network monitoring and enforcement for GitHub-hosted runners, restricting which external domains workflows can reach. This would have blocked the exfiltration to scan.aquasecurtiy[.]org andmodels.litellm.cloud . Public preview in 6-9 months. Analysts assess these controls represent the most substantive platform-level response to the GitHub Actions supply chain attack vector to date. However, the 3-9 month rollout timeline means organizations remain exposed to tag-rewriting and credential theft TTPs in the interim. Pinning actions to full commit SHAs remains the primary defensive measure until dependency locking reaches GA. Additional Intelligence Kaspersky publishes independent verification: Kaspersky published their own technical advisory characterizing this as a unified "trojanization" campaign, independently verifying the attack chain and broadening awareness to their enterprise customer base. GitGuardian draws "Shai Hulud" parallel: GitGuardian frames the campaign alongside the "Shai Hulud" attack pattern -- both targeting CI/CD pipelines to harvest secrets rather than attacking applications directly. Their analysis emphasizes that Aqua Security's non-atomic credential rotation was the root cause enabling the second compromise wave (Docker Hub images v0.69.5 and v0.69.6 on March 22). Corrections to Update 001 Aqua Security "additional findings" deadline: Update 001 stated "Aqua Security promised additional findings by end of day March 26" as a watch item. This was incorrect. On March 23, 2026, Aqua Security's blog stated they would "provide a further update, including additional findings, tomorrow end of day" -- meaning end of day March 24, not March 26. Aqua published their comprehensive incident report, "Trivy Supply Chain Attack: What Happened and What You Need to Know", on March 24 at 23:00 UTC, meeting their stated deadline. The report covers the full attack timeline, root cause (non-atomic credential rotation after the March 1 incident), and remediation details. This is no longer a watch item. CISA KEV remediation deadline: Also corrected in this update's MEDIUM finding above -- April 8, not April 3 as originally reported in Update 001. Watch Items Vect ransomware affiliate key distribution and first deployments linked to TeamPCP credentials Additional PyPI packages compromised via stolen credentials (telnyx confirms the pattern) AstraZeneca confirmation or denial of the LAPSUS$ breach claim Mandiant formal attribution report (BerriAI engagement announced, report pending) CISA standalone advisory or emergency directive (KEV entries issued, no dedicated advisory yet) Expansion to RubyGems, crates.io, or Maven Central (Endor Labs prediction, not yet confirmed) LiteLLM/BerriAI forensics completion and release resumption The full campaign report is available at sans.org/white-papers/when-security-scanner-became-weapon. A SANS Emergency Webcast replay is available at sans.org/webcasts/when-security-scanner-became-weapon. Updates to the report will be in the form of these ISC diaries.
2 shared
Mar 28, 2026
GlassWorm attack installs fake browser extension for surveillance
Supply-chain attacks have been one of the most dangerous categories of cybersecurity incidents for years now. And if 2025 taught us anything, it’s that cybercriminals are doubling down on them. In this deep dive, we’re looking at supply-chain attacks from 2025 that, while not always the costliest, were certainly the most unusual and caught the industry’s attention. January 2025: a RAT found in the DogWifTools GitHub repository As a “warm-up” after the holiday break, cybercriminals systematically backdoored several versions of DogWifTools. This is a utility designed for launching and vigorously promoting Solana-based meme coins on Pump.fun. After compromising the private GitHub repository for DogWifTools, the attackers waited for the developers to upload a fresh build, injected a RAT into it, and then swapped the legitimate program with their malicious version just a few hours later. According to the developers, the threat actors successfully trojanized versions 1.6.3 through 1.6.6 of DogWifTools for Windows. The endgame was triggered in late January. After using the RAT to harvest a massive amount of data from infected devices, the attackers drained their victims’ crypto wallets. While victims estimate the total haul at over US$10 million in cryptocurrency, the attackers themselves disputed that figure — though they stopped short of revealing exactly how much they’d actually made off with. February 2025: the US$1.5 billion Bybit heist If January was a warm-up, February was a total meltdown. The Bybit crypto exchange hack completely eclipsed previous incidents — becoming the largest crypto heist in history. The attackers managed to compromise the Safe{Wallet} software, the multisig cold storage solution the exchange relied on to manage its assets. Bybit employees thought they were signing a routine transaction; in reality they were authorizing a malicious smart contract. Once executed, it drained a primary cold wallet, dispersing the funds across several hundred attacker-controlled addresses. The final haul exceeded 400 000 ETH/stETH, with a staggering total value of approximately… US$1.5 billion! March 2025: Coinbase targeted in a GitHub Actions cascading compromise Spring 2025 kicked off with a sophisticated attack that used a compromise of multiple GitHub Actions — the workflow patterns used to automate standard DevOps tasks — as its primary delivery mechanism. It all started with the theft of a personal access token belonging to a maintainer of the SpotBugs analysis tool. Using this foothold, the attackers published a malicious process and managed to hijack a token from a maintainer of the reviewdog/action-setup workflow, who was also involved in the project. From there, they compromised a dependency, the tj-actions/changed-files workflow, modifying it to execute a malicious Python script. This script was designed to hunt for high-value secrets, such as AWS, Azure and Google Cloud keys, GitHub and NPM tokens, database credentials, and RSA private keys. Oddly, the script wrote everything it found directly to publicly accessible build logs. This meant the leaked data wasn’t just available to the attackers, but to anyone savvy enough to look. The original goal of this operation was a repository belonging to the Coinbase crypto exchange. Fortunately, the developers caught the threat in time and prevented the compromise. After apparently realizing they were about to lose control of the tj-actions/changed-files pipeline, the attackers pivoted to a spray-and-pray approach. This put 23 000 repositories at risk of a secrets leak. In the end, several hundred of those repositories actually saw their sensitive credentials exposed to the public. April 2025: a backdoor in 21 Magento extensions In April, an infection was discovered across a whole range of extensions for Magento, one of the most popular platforms for building online stores. The backdoor was embedded into 21 modules developed by three vendors: Tigren, Meetanshi, and MGS. These extensions were part of the infrastructure for several hundred e-commerce companies, including at least one multinational corporation. According to the researchers who discovered it, the backdoor was actually planted way back in 2019. In April 2025, the attackers finally triggered it to compromise websites and upload web shells. This was accomplished through a function embedded in the extensions that executed arbitrary code pulled from a license file. Ironically, the infected modules included MGS GDPR and Meetanshi CookieNotice. As the names suggest, these extensions were designed to help sites comply with user privacy and data processing regulations. In the end, instead of ensuring privacy, their use most probably led to the theft of user data and financial assets through web skimming. May 2025: ransomware distributed through a compromised MSP In May, ransomware actors from the DragonForce gang gained access to the infrastructure of an unnamed managed service provider (MSP) and used it to distribute their ransomware and steal data from the MSP’s client organizations. It appears the attackers exploited several vulnerabilities (including one critical flaw) in SimpleHelp, the remote monitoring and management tool used by the MSP. These vulnerabilities were discovered back in 2024 and were publicly disclosed and patched in January 2025. Unfortunately, the MSP evidently decided not to rush the update process — a delay the ransomware gang was more than happy to exploit. June 2025: a backdoor in over a dozen popular npm packages At the start of the summer, attackers hacked the account of one of the Gluestack library maintainers and used a stolen access token to inject backdoors into 17 npm packages. The most popular of these packages, @react-native-aria/interactions, boasted 125 000 weekly downloads, while all the compromised packages combined totaled over a million. What’s particularly interesting in this case are the steps the Gluestack developers took following the incident: first, they restricted GitHub repository access for secondary contributors; second, they enabled two-factor authentication (2FA) for publishing new versions; and third, they promised to implement secure development practices like pull-request-based workflow, systematic code reviews, audit logging, and so on. In other words, prior to the incident a project with hundreds of thousands of weekly downloads had no such measures in place. July 2025: popular npm packages infected through a phishing attack In July, npm packages were once again the stars of the show — including the widely used, succinctly named “is” package, which boasts 2.7 million weekly downloads. This JavaScript utility library provides a broad range of type-checking and value validation functions. To pull off a phishing strike against one of the project owners, attackers successfully utilized the oldest trick in the book: typosquatting (using the domain npnjs.com instead of npmjs.com) and a clone of the official npm website. They then used the compromised account to publish several of their own versions of the package with an embedded backdoor. The infection flew under the radar for six hours: plenty of time for a large number of developers to download the malicious npm packages. The same phishing tactic was deployed against other developers as well. The attackers leveraged several compromised developer accounts to distribute different variants of their malicious payload. There’s also a strong suspicion that they may have saved some of their haul for future attacks. August 2025: the s1ngularity attack and a leak of hundreds of developers’ secrets In late August, an incident dubbed “s1ngularity” continued the trend of targeting JavaScript developers. Attackers compromised Nx, a popular build system and CI/CD pipeline optimization tool. Malicious code injected into the packages searched through infected developer systems for a vast range of sensitive data, such as crypto wallet keys, npm and GitHub tokens, SSH keys, API keys, and more. Interestingly, the attackers used locally installed AI tools, such as Claude Code, Gemini CLI, and Amazon Q, to sniff out secrets on the victims’ machines. Everything they found was then posted to public GitHub repositories created in the victims’ names, using titles “s1ngularity-repository”, “s1ngularity-repository-0”, and “s1ngularity-repository-1”. As you might have guessed, that’s where the name of the attack comes from. Consequently, the private data of hundreds of developers ended up sitting in plain sight, where it could be accessed not just by the attackers, but by absolutely anyone with an internet connection. September 2025: a crypto stealer hits npm packages that have 2.6 billion weekly downloads The trend of npm package compromises rolled right into September. Following a fresh phishing campaign targeting JavaScript developers, attackers managed to inject malicious code into a few dozen high-profile projects. Some of these, specifically “chalk” and “debug”, boast hundreds of millions of weekly downloads; collectively, the infected packages were racking up over 2.6 billion downloads per week at the time of the breach — and they’ve only grown more popular since. The payload was a crypto stealer: malware designed to intercept cryptocurrency transactions and reroute them to the attackers’ wallets. Fortunately, despite successfully poisoning some of the world’s most popular projects, the attackers somehow managed to botch the final stage of their operation. In the end, they walked away with a measly US$925. Just a week later, another major incident struck: the first wave of the self-propagating Shai-Hulud malware, which infected around 150 npm packages, including projects from CrowdStrike. However, the second wave, which hit several months later, proved to be far more destructive. We’ll take a closer look at the Great Worm a bit further down. October 2025: GlassWorm infects the Visual Studio Code ecosystem Roughly a month after the Shai-Hulud attack, similar self-propagating malware dubbed GlassWorm began infecting Visual Studio Code extensions across both the Open VSX Registry and the Microsoft Extension Marketplace. The attackers were hunting for GitHub, Git, npm, and Open VSX accounts, as well as crypto wallet keys. The creators of GlassWorm took a highly creative approach to their command-and-control infrastructure: they used a crypto wallet on the Solana blockchain as their primary C2, with Google Calendar serving as a backup communication channel. Beyond simply draining victims’ crypto wallets and hijacking their accounts to spread the worm further, the attackers also dropped a RAT named Zombi onto infected devices, granting them total control over the compromised systems. November 2025: the IndonesianFoods campaign and 150 000 spam packages on npm In November, a new nuisance emerged within the npm registry. A coordinated malicious campaign dubbed IndonesianFoods saw attackers flood the registry with tens of thousands of useless packages. The primary goal here was gaming the system to inflate metrics and farm tokens on tea.xyz, a blockchain platform designed to reward open-source developers. To pull this off, the attackers built a massive web of interdependent projects with the names referencing Indonesian cuisine, such as zul-tapai9-kyuki or andi-rendang23-breki. The creators of this campaign didn’t bother hijacking accounts. Strictly speaking, the spam packages didn’t even contain a malicious payload — unless you count a script designed to automatically generate new packages every seven seconds. Nevertheless, the incident served as a stark reminder of how vulnerable the npm infrastructure is to large-scale spam campaigns. December 2025: Shai-Hulud 2.0 and the leak of 400 000 developer secrets The absolute headliner of the year — not just for supply-chain attacks, but likely for the entire cybersecurity field — was the self-propagating malware Shai-Hulud (also known as Sha1-Hulud) targeting developers. This malware was the logical evolution of the s1ngularity attack we mentioned earlier: it also scours systems for all kinds of secrets and publishes them in open GitHub repositories. However, Shai-Hulud added a self-propagation mechanism to this baseline: the worm infects projects controlled by already-compromised developers by using their stolen credentials. The first wave of Shai-Hulud hit in September, infecting several hundred npm packages. But toward the end of the year, a second wave arrived, dubbed Shai-Hulud 2.0. This time, the worm was upgraded with wiper functionality. If the malware failed to find valid npm or GitHub tokens on an infected system, it triggered a destructive payload that erased user files. Approximately 400 000 secrets were leaked in total as a result of the attack. It’s worth noting that, just like with s1ngularity, all this sensitive data ended up in public repositories where it could be downloaded not only by the attackers but by anyone else. And it’s highly likely that the fallout from this attack will be felt for a long time to come. One of the first, confirmed cases of an exploit using secrets leaked by Shai-Hulud was a cryptocurrency theft targeting several thousand Trust Wallet users. Attackers used these secrets on Christmas Eve to upload a malicious version of the Trust Wallet extension, complete with a built-in crypto drainer, to the Chrome Web Store. In the end, they managed to make off with US$8.5 million in cryptocurrency. How to protect against supply-chain attacks While putting together a similar retrospective for 2024, we found sticking to a “one month, one threat” structure fairly easy. For 2025, however, it was a much taller order. There were so many massive supply-chain attacks last year that we simply couldn’t fit them all into this one overview. The year 2026 is shaping up to be just as intense, so we recommend checking out our dedicated post on preventing supply-chain attacks. In the meantime, here are the essential takeaways: Thoroughly evaluate your vendors and carefully audit the code you integrate into your own projects. Implement strict security requirements directly into your service contracts. Develop a comprehensive incident response plan. Monitor your corporate infrastructure for suspicious activity using an XDR solution. If your internal security team is stretched thin, leverage an external service for proactive threat hunting and timely response. If you want to learn more about supply-chain attacks, have a read of our analytical report Supply chain reaction: securing the global digital ecosystem in an age of interdependence. It’s based on insights from technical experts, and reveals how often organizations face supply-chain and trusted-relationship risks, where protection gaps remain, and what strategies to employ to improve resilience against these kinds of threats.
2 shared
Mar 27, 2026
Update Microsoft SharePoint ASAP | Kaspersky official blog
The recently disclosed critical Microsoft SharePoint vulnerability has been under exploitation as early as July 7, 2025, according to findings from Check Point Research. The cybersecurity company said it observed first exploitation attempts targeting an unnamed major Western government, with the activity intensifying on July 18 and 19, spanning government, telecommunications, and software sectors in North America and Western Europe. Check Point also said the exploitation efforts originated from three different IP addresses – 104.238.159[.]149, 107.191.58[.]76, and 96.9.125[.]147 – one of which was previously tied to the weaponization of security flaws in Ivanti Endpoint Manager Mobile (EPMM) appliances (CVE-2025-4427 and CVE-2025-4428). "We're witnessing an urgent and active threat: a critical zero-day in SharePoint on-prem is being exploited in the wild, putting thousands of global organizations at risk," Lotem Finkelstein, Director of Threat Intelligence at Check Point Research, told The Hacker News. "Our team has confirmed dozens of compromise attempts across government, telecom, and tech sectors since July 7. We strongly urge enterprises to update their security systems immediately – this campaign is both sophisticated and fast-moving." The attack chains have been observed leveraging CVE-2025-53770, a newly patched remote code execution flaw in SharePoint Server, and chaining it with CVE-2025-49706, a spoofing vulnerability that was patched by Microsoft as part of its July 2025 Patch Tuesday update, to gain initial access and escalate privileges. It's worth mentioning at this stage that there are two sets of vulnerabilities in SharePoint that have come to light this month - CVE-2025-49704 (CVSS score: 8.8) - Microsoft SharePoint Remote Code Execution Vulnerability (Fixed on July 8, 2025) CVE-2025-49706 (CVSS score: 6.5) - Microsoft SharePoint Server Spoofing Vulnerability (Fixed on July 8, 2025) CVE-2025-53770 (CVSS score: 9.8) - Microsoft SharePoint Server Remote Code Execution Vulnerability CVE-2025-53771 (CVSS score: 6.5) - Microsoft SharePoint Server Spoofing Vulnerability CVE-2025-49704 and CVE-2025-49706, collectively referred to as ToolShell, is an exploitation chain that can lead to remote code execution on SharePoint Server instances. They were originally disclosed by Viettel Cyber Security during the Pwn2Own 2025 hacking competition earlier this May. CVE-2025-53770 and CVE-2025-53771, which became public knowledge over the weekend, have been described as variants of CVE-2025-49704 and CVE-2025-49706, respectively, indicating that they are bypasses for the original fixes put in place by Microsoft earlier this month. This is evidenced by the fact that Microsoft acknowledged active attacks exploiting "vulnerabilities partially addressed by the July Security Update." The company also noted in its advisories that the updates for CVE-2025-53770 and CVE-2025-53771 include "more robust protections" than the updates for CVE-2025-49704 and CVE-2025-49706. However, it bears noting that CVE-2025-53771 has not been flagged by Redmond as actively exploited in the wild. "CVE-2025-53770 exploits a weakness in how Microsoft SharePoint Server handles the deserialization of untrusted data," Martin Zugec, technical solutions director at Bitdefender, said. "Attackers are leveraging this flaw to gain unauthenticated remote code execution." This, in turn, is achieved by deploying malicious ASP.NET web shells that programmatically extract sensitive cryptographic keys. These stolen keys are subsequently leveraged to craft and sign malicious __VIEWSTATE payloads, thereby establishing persistent access and enabling the execution of arbitrary commands on SharePoint Server. According to Bitdefender telemetry, in-the-wild exploitation has been detected in the United States, Canada, Austria, Jordan, Mexico, Germany, South Africa, Switzerland, and the Netherlands, suggesting widespread abuse of the flaw. Palo Alto Networks Unit 42, in its own analysis of the campaign, said it observed commands being run to execute a Base64-encoded PowerShell command, which creates a file at the location "C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\16\TEMPLATE\LAYOUTS\spinstall0.aspx" and then parses its content. "The spinstall0.aspx file is a web shell that can execute various functions to retrieve ValidationKeys, DecryptionKeys, and the CompatabilityMode of the server, which are needed to forge ViewState Encryption keys," Unit 42 said in a threat brief. In an advisory issued Monday, SentinelOne said it first detected exploitation on July 17, with the cybersecurity company identifying three "distinct attack clusters," including state-aligned threat actors, engaging in reconnaissance and early-stage exploitation activities. Targets of the campaigns include technology consulting, manufacturing, critical infrastructure, and professional services tied to sensitive architecture and engineering organizations. "The early targets suggest that the activity was initially carefully selective, aimed at organizations with strategic value or elevated access," researchers Simon Kenin, Jim Walter, and Tom Hegel said. Analysis of the attack activity has revealed the use of a password-protected ASPX web shell ("xxx.aspx") on July 18, 2025, at 9:58 a.m. GMT. The web shell supports three functions: Authentication via an embedded form, command execution via cmd.exe, and file upload. Subsequent exploitation efforts have been found to employ the "spinstall0.aspx" web shell to extract and expose sensitive cryptographic material from the host. Spinstall0.aspx is "not a traditional command web shell but rather a reconnaissance and persistence utility," the researchers explained. "This code extracts and prints the host's MachineKey values, including the ValidationKey, DecryptionKey, and cryptographic mode settings -- information critical for attackers seeking to maintain persistent access across load-balanced SharePoint environments or to forge authentication tokens." Unlike other web shells that are typically dropped on internet-exposed servers to facilitate remote access, spinstall0.aspx appears to be designed with the sole intention of gathering cryptographic secrets that could then be used to forge authentication or session tokens across SharePoint instances. These attacks, per CrowdStrike, commence with a specially crafted HTTP POST request to an accessible SharePoint server via the "/_layouts/15/ToolPane.aspx" endpoint that attempts to write spinstall0.aspx via PowerShell. The company said it blocked hundreds of exploitation attempts across more than 160 customer environments. SentinelOne also discovered a cluster dubbed "no shell" that took a "more advanced and stealthy approach" to other threat actors by opting for in-memory .NET module execution without dropping any payloads on disk. The activity originated from the IP address 96.9.125[.]147. "This approach significantly complicates detection and forensic recovery, underscoring the threat posed by fileless post-exploitation techniques," the company said, positing that it's either a "skilled red team emulation exercise or the work of a capable threat actor with a focus on evasive access and credential harvesting." It's currently not known who is behind the attack activity, although Google-owned Mandiant has attributed the early-exploitation to a China-aligned hacking group. Data from Censys shows that there are 9,762 on-premises SharePoint servers online, although it's currently not known if all of them are susceptible to the flaws. Given that SharePoint servers are a lucrative target for threat actors due to the nature of sensitive organizational data stored in them, it's essential that users move quickly to apply the fixes, rotate the keys, and restart the instances. "We assess that at least one of the actors responsible for the early exploitation is a China-nexus threat actor," Charles Carmakal, CTO, Mandiant Consulting at Google Cloud, said in a post on LinkedIn. "We're aware of victims in several sectors and global geographies. The activity primarily involved the theft of machine key material which could be used to access victim environments after the patch has been applied." (The story was updated after publication on July 23, 2025, to reflect the change in CVSS scores.)
2 shared
Jul 22, 2025