New CTI Lab: CVE-2026-21858 (n8n RCE): Offensive
On January 7, 2026, Cyera Research Labs released an advisory for "Ni8mare," a critical unauthenticated remote code execution vulnerability (CVE-2026-21858) in n8n with a CVSS score of 10.0. The flaw stems from a "Content-Type Confusion" bug in the Form Webhook node, which allows attackers to override internal file paths, thereby enabling the arbitrary disclosure of sensitive data, including database.sqlite and the system's unique encryption key. This vulnerability can be exploited to forge administrative sessions and achieve full system takeover. What is this about? n8n has had a lot of vulnerabilities over the last year or so, in particular, these vulnerabilities have required authentication to exploit, meaning the attacker would already need access to the n8n server to leverage the vulnerability. This critical vulnerability has a CVSS score of 10.0, and attackers can achieve unauthenticated remote code execution - making it a poignant discussion point for potential future vulnerabilities and attacks, given that n8n will likely receive more attention from vulnerability researchers and threat actors alike. Why is this critical for you and your team? n8n is very popular with organization and the wider community alike, with over 70,000 active instances exposed to the internet; there is a reasonably wide attack surface to be exploited. If you or your team uses n8n, and there is a reasonably high probability that you do (for example in human resources, project planning, news feeds etc) then learning about and mitigating this vulnerability is essential to protect yourself against attacks. Who is the content for? Penetration Testers Security Analysts Incident Responders Here is a link to the lab: CVE-2026-21858 (n8n RCE): OffensiveNew CTI Lab: CVE-2025-55182 (React - Next.js)
On December 3, 2025, the cybersecurity world received news of a critical vulnerability in the React 19 ecosystem. This critical flaw, tracked as CVE-2025-55182 with a CVSS score of 10.0, affects React Server Components (RSC). A major issue, this flaw allows unauthenticated attackers to achieve Remote Code Execution (RCE) on vulnerable servers by sending a specially crafted HTTP request. AI Hallucination Within the first 24 hours of the vulnerability being announced, a POC was published to GitHub, which looked convincing and, when tested, appeared to achieve the goal successfully, resulting in Code Execution. It turned out that this POC, which was picked up and circulated by researchers and social media, was actually an AI Hallucination. The AI had crafted a deliberately misconfigured and vulnerable server and a POC that appeared to match the requirements of the exploit, but only actually triggered the misconfiguration. What is this about? CVE-2025-55182 is a critical Insecure Deserialization vulnerability. It affects React Server Components (RSC) within the React 19 ecosystem. The flaw is located in the server-side logic that handles the React Flight protocol, which is used for client-to-server interactions, specifically Server Functions or Server Actions. An unauthenticated attacker can execute a specially crafted HTTP request containing a malicious, serialized payload. The vulnerable server-side code fails to validate this payload, allowing the attacker to achieve remote code execution on the server. Why is this critical for you and your team? This critical vulnerability has a CVSS score of 10, is fairly trivial to exploit, and has significant impacts when successfully exploited, given that its impact includes unauthenticated remote code execution. If your team uses React, React Server Components (RSC), or similar, are at risk. This flaw impacts the standard, default configurations of high-profile frameworks like the Next.js App Router, which many organizations rely on for building high-performance sites. Who is the content for? Security Analysts Penetration Testers Incident Responders Vulnerability Management Teams Here is a link to the lab: CVE-2025-55182 (React - Next.js)New CTI Lab: Shai-Hulud 2.0: Analysis
In late November/early December 2025, a set of critical software supply chain intrusions took place when the highly dangerous Shai-Hulud 2.0 worm was used to steal GitHub, Cloud, and other credentials and secrets by gaining access to developer machines through the use of a malicious npm package installation. What is this about? By abusing the inherent trust in the npm ecosystem, Shai-Hulud guarantees execution during the crucial preinstall phase, effectively bypassing many traditional security scans that only review code after installation. Once running, the payload launches a concurrent, parallel attack across your environment: it hunts for local credentials, attempts to steal highly privileged temporary cloud tokens via the Instance Metadata Service (IMDS), and, most critically, can automatically inject itself into every other package the victim maintains on their machine. Why is this critical for you and your team? npm is massively popular, and many of the affected packages are widely used in software development and deployment. Shai-Hulud 2.0 is a devastating self-replicating worm that weaponizes your supply chain to steal highly privileged cloud credentials (IMDS) and establish a permanent C2 backdoor via GitHub Actions if the threat actor decides to set that up. Given the importance of npm packages to developers, customers from any organisation, and across all sectors, it is essential that they understand how this intrusion works to prevent their credentials and secrets from being stolen. Who is the content for? Security Analysts Incident Responders Software Developers/Secure Development teams Cloud Engineers Vulnerability Management Teams Here is a link to the lab: Shai-Hulud 2.0: AnalysisNew CTI Lab: Lazarus Cyberespionage Campaign: Analysis
In early November 2025, North Korean state-sponsored actor Lazarus was reported to have launched various attacks as part of a long-standing cyberespionage campaign linked to Operation DreamJob. Targets of the attacks include European organizations manufacturing unmanned aerial vehicles (UAV), aircraft component manufacturers, and British industrial automation organization. Lazarus's and by extension North Korea's operational objectives with these attacks is assessed with high confidence to be cyber espionage. What is this about? The attacks launched by Lazarus used a custom remote access trojan called ScoringMathTea RAT, which uses its own cipher system to obfuscate its code to conceal its functionality from analysts. The lab involves reverse engineering the malware and identify indicators of compromise by breaking the cipher and using that to identify what the malware is doing. Why is this critical for you and your team? North Korean cybercriminals and state sponsored actors are highly skilled, persistent, and aggressive in the pursuit of the North Korean regimes objectives, and one of those objectives is stealing information from targets that can affect national security. Understanding how North Korean cyber operators conduct attacks and understanding their tooling is essential for analysts to be better equipped to tackle these threats. Who is the content for? Malware Analysts and Reverse Engineers SOC Analysts Incident Responders Threat Hunters Tactical and Operational Cyber Threat Intelligence Analysts Here is a link to the lab: Lazarus Cyberespionage Campaign: AnalysisNew CTI Labs: CVE-2017-1000353 Offensive and Defensive (October 2025 CISA KEV Additions)
In October 2025, the Cybersecurity and Infrastructure Security Agency (CISA) added five new vulnerabilities to its known exploited vulnerabilities catalogue, one of which was a critical 2017 vulnerability affecting Jenkins versions 2.56 and earlier and 2.46 LTS and earlier. This vulnerability allowed attackers to gain remote code execution on vulnerable instances. Why is this critical for you and your team? Jenkins is a widely used application. Shodan reports confirm that there are 000s of instances exposed to the internet, with the vulnerable versions. With this vulnerability being a critical remote code execution vulnerability, the impact is significant. Understanding how to investigate logs for this attack and understanding how to successfully achieve exploitation is important for any team. Even though it's a 2017 vulnerability, it's a very recent addition to CISA KEV, which illustrates just how significant it is, and that even today, attackers are using this vulnerability to gain footholds and compromise vulnerable victims. Who is the lab for? SOC Analysts Incident Responders Penetration Testers Red Teamers Threat Hunters Here are the links to the labs: Offensive: https://immersivelabs.online/v2/labs/cve-2017-1000353-jenkins-command-injection-offensive Defensive: https://immersivelabs.online/v2/labs/cve-2017-1000353-jenkins-command-injection-defensiveNew Labs - Malterminal: Malware Analysis
With artificial intelligence (AI) and large language models (LLMs) fast becoming a more popular and talked-about set of technologies in every industry in society, it's no surprise that LLM-enabled malware now exists that can dynamically generate code, query data, and offload malicious functionality to LLMs, lowering the barrier of entry for threat actors deploying malware. This lab introduces one of the first known malware samples to ever facilitate the use of LLMs to perform malicious functionality. Why should our customers care? Most, if not all, companies are looking into using AI to varying degrees, whether to make their workforce more efficient and productive or to build full models that facilitate technical processes. With this in mind, and with the advent of basic malware that can use API keys to query LLMs and AI services, we will likely see this particular malware set evolve over time. By doing this lab, you'll begin to see how these pieces of malware are just the stub and querier for AI and how they can be used maliciously. This will showcase what this threat is like in its current state. We shall be monitoring how this threat evolves, so stay tuned for more labs. Who is the defensive lab for? SOC Analysts Incident Responders Threat Hunting Here is a link to the lab: https://immersivelabs.online/v2/labs/malterminal-analysisCVE-2025-53770: Critical Zero-Day RCE Vulnerability in Microsoft SharePoint Servers
An unauthenticated remote code execution (RCE) vulnerability, identified as CVE-2025-53770, has been discovered in on-premise Microsoft SharePoint Servers. This critical zero-day flaw allows attackers to execute arbitrary code on a server without needing to authenticate, posing a significant security risk. The vulnerability has been actively exploited in the wild, with researchers detecting an exploit chain as early as July 18, 2025. What is CVE-2025-53770? The vulnerability stems from insufficient validation of user-supplied data, which can be exploited by a specially crafted request to the server. This allows a remote attacker to execute code with the permissions of the SharePoint application pool, leading to a full compromise of the server – meaning they could have access to sensitive data, install malware, and even have complete control over the system. Which systems are affected? This vulnerability impacts multiple versions of on-premise Microsoft SharePoint servers: SharePoint Server Subscription Edition (Versions earlier than KB5002768) SharePoint Server 2019 (Versions earlier than 16.0.10417.20027/KB5002754) SharePoint Server 2016 (Specific version numbers vary, but generally earlier than the latest security updates) SharePoint Server 2013 and 2010 (While these are end-of-life and no longer supported, Microsoft still lists them as being potentially affected) How could attackers use this vulnerability? Bad actors are actively exploiting CVE-2025-53770 to gain initial access to corporate networks. Since the vulnerability is unauthenticated, attackers can scan the internet for vulnerable SharePoint servers and execute their exploit without needing any user credentials. Once exploited, they can deploy web shells to maintain persistent access, install ransomware, exfiltrate sensitive company data, or use the compromised server as a pivot point to move laterally within the network and attack other systems. The fact that it’s easy to exploit and the high level of access it grants make this a particularly dangerous vulnerability for any organization with an on-premise SharePoint deployment. How to protect your organization To protect your organization from this critical vulnerability, you need to take immediate action: Apply security patches Microsoft has released security updates to address this vulnerability. It’s crucial to apply these patches to all affected SharePoint servers immediately. Hunt for indicators of compromise (IoCs) Since this vulnerability was a zero-day and exploited in the wild, it’s essential to check for signs of a breach. Security teams should analyze SharePoint and web server logs for suspicious requests, particularly those involving unexpected file uploads or unusual processes being executed by the SharePoint application pool identity. Look for newly created .aspx or .ashx files in SharePoint directories that aren’t part of a standard installation. Implement network segmentation Restrict access to your SharePoint servers from the internet as much as possible. If external access is necessary, consider placing the server behind a web application firewall (WAF) with rules designed to block common web attack patterns. Enhance monitoring Increase monitoring of SharePoint servers for any anomalous behavior, such as unexpected outbound network connections, high CPU usage from SharePoint-related processes, or suspicious scheduled tasks being created. Conclusion In conclusion, CVE-2025-53770 represents a severe and immediate threat to organizations utilizing on-premise Microsoft SharePoint Servers. As a critical, unauthenticated remote code execution vulnerability being actively exploited in the wild, it provides a direct gateway for attackers to achieve a full compromise of server integrity, leading to potential data breaches, ransomware deployment, and significant operational disruption. Your response to this threat must be swift and comprehensive. Immediately applying Microsoft’s security patches is a critical first step to prevent exploitation. However, due to its nature as a zero-day exploit, organizations must also assume possible compromise and proactively hunt for IoCs. Strengthening network segmentation and enhancing monitoring are vital secondary measures to protect against this and future threats. Ultimately, a decisive and layered security response is essential to mitigate the substantial risks posed by this vulnerability. Recommended content To learn how to detect and exploit this vulnerability in a sandboxed environment, check out the following labs on the Immersive platform: Defensive: CVE-2025-53770 (ToolShell SharePoint RCE) Offensive: CVE-2025-53770 (ToolShell SharePoint RCE) Share your thoughts Have you seen this vulnerability being exploited in the wild? Have you patched your systems yet? Share your thoughts by commenting in the thread below.New CTI Lab: CVE-2025-9074 (Docker Container Escape): Defensive
Pvotal Technologies published a write-up for a vulnerability in Docker Engine, given a CVSS score of 9.3. CVE-2025-9074 is a flaw in Docker Desktop that exposes the Docker Engine API to any container, with no authentication. Exploitation of this critical vulnerability allows a low-privileged container to issue privileged API commands, take over other containers, and, in some cases, mount the host drive and access files and folders and eventually achieve remote code execution. Why should our customers care? Many organizations rely on containerization in their development teams, and a vulnerability like this could allow an attacker to gain access to any to developer's workstation by mounting a developer's host drive. The possibility of supply chain attacks is increased due to malicious containers that can be used by developers, which can have start-up scripts that mount and "escape" the containerized environment. Who is the defensive lab for? System Administrators Developers SOC Analysts Incident Responders Threat Hunting Here are the links to the labs: Defensive: https://immersivelabs.online/labs/cve-2025-9074-docker-container-escape-defensiveImmersiveOne: Scattered Spider Release
Scattered Spider has continuously been a threat to many of our customers, and one of the reasons is that they have techniques and tactics that can affect all members of an organization. From their advanced social engineering tactics targeting less security-focused users in an organization to bypassing defences long enough to deploy ransomware and steal data from some of the largest organizations in the world. Therefore, Immersive is releasing an ImmersiveOne approach to protecting our customers. This means customers now have access to the following: Lab – Scattered Spider and Dragonforce: Campaign Analysis Lab – Threat Actors: Scattered Spider Workforce Scenario – Social Engineering Techniques Crisis Sim – Responding to a Scattered Spider Attack The technical and non-technical labs, workforce scenario, and Crisis Sim scenario release will enable everyone inside an organization to prepare and be ready for threats posed by Scattered Spider. For an in-depth blog on Scattered Spider and what to think about in a crisis, follow the link here: https://www.immersivelabs.com/resources/blog/scattered-spider-what-these-breaches-reveal-about-crisis-leadership-under-pressureCVE-2025-53770 - Unauthenticated Remote Code Execution via unsafe deserialization in Microsoft SharePoint Server
Understanding the RCE On July 22, 2025, Immersive’s threat research team was trying to understand how the SharePoint zero-day vulnerability was uncovered, based on Eye Security’s initial article. There were many proofs of concept (PoCs) and initial articles on indicators of attack (IoAs) and their severity. But none covered the exploit itself or could help us understand how the exploit was weaponized in depth. In this blog, I’ll share our research process and how we (eventually!) got to the bottom of this exploit. The challenges of building a CTI lab Our initial thought process for building this Cyber Threat Intelligence (CTI) lab was fairly straightforward. We’d understand the indicators of compromise (IoCs) and the PoCs that were shared in the article, try replicating it with the PoC, and obtain some logs. However, it was easier said than done. What went wrong? The PoCs just didn't work, and there was no way for us to understand why. This makes sense retrospectively – initial articles only provided surface-level information, rather than details on how the exploit was made. We ended up deploying different variants of SharePoint to see which were vulnerable. Alas, nothing worked (I’ll explain why this happened in more depth later on). Looking at the logs to identify the problem didn’t work either, because who looks at logs, right? Some of the initial PoCs were taken down, and the ones remaining were missing a piece of the puzzle. It was also fairly noticeable that many of the PoCs added to GitHub weren’t true either, and some were ransomware binaries! Dissecting the payload – mistakes and a learning curve Based on the initial brief from the Eye Security article, we figured out that it was a deserialization problem. After many days of unravelling and building multiple SharePoint servers with different versions, the “Hallelujah” moment finally arrived. A new remote code execution (RCE) module for this exploit was committed to Metasploit's GitHub repo. It wasn't the code that mattered much to us, but the comments in it that got us interested: The highlighted comments helped us map out which deserialization gadget chain works against specific SharePoint Server versions. This was important, as the exploit itself abuses insecure deserialization in the ViewState on SharePoint pages like ToolPane.aspx. This is when it hit us: our initial exploit of the RCE using the TypeConfuseDelegate gadget with BinaryFormatter wasn't working because we weren’t targeting the versions that were vulnerable to that gadget chain. To put this to the test, we had the right version built (v16.0.10337.12109) and also decided to further analyze the payload itself from the Metasploit module – I know it's cutting corners, but I was very keen on how it all works together! To achieve this, we downloaded the earliest exploit module commit on its GitHub, added it to our existing Metasploit framework, and intercepted the request using BurpSuite. This gave us the PoC, which we could analyze: Obviously, there was no need to reinvent the wheel since Metasploit already had a functional module, but where’s the fun in that? Dissecting the payload – decoding It’s already noticeable that the payload is URL-encoded. By decoding it, you’ll be able to see the body of the request. It has references to controltemplates/ACLEditor and an Excel DataSet, which is commonly used in .NET deserialization exploits, along with a Base64 encoded and compressed data table: The next step was to extract and Base64 decode the compressed data table: The decoded and decompressed information is the raw XML schema and DiffGram that the DataSetWrapper spits out. The part highlighted in the red box is the embedded first-stage gadget, Base64 encoded as an XSD string. Remember when I mentioned that our PoCs weren't working earlier? It’s because we didn't embed our Base64 encoded payload onto a raw XML schema and DiffGram. If you take the Base64 encoded XSD string and decode it, you’d get the payload. The payload I had on Metasploit was: And by decoding the string obtained from above, we can see it too: Weaponizing our PoC to emulate the IoCs With all the juicy information to hand, it was time to recreate this and see how threat actors in the wild did it. Bear in mind that the IoCs from the research article mentioned they weren’t obtaining any shells from the RCE, but stealthily leaking cryptographic secrets from SharePoint servers, which were chained to craft a fully valid and signed payload using ysoserial. The PoC implemented based on the work from the Metasploit module wraps our initial “inner” ysoserial payload inside an XML and DataSet gadget that SharePoint expects, then serializes, compresses, and Base64 encodes it. The payload that was built closely resembles what’s seen in the wild, which was dropping malicious content to a file named spinstall0.aspx that leaks cryptographic secrets. This Base64 payload was then embedded into an XML and DataSet gadget, using our PoC: All that remained was to send the payload. Here’s what we noticed upon sending the request via Burp: And while looking at the Process Explorer running on our SharePoint test environment: Similar to the IoCs, you’ll note that w3wp.exe spawns cmd.exe, and a PowerShell process is then spawned from the cmd.exe child process. If it’s succeeded, you should be able to navigate to https://X.X.X.X/_layouts/15/spinstall0.aspx to view and read the SharePoint’s MachineKey config file, including the ValidationKey: Finally, from our ELK logs: As you’ll notice, the log shows that the exploit’s PowerShell payload used set-content to write an ASPX backdoor into SharePoint’s _layouts directory (spinstall0.aspx). In summary Looking back at this exploit, it’s interesting from an offensive perspective to see how advanced persistent threat actors are finding creative ways to compromise organization infrastructures. In the meantime, I can only send prayers to the SOC analysts and Sysadmins fixing SharePoint, because let’s be honest – SharePoint is a cave nobody comes out alive from! For more information and finer details on how the exploit works, I'll leave this fantastic article here: Viettel Cyber Security: SharePoint ToolShell – One Request PreAuth RCE Chain
