Read more of this story at Slashdot.

A double free vulnerability has been reported in the Windows Internet Key Exchange (IKEv2) service. The vulnerability is due to an error when processing fragments.

An unauthenticated, remote attacker could exploit this vulnerability by sending crafted packets to the target server. Successful exploitation could result in a crash of the IKEEXT service, or potentially arbitrary code execution.

The Vulnerability

Microsoft Windows is an operating system which includes both server and desktop components along with an easy-to-use GUI. All currently supported versions of Windows include Internet Key Exchange Protocol Extensions to support the Virtual Private Network (VPN) feature.

The VPN feature of Windows encrypts communication between hosts. ISAKMP is a negotiation protocol used by IPsec-enabled hosts to build a security association. It uses the Internet Key Exchange (IKE) Protocol in order to negotiate keys for encrypted communication. IKE has two versions: IKEv1 and IKEv2. IKE version 1 (IKEv1) and version 2 (IKEv2) messages have the following general format:

The type of payload is determined by the Next Payload header of the previous payload, or the Next Payload field in the header (in the case of the first payload).

IKEv2 supports message fragmentation as defined in RFC 7383. When IKEv2 messages exceed the path MTU, they may be split into multiple Encrypted Fragment payloads. Of interest to this report is the Encrypted Fragment (SKF) payload (type 0x35). The SKF payload format is defined as:

When an IKEv2 implementation receives fragments, it inserts each fragment into an ordered list and reassembles them once all fragments have been received. In the Windows implementation, the function IkeReinjectReassembledPacket() performs this reassembly.

A double-free vulnerability has been reported in the Windows IKE Extension library (ikeext.dll). The vulnerability is due to improper ownership handling of a heap-allocated blob pointer during IKEv2 fragment reassembly. During the IKE_SA_INIT exchange, a Security Realm Vendor ID payload causes IkeHandleSecurityRealmVendorId() to allocate a blob and store it in the MMSA (Main Mode Security Association) structure at offset 0x208. When a fragmented IKE_AUTH message is fully reassembled, IkeReinjectReassembledPacket copies MMSA fields at offsets 0x178 through 0x21F - including the blob pointer at 0x208 - into a local stack struct. This struct is then passed to IkeQueueRecvRequest, which shallow-copies it into a heap-allocated work item. While IkeQueueRecvRequest deep-copies the reassembly buffer at offset 0x10 in the struct, the Security Realm blob pointer at offset 0xC8 remains a shallow copy, aliasing the original at MMSA+0x208.

When the thread pool processes the queued work item, IkeDestroyPacketContext checks the blob pointer at offset 0xC8 and calls WfpMemFree to release it (first free). The MMSA structure still holds the original pointer to the same allocation at offset 0x208. When the MMSA is subsequently cleaned up through IkeCleanupMMNegotiation, the SA reference count is decremented via IkeDerefMMSA, eventually triggering IkeFreeMMSA, which frees the blob pointer at MMSA offset 0x208 - the same allocation already freed by IkeDestroyPacketContext (second free).

A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted IKE_SA_INIT message followed by two or more Encrypted Fragment (SKF) payloads containing an invalid IKE_AUTH message to the target server. The fragment reassembly path will shallow-copy the blob pointers, and the subsequent MMSA cleanup will trigger the double free. Successful exploitation could result in arbitrary code execution under the security context of the IKEEXT service (SYSTEM).

Source Code Walkthrough

The following code snippets were taken from IKEEXT.DLL file version 10.0.20348.2849 and decompiled with IDA Pro version 8.3. Comments added by TrendAI have been highlighted.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on UDP ports 500 and 4500. The IKE general format, Payloads field, and the Encrypted Fragment (SKF) payload format can be seen above.

The detection device should monitor all incoming IKE traffic. Detection requires correlating two packets within the same IKE session: an IKE_SA_INIT request carrying the Microsoft Security Realm Vendor ID, followed by a fragmented IKE_AUTH request. Neither packet alone is malicious; both must be observed in sequence from the same source.

IKE_SA_INIT

At byte offset 17 of the UDP payload, the device should check for the three-byte sequence 20 22 08, which corresponds to the IKEv2 version identifier (0x20), the IKE_SA_INIT exchange type (0x22), and the Initiator flag (0x08). The device should then scan the remainder of the packet for the 16-byte sequence 68 6a 8c bd fe 63 4b 40 51 46 fb 2b af 33 e9 e8, which is the Microsoft Security Realm Vendor ID. If both conditions are met, the device should follow the guidance below.

IKE_AUTH

For subsequent packets from the same source, the device should check bytes at offset 16 through 23 of the UDP payload. At offset 16, the four-byte sequence 35 20 23 08 identifies an Encrypted Fragment payload (SKF, type 0x35), IKEv2 version (0x20), IKE_AUTH exchange type (0x23), and Initiator flag (0x08). If found, the detection device should inspect offset 20 and search for the four-byte sequence00 00 00 01. If found the traffic should be considered malicious; an attack exploiting this vulnerability is likely underway.

Notes
• All multi-byte values should be treated as big endian.
• When detecting traffic on port 4500, IKE packets are prepended by a 4-byte non-ESP marker (\x00\x00\x00\x00), shifting all IKE header content offsets by 4.

Conclusion

This vulnerability was patched by Microsoft in the April 2026 release cycle. They do note two mitigations that could prevent exploitation while the patch is being tested and deployed. 

·      Block inbound traffic on UDP ports 500 and 4500 for systems that do not use IKE.

·      For systems that require IKE, configure firewall rules to allow inbound traffic on UDP ports 500 and 4500 only from known peer addresses.

These mitigations may be removed once the security patch is applied. The only way to fully remediate the vulnerability is to apply the update from the vendor.

Special thanks to Richard Chen and Lucas Miller of the TrendAI Research team for providing such a thorough analysis of this vulnerability. For an overview of TrendAI Research services please visit https://go.trendmicro.com/tis/vulnerabilities.html.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

Adobe Patches for May 2026

For May, Adobe released 10 bulletins addressing 52 unique CVEs in Adobe Commerce, After Effects, Adobe Connect, Illustrator, Media Encoder, Premiere Pro, Substance 3D Painter, Substance 3D Sampler, Content Authenticity SDK, and the Adobe Substance 3D Designer. Here’s this month’s overview table:

The obvious priority this month is the patch for Commerce, with its 15 bugs and deployment priority of 2. The Connect fix should also rank up there since both of its CVEs are CVSS 9s. Beyond those, it’s a pretty typical month for Adobe, with most of the bugs either being cross-site scripting (XSS) or open-and-own code executions.

Microsoft Patches for May 2026

This month, Microsoft released a whopping 138 new CVEs in Windows and Windows components, Office and Office Components, Microsoft Edge (Chromium-based), Azure, .NET and Visual Studio, Copilot Chat, Github Copilot, M365 Copilot, SQL Server, TCP/IP, and the Telnet Client – yes, the Telnet client. Two of these bugs were reported through the TrendAI ZDI program. 30 of these bugs are rated Critical, three are rated as Moderate, one is rated Low, and the rest are rated Important in severity.

This large volume of fixes follows the largest monthly release in Microsoft’s history and reflects the trend across the industry of a high number of submissions. While not all of these bugs were found by AI, it’s likely they had an AI-related component – even if it was just AI writing the submission. I should also point out the Pwn2Own Berlin occurs in just a few days, and it’s typical for vendors to patch as much as they can before the event.

None of the bugs patched by Microsoft this month are listed as publicly known or under active attack at the time of release, so we’ve got that going for us. Let’s take a closer look at some of the more interesting updates for this month, starting with a nasty-looking bug in DNS:

-    CVE-2026-41096 - Windows DNS Client Remote Code Execution Vulnerability
This patch fixes a heap-based buffer overflow in the DNS Client triggered by a malicious DNS response. No authentication or user interaction needed, and since the DNS Client runs on virtually every Windows machine, the attack surface is enormous. An attacker with a position to influence DNS responses (MitM, rogue server) could achieve unauthenticated RCE across your enterprise.

-    CVE-2026-41089 - Windows Netlogon Remote Code Execution Vulnerability
This update covers another CVSS 9.8 bug, which is a stack-based buffer overflow that lets an unauthenticated remote attacker execute code on a domain controller by sending a specially crafted network request — no credentials, no user interaction required. Yup – that makes it wormable. This is the highest-impact bug that requires immediate patching: a compromised domain controller is a compromised domain.

-    CVE-2026-42898 - Microsoft Dynamics 365 On-Premises Remote Code Execution Vulnerability
This bug rates a CVSS 9.9(!) and represents a code injection in Dynamics 365. It allows any authenticated user to execute code with a scope change, meaning exploitation can break out and affect resources beyond the vulnerable component itself. Scope changes are pretty rare, so if you’re running Dynamics 365 On-Prem, definitely test and deploy this patch quickly.

-    CVE-2026-40415 - Windows TCP/IP Remote Code Execution Vulnerability
This bug in the TCP/IP stack results from a use-after-free (UAF) and could allow a remote, unauthenticated threat actor to execute code without user interaction. That makes this another wormable bug. However, this one is much less likely to be exploited. The target needs to be under sustained low-memory (memory pressure) conditions, which is pretty rare. Still, no need to tempt fate here. Test and deploy this one quickly.

Here’s the full list of CVEs released by Microsoft for May 2026:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Looking at the other Critical-rated bugs in this month’s release, there are quite a few scary-looking bugs (including a CVSS 10!), but there’s no action for the end user as Microsoft has already mitigated these bugs and is just now documenting them. There’s also this month’s crop of Office bugs where the Preview Pane is an attack vector. However, the bug in Office for Android does not have the Preview Pane vector; it’s simple open and own. The bug in the WiFi driver needs a network adjacent attacker. The SharePoint bug requires authentication, but anyone with site privileges has the authentication needed. The bug in SSO Plugin for Jira & Confluence should really be called an authentication bypass, since it allows an unauthenticated attacker to gain access to a system.

Looking at the other code execution bugs, most are of the open and own variety as expected. The bug in Dynamic 365 (On Prem) requires high privileges. The Message Queueing bug requires an adjacent attacker. The bug in SQL Server requires authentication, but as usual, patching won’t be straightforward. Finally, there’s a bug in the kernel that leads to code execution. Most kernel bugs are privilege escalations, but this one could allow code execution if an attacker sends specially crafted NVMe over Fabrics (NVMe‑oF) response messages during the connection handshake process that contains an invalid header length value. Neat.

As usual, the vast majority of the Microsoft release fixes Elevation of Privilege (EoP) bugs. Also as usual, most simply lead to local attackers executing their code at SYSTEM-level privileges or administrative privileges, so there’s not much to add without further technical details about the bugs themselves. There are also a few bugs that just state the attacker could “gain ELEVATED privileges.” How obtuse. The bugs in Azure allow an attacker to access data otherwise hidden from them. The Edge bug allows threat actors to elevate to the privileges of the running application. The bug in Visual Studio allows attackers to get permissions associated with the MCP Server’s managed identity. Finally, there are a couple of sandbox escapes, too, which are always useful.

This month's update includes six Security Feature Bypass vulnerabilities. The most severe is in the Azure SDK for Java (CVSS 9.1). An attacker over the network can bypass the integrity protection provided by authentication tags on encrypted data, effectively manipulating encrypted input in a way that slips past integrity checks during decryption. Close behind is the bypass affecting the GitHub Copilot integration in Visual Studio Code (CWE-74). This one requires a user interaction, but it allows an attacker to circumvent the path validation safeguards that normally control which files Copilot is permitted to modify. The other Visual Studio Code bypass involves cross-site scripting, improper link resolution, and information exposure triggered when a user opens or views a maliciously crafted notebook. On the Windows networking side there are two bypasses. The first hits the Windows TCP/IP driver via an authentication bypass using an alternate channel. The other impacts the Windows Filtering Platform through improper access control, allowing a local, low-privileged attacker to bypass FQDN-based network security rules. Finally, there’s a Secure Boot bypass that, you guessed it, bypasses secure boot features.

Moving on to the Information Disclosure bugs fixed this month, we have 15 different CVEs. As usual, the majority of these simply result in info leaks consisting of unspecified memory contents or memory addresses. The bug in Power Automate could expose data marked “Sensitive” within Power Automate Desktop flows. One of the Word bugs could disclose NLTM hashes. The bug in Edge could disclose your cookies, which seems rude. The bug in Visual Studio could expose file path information. Finally, there’s a bug in Telnet for Windows 11 that leaks information being used by Telnet at the time. I didn’t even realize Windows 11 still had a telnet client.

The May release contains 10 spoofing bugs (plus the ones already addressed by Microsoft). The bug in Azure Machine Learning Notebooks vulnerability requires user interaction, but it could expose info through the Azure ML web interface to the attacker. There’s a cluster of fixes for Microsoft's mobile Office suite on Android. Excel, Word, and PowerPoint for Android all carry spoofing flaws rooted in improper access control. Two Copilot products are also affected by spoofing vulns. The M365 Copilot for Desktop has no details provided. The M365 Copilot for Android variant requires low privileges and producing only limited impact on confidentiality and integrity. Microsoft Teams for Android rounds out the mobile app spoofing bugs. Three Edge bugs close things out, all involving misrepresentation of information in the browser UI.

There are two Tampering bugs in this month’s release. The one in .NET Core allows threat actors to write files to an affected system. The other is in Outlook for iOS and manifests as a command injection bug.

There are eight DoS bugs in the May release, but as always, Microsoft provides little to no actionable information about the vulnerabilities. The most interesting from a practical standpoint are two TCP/IP bugs that allow a low-privilege Hyper-V guest to crash the host. Both are triggered from the adjacent network. On the broader network-exposure side, the ASP.NET Core bug is a straightforward infinite loop condition — an unauthenticated attacker sends a crafted request over the network and the server stops responding.

No new advisories are being released this month.

Looking Ahead

Assuming I survive Pwn2Own Berlin (which is looking iffy at the moment), I’ll return on June 9th on what will hopefully be a smaller release than this one. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

Adobe Patches for March 2026

For March, Adobe released eight bulletins addressing 80 unique CVEs in Adobe Acrobat Reader, Commerce, Illustrator, Substance 3D Painter, Premier Pro, Experience Manager, Substance 3D Stager, and the Adobe DNG Software Development Kit (SDK). Two of these bugs were submitted through the TrendAI ZDI program. If you need to prioritize, the update for Acrobat likely has the most impact, with the patch fixing two Critical-rated and one Important bugs. The fix for Experience Manager is the largest this month with 33 CVEs addressed. However, these are simple cross-site scripting (XSS) bugs, so it’s not too exciting. The fix for Commerce is also quite large with 19 CVEs. Most of these are also XSS bugs, but there’s a few security feature bypass bugs in there, too. Adobe actually gives this patch a deployment priority of 2, but it’s not under active attack at the time of release.

The fix for Illustrator corrects seven bugs, including a few Critical-rated ones. The patch for Substance 3D Painter fixes nine different CVEs, all rated Important. That’s not the case for Substance 3D Stager, which fixes six different Critical bugs that could lead to arbitrary code execution. The patch for the Adobe DNG Software Development Kit (SDK) addresses one Critical and one Important bug. Finally, the update for Premiere Pro correct a single, Critical-rated bug that could lead to arbitrary code execution.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release, and beyond the update for Commerce, all of the other updates released by Adobe this month are listed as deployment priority 3.

Microsoft Patches for March 2026

This month, Microsoft released 84 new CVEs in Windows and Windows components, Office and Office Components, Microsoft Edge (Chromium-based), Azure, SQL Server, Hyper-V Server, and the Windows Resilient File System (ReFS). Counting the third-party and Chromium updates listed in the release, it brings to total number of CVEs to 94. Five of these bugs were reported through the TrendAI ZDI program. Eight of these bugs are rated Critical, and the rest are rated Important in severity.

This volume is relatively typical for a March release, and the lack of bugs under active attack is a nice change from last month. There are two vulnerabilities listed as publicly known at the time of release, but none listed as actively exploited.

Let’s take a closer look at some of the more interesting updates for this month, starting with a bug with an AI slant:

-    CVE-2026-26144 - Microsoft Excel Information Disclosure Vulnerability
This is a fascinating bug and an attack scenario we’re likely to see more often. The vulnerability is a simple cross-site scripting (XSS) bug in Excel, but an attacker could use it to cause the Copilot Agent to exfiltrate data off the target. This essentially makes it a zero-click information disclosure. Although not stated, the disclosure is likely at the level of the logged-on user, so there isn’t a privilege escalation component. Info disclosures rarely get rated Critical, but it makes sense here.

-    CVE-2026-26110/CVE-2026-26113 - Microsoft Office Remote Code Execution Vulnerability
Another month and another pair of Office bugs where the Preview Pane is an exploit vector. I’ve lost count of how many of these bugs have been patched over the last year, but it’s just a matter of time until they start appearing in active exploits. The latest versions of Outlook allow you to hide the Preview Pane, but it isn’t clear if this would mitigate these attacks. The best option is still to test and deploy the update, but considering how many of these patches exist, it’s likely further updates will be needed to fully address these issues.

-    CVE-2026-23669 - Windows Print Spooler Remote Code Execution Vulnerability
Just reading the title makes me twitch with remembrances of Print Nightmare from a few years ago. This bug works in the same manner as those exploits. An authenticated attacker sends specially crafted messages to an affected system to gain arbitrary code execution. No user interaction is required. Let’s hope we don’t end up in a new nightmare of spooler exploits. Test and deploy this one quickly.

-    CVE-2026-23668 - Windows Graphics Component Elevation of Privilege Vulnerability
This vulnerability was submitted to the ZDI program by Marcin Wiązowski as two separate bugs, and it demonstrates the need for variant investigations when creating security patches. Both cases are caused by the lack of proper locking when performing operations on an object. However, in one case, it’s in the cdd.dll driver while the other is in the win32kfull driver. Either way, an attacker could use these to elevate privileges to SYSTEM and execute arbitrary code. Since the fix for both is to add object locking to the GDI object, the cases are combined into a single CVE. That’s not a problem, but it does show how variants can occur, and fixes should be as broad as possible.

Here’s the full list of CVEs released by Microsoft for March 2026:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Looking at the other Critical-rated bugs in this month’s release, they are all cloud-native and require no user action. Microsoft has already remediated the vulnerabilities.

Moving on to the other code execution bugs, the vulnerabilities in SharePoint Server pop out first. Both require authentication, but it’s essentially the lowest level of authentication, so these would be ideal cases for lateral movement within an enterprise. There are the standard open-and-own cases within Office components. There an interesting sounding bug in the Windows Mobile Broadband Driver that requires physical access, but Microsoft doesn’t elaborate on the attack scenario beyond that fact. The bug in the System Image Manager Assessment and Deployment Kit (ADK) requires authentication. The bug in GDI requires user interaction. The remaining code execution bugs are in the RRAS protocol. We’ve seen bugs in this component in the past, but never in the wild. I wouldn’t ignore these, but I wouldn’t rush them out either.

Similar to last month, updates for Elevation of Privilege (EoP) bugs make up nearly half of this month’s release. And as we saw last month, but most simply lead to local attackers executing their code at SYSTEM-level privileges or administrative privileges. The bugs in SQL Server allow attackers to elevate to SQL sysadmin privileges. The bug in the Azure MCP Server is more complex. It allows attackers to obtain the permissions associated with the MCP Server’s managed identity, which lets them perform actions that the managed identity is able to reach. The bug in the Azure AD SSH Login extension for Linux leads to root access, and it won’t be easy to patch. You’ll need to run the update instructions from the command line on each affected system. That’s the same case for the bug in the Linux Azure Diagnostic extension (LAD). There’s an odd bug in the Hybrid Worker Extension (Arc‑enabled Windows VMs) that leads to “ELEVATED” privileges, which is something I’ve never seen before. The bug in the Broadcast DVR component allows an attacker to go from low integrity level up to medium. There’s a bug listed as an EoP in the Push message Routing Service, but reading the description, Microsoft notes it could lead to an information disclosure. It’s likely this is an error and should be an Information Disclosure bug. The final EoP is in the Azure Portal Windows Admin Center and leads to SYSTEM. However, there’s no patch to remediate this bug. Instead, you need to install the latest version of the Windows Admin Center extension through the Azure Portal by hand.

There are two security feature bypass patches in the March release. The first is a bypass of the MapURLToZone method, which (as expected) allows attackers to bypass MapURLToZone protections. The third bypass is in Kerberos and could allow an attacker to either view some sensitive information or make changes to “disclosed” information. This is a race condition that occurs while the group policy is being reapplied, so the window to exploit this would be extremely small.

Looking at the remaining info disclosure bugs getting patched this month, only two result in info leaks consisting of unspecified memory contents or memory addresses. Ther others provide more interesting results. There are three bugs in the Azure IoT Explorer have some wide-ranging implications. According to Microsoft, exploitation could result in, “device connection information, authentication tokens, request data, file paths, and other information transmitted between the application and the IoT Hub.” The bug in Authenticator almost reads like a security feature bypass, as exploit results in the disclosure of a one‑time sign‑in code or authentication deep link. The attacker would receive the sign‑in information and could potentially use it to authenticate as the user, allowing access to information or services available to that account. The last info disclosure bug is in the Accessibility Infrastructure and allows an attacker to gain secrets or privileged information belonging to the user of the affected application.

There are only four spoofing bugs in the March release. The first is in SharePoint server and manifests as an XSS. The second bug is a Server-Side Request Forgery (SSRF) in the Azure IoT Explorer. The remaining two are a bit more cryptic. The bug in Windows Shell Link Processing results from the “exposure of sensitive information to an unauthorized actor,” and could lead to spoofing. That sounds like credential exposure, but it’s not explicitly called out. The final spoofing bug results from the insufficient verification of data authenticity in Windows App Installer. Again, this sounds vaguely like credential reflection, but without further information, we can only speculate.

Finally, there are four denial-of-service (DoS) bugs in the release, including one that’s listed as publicly known in the .NET Framework. As usual, Microsoft provides no actionable information about these bugs.

No new advisories are being released this month.

Looking Ahead

I plan on being at RSA for the first time in my career, so if you’re around, please stop by and say hello. I like it when people say hello. Otherwise, I’ll be back on April 14 with my assessment of that patch Tuesday release. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

Executive summary 

A group of Russian state-supported cyber actors has been targeting and compromising various Western government and commercial organizations using the Zimbra Collaboration Suite (ZCS) software since at least July 2025. The Russian state-supported advanced persistent threat (APT) group’s activity is tracked in the cybersecurity community under several names (see Cybersecurity industry tracking), primarily as “LAUNDRY BEAR,” a name initially coined by the Netherlands General Intelligence and Security Service (AIVD) and Defence Intelligence and Security Service (MIVD) [1].

LAUNDRY BEAR’s targeting is almost certainly to gather sensitive information for the Russian Federation, with these actors primarily focusing on the covert acquisition of email data. Previous campaigns indicated LAUNDRY BEAR relied on unsophisticated initial access techniques—including password spraying, phishing, and pass-the-cookie—allowing the group to successfully run high-volume operations. The latest campaign targeting ZCS uses a novel exploit that was a zero-day vulnerability when first exploited and continues to be successfully exploited. The vulnerability, Common Vulnerabilities and Exposures (CVE) CVE-2025-66376, was patched in November 2025. This demonstrates LAUNDRY BEAR’s intent and ability to deploy increasingly sophisticated technical capabilities.

Unlike traditional phishing campaigns that persuade a user into taking an action, such as clicking a link or opening a file, LAUNDRY BEAR’s latest campaign leverages a view-based exploit that only requires a user to view a malicious email within a vulnerable version of the webmail service. Once viewed, the exploit attempts to exfiltrate the victim’s last 90 days of email communications, the organization email directory (i.e., Global Address List [GAL]), and other sensitive information to servers controlled by LAUNDRY BEAR. The exploit also attempts to establish persistent access to victim accounts through a variety of means as detailed in the Persistence and credential access section.

This Cybersecurity Advisory (CSA) warns of this ongoing malicious threat activity and urges organizations to update their vulnerable software and implement additional mitigations to thwart these Russian state-supported actors’ continued success. The CSA is being released by the following authoring and co-sealing agencies:

• United States National Security Agency (NSA)
• United States Federal Bureau of Investigation (FBI)
• Netherlands Defence Intelligence and Security Service (MIVD)
• Netherlands General Intelligence and Security Service (AIVD)
• United States Cybersecurity and Infrastructure Security Agency (CISA)
• United States Defense Counterintelligence and Security Agency (DCSA)
• United States Department of Defense Cyber Crime Center (DC3)
• United States Department of the Treasury
• United States Naval Criminal Investigative Service (NCIS)
• Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
• Communications Security Establishment Canada’s (CSE’s) Canadian Centre for Cyber Security (Cyber Centre)
• New Zealand National Cyber Security Centre (NCSC-NZ)
• United Kingdom National Cyber Security Centre (NCSC-UK)
• Czech Republic National Cyber and Information Security Agency (NÚKIB)¹
• Danish Defence Intelligence Service (DDIS)²
• Estonian Foreign Intelligence Service (EFIS)³
• Finnish Defence Intelligence (FDI)⁴
• Finnish Security and Intelligence Service (SUPO)⁵
• French General Directorate for Internal Security (DGSI)⁶
• French National Cybersecurity Agency (ANSSI)⁷
• Italian External Intelligence and Security Agency (AISE)⁸
• Italian Internal Intelligence and Security Agency (AISI)⁹
• Security and Intelligence Service of the Republic of Moldova (SIS RM)¹⁰
• Polish Foreign Intelligence Agency (AW)¹¹
• The Military Counterintelligence Service of Poland (SKW)¹²
• Spain National Intelligence Centre (CNI)¹³
• Sweden National Cyber Security Centre (NCSC-SE)¹⁴

The authoring agencies urge any organizations using ZCS to implement the recommendations listed within the Mitigations section of this advisory to reduce the risk associated with this activity. This CSA also includes specific remediations for organizations to implement if they discover the presence of the listed Indicators of compromise (IOCs).  

As more organizations update their ZCS software based on this CSA, LAUNDRY BEAR may discontinue the current campaign exploiting this vulnerability; however, based on the success of this and previous campaigns, it is very likely that the group will continue to target ZCS and other email systems used by organizations in Western countries. The actors will almost certainly continue to rely on email to engage potential victims by exploiting novel vulnerabilities and, when necessary, use social engineering techniques to assist with their efforts. The authoring agencies recommend organizations regularly update their mail service software and continuously monitor their email systems and emails for malicious activity.

For a downloadable list of IOCs, see:

• AA26-204A.stix.xml (STIX XML)
• AA26-204A.stix.json (STIX JSON)

Cybersecurity industry tracking

The cybersecurity industry provides overlapping cyber threat intelligence, indicators of compromise (IOCs), and mitigation recommendations related to these Russian state-supported cyber actors. While not exhaustive, the following are threat group names commonly used for these actors within the cybersecurity community:

• LAUNDRY BEAR
• Void Blizzard [2]
• CL-STA-1114 [3]
• TA488 (formerly UNK_PitStop) [4]

Note: Cybersecurity companies have different methods of tracking and attributing cyber actors, and this may not be a 1:1 correlation to the U.S. government’s understanding for all activity related to these groupings.

Background

Public advisories from Netherlands General Intelligence and Security Service (AIVD), Netherlands Defence Intelligence and Security Service (MIVD), and Microsoft highlighted these Russian state-supported advanced persistent threat (APT) actors in May 2025, calling them LAUNDRY BEAR and Void Blizzard respectively [1] [2]. Both advisories assessed that the group was engaged in malicious cyber activity as early as April 2024.  

The May 2025 advisories highlighted a cluster of activity targeting cloud-based email environments, including Microsoft Exchange in particular, and abusing legitimate APIs to perform data exfiltration in bulk [T1114.002]. The group relied on unsophisticated means of initial access, including procuring stolen credentials on criminal marketplaces [T1078], and using social engineering techniques to lure targets into interacting with a malicious site masquerading as a legitimate one. As of April 2025, one of these sites resembled a European Defence & Security Summit registration portal that required registrants to sign in to their Microsoft account to view. Once a user entered their Microsoft credentials into this malicious site, LAUNDRY BEAR’s modified version of the open source adversary emulation toolkit, Evilginx, intercepted the user’s credentials. LAUNDRY BEAR then used this authentication data, including passwords and session tokens, to access the compromised account and conduct mass email exfiltration, as well as harvest other information. This method of compromise is commonly known as an adversary-in-the-middle (AiTM) technique [T1557].  

Beginning around July 2025, LAUNDRY BEAR shifted toward a more technical method of email compromise, highlighting their continued efforts to covertly acquire email communications from a variety of Western organizations of interest and deliver them to the Russian Federation. Using a custom-developed capability [T1587.001] named “Улей” or “Ulej” (Russian for beehive), LAUNDRY BEAR successfully targeted and exfiltrated sensitive user information from organizations who use the Zimbra Collaboration Suite (ZCS) product [T1114]. Data LAUNDRY BEAR attempted to exfiltrate from compromised accounts included:

• Last 90 days of emails,
• Email address,
• Password [T1589.001],
• Global Address List (GAL) [T1087],
• Two-factor authentication (2FA) tokens, and
• Newly-created Application Passcode [T1098].

The covert and persistent nature of this activity, along with the absence of any known financial extortion, almost certainly indicates this group’s involvement in espionage activities with Russian government backing. Additionally, extensive Ukrainian targeting, prior to use against U.S. and other NATO allies, outlines an increasing trend within Russian cyber threat groups to target Ukrainian users first—both as a priority target and as a testbench for malicious cyber techniques before broader global deployment.

Targeting details

LAUNDRY BEAR has targeted and compromised users in various organizations, including those associated with:

• the Defense Industrial Base (DIB),  
• the federal and local government,
• education,
• energy,
• law enforcement,  
• media,  
• non-governmental organizations, and
• technology.

Technical details

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise framework, version 19. This advisory also uses MITRE D3FEND^TM version 1.4.0¹⁵. See Appendix A and Appendix B for tables of the activity mapped to MITRE ATT&CK and D3FEND tactics, techniques, and countermeasures.

Ulej is a novel data exfiltration and aggregation capability, that currently (as of the publication of this report) supports a campaign specifically targeting users of ZCS webmail servers. This capability is used to exploit CVE-2025-66376 [Common Weakness Enumeration (CWE) CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')], but likely could be adapted to exploit other vulnerabilities. It exfiltrates emails and other sensitive user data from a victim’s system immediately after exploitation and stores the data in an actor-controlled unattributable virtual private server (VPS) [T1074.002] running LAUNDRY BEAR’s “Flowerbed” collection framework. The collected data is almost certainly further exfiltrated to internal network resources for review and long-term retention.

Reconnaissance

LAUNDRY BEAR uses the Ulej capability to exploit the CVE-2025-66376 vulnerability in organizations using ZCS. This campaign’s targeted victimology and limited exploitation capabilities likely indicate this group manually identifies and targets the victim organizations. LAUNDRY BEAR likely identifies organizations with public-facing Zimbra infrastructure by port scanning [T1595] and fingerprinting datasets easily procured through various commercial vendors [T1596.005].  

After identifying a target organization, the group likely compiles email addresses for individual users to target with the exploit [T1589.002] from datasets offered by commercial vendors [T1597.002], open source intelligence [T1593], or previously exfiltrated data [T1597].  

Resource development

The actors procure VPSs from a variety of providers [T1583.003], including those with Know Your Customer (KYC) requirements, and often use fabricated identities. LAUNDRY BEAR primarily uses Mullvad VPN [T1583] when interacting with these servers, further demonstrating the group’s intent to mask their identity and maintain operations security (OPSEC). After the server is provisioned, an automated process deploys the Docker containers necessary for Ulej’s Flowerbed framework [T1608], which then receives and aggregates the data Ulej exfiltrates. These servers are typically only used for 7-60 days before moving to new infrastructure.

Flowerbed framework

Flowerbed is a Python project that uses Docker for containerization. The project includes four different Docker containers:

• Catcher,
• Certbot,
• Nginx, and
• Gardener.

Catcher acts as both a DNS and HTTP server to receive and aggregate exfiltrated victim information [T1048]. For additional information on Catcher, refer to the Exfiltration section of this advisory. Flowerbed’s next container, Certbot, is based on one of the official Certbot containers, which allows for automated generation of Let’s Encrypt certificates using DNS challenges through Cloudflare. This certificate can then be used by the Nginx container, which serves as an HTTPS reverse proxy for Catcher, enabling Flowerbed to disguise some of its exfiltration activity through an encrypted communications channel [T1048.002]. The Nginx reverse proxy also validates that the Server Name Indicator (SNI) value contains “*.i.*” prior to forwarding the traffic to Catcher. If the SNI does not contain that string, the Nginx server returns a 444 error to the client. This is likely an attempt to reject non-Ulej connections. Finally, the Gardener container functions as a health check for the Catcher service. Gardener is a simple Python script that validates Catcher correctly receives and processes data.

The simplistic Flowerbed codebase has indications that artificial intelligence (AI) played a role in its development. This highlights how AI is increasingly being used to develop malicious capabilities [T1588.007]. The dependence on AI for a simple capability, such as Flowerbed, alongside a previous reliance on open source capabilities, such as Evilginx2 [T1588.002], likely indicates a lack of advanced technical knowledge within LAUNDRY BEAR, especially in relation to true software development capabilities.

Initial access

To gain initial access, LAUNDRY BEAR sends an email containing a malicious JavaScript payload to the target [T1566]. Through exploitation of CVE-2025-66376, this JavaScript payload is immediately executed once the user views the malicious email [T1203], such as the one shown in Figure 1, in the ZCS webmail platform. Since at least November 2025, LAUNDRY BEAR began sending these phishing emails from victim infrastructure through compromised accounts [T1199], as shown in the email metadata in Figure 2. These compromised accounts were likely previous victims of this, or another LAUNDRY BEAR, campaign and their use is intended to further obfuscate and frustrate anti-phishing tools and training.

According to the National Vulnerability Database (NVD), CVE-2025-66376 was initially published on 5 January 2026. This vulnerability allows for execution of a JavaScript payload included in email content due to improper sanitization of Cascading Style Sheet’s (CSS) @import directives within an email [5]. Because the activity attributed to this campaign began in July 2025—months before Synacor released a patch and the CVE was published—the payload initially exploited a zero-day vulnerability at that time [T1587.004].  

Utilization of a zero-day exploit within this campaign demonstrates the ability for even emerging threat groups like LAUNDRY BEAR to operationalize novel exploits into a highly successful capability.

Hidden in LAUNDRY BEAR’s email is a Base64 encoded payload within the “onload” field of a Scalable Vector Graphics (SVG) element [T1027.017], as shown in Figure 3. Leading up to the inclusion of this payload in the SVG element are various instances of @import directives, as required to leverage CVE-2025-66376. This payload includes an XOR encrypted final script encoded in a Base64 inner payload (see Figure 3) [T1027.013]. The outer payload decodes and decrypts the inner payload using an XOR function and a hardcoded key and then executes the script contained within the inner payload containing the collection and exfiltration logic. By changing the key used for the XOR encryption of the inner payload or adding additional @import directives with non-functional code [T1027.010], LAUNDRY BEAR can easily generate new payloads that bypass basic threat detection signatures. This malicious payload attempts to collect and exfiltrate information in 12 asynchronous stages [T1119]. The stages in order of appearance within the payload are as follows:

1. sendStartPing,
2. gather_email,
3. gather_environment,
4. gather_2fa_codes,
5. gather_app_password,
6. gather_device_status,
7. gather_oauth_consumers,
8. gather_autocomplete_password,
9. enable_mail_protocols,
10. gather_gal,
11. sendArchives, and
12. sendFinishPing. 

Use of a zero-day exploit within this campaign demonstrates the ability for even emerging threat groups like LAUNDRY BEAR to operationalize novel exploits into a highly successful capability [T1587].

Persistence and credential access

To establish sustained persistence into the victim’s email account, the script attempts to modify account preferences and collect authentication information. Any collected credentials are later exfiltrated, as further described in the Exfiltration section below. Other campaigns attributed to LAUNDRY BEAR also demonstrated the group’s ability to circumvent multi-factor authentication through session token replay [T1550.004], and the Zimbra campaign follows a similar trend.

The script used in this campaign tries to discover the victim’s email address during the gather_email stage [T1087]. The script searches for this email address in two ways. First, it examines the batchInfoResponse variable, which an HTML script element on the webpage can define, for an email address. Even if the script finds an email address there, it also checks whether it acquired a Cross-Site Request Forgery (CSRF) token as described later in the Collection section of this advisory. If so, the script uses the “GetIdentitiesRequest” Simple Object Access Protocol (SOAP) command under the “ZimbraAccount” namespace to determine the victim’s email address [T1185] and then exfiltrates it. However, if the script does not have a CSRF token or the SOAP request fails, the script exfiltrates the email value recovered from the first method instead. If both attempts fail to capture the victim’s email, the script sends a JavaScript Object Notation (JSON) payload with a key of “email” and value of null over HTTPS and does not attempt DNS exfiltration.

During the gather_autocomplete_password stage, the script attempts to collect the victim’s saved password via the autocomplete feature of the victim’s password manager. The script injects two HTML div elements requesting login credentials onto the page outside of the victim’s view, as shown in Figure 4 and Figure 5. After waiting five seconds, the script then attempts to extract the password provided automatically by the password manager from the input element shown in Figure 4. If there is no value in that input field, it checks the password input field shown in Figure 5. If neither input field contains a value, a JSON payload with a key of “autocomplete_password” and value of null is sent over HTTPS and DNS exfiltration is not attempted.

LAUNDRY BEAR almost certainly relies on a mail client using the Internet Message Access Protocol (IMAP) for persistent access to the victim’s mailbox. During the enable_mail_protocols stage, a SOAP request leveraging the “ModifyPrefsRequest” command under the “ZimbraAccount” namespace is sent. This request attempts to set the “zimbraPrefImapEnabled” preference to TRUE. While the default setting for “zimbraPrefImapEnabled” is not well documented, this action is almost certainly intended to ensure that IMAP access to the victim’s mailbox is enabled.

ZCS does not support 2FA for some mail clients, including IMAP. To support users who rely on IMAP clients, ZCS allows for the generation of Application Passcodes. Application Passcodes are randomly generated passwords that can be used for clients that cannot support the normal 2FA process to authenticate. During the gather_app_password stage, the script makes a SOAP request using the “CreateAppSpecificPasswordRequest” command under the “ZimbraAccount” namespace to create a new Application Passcode [T1556.006]. The SOAP request uses “ZimbraWeb” as the name of the application.

Additionally, the script also attempts to collect 2FA tokens. During the gather_2fa_codes stage, the script makes a SOAP request using the “GetScratchCodesRequest” command under the “ZimbraAccount” namespace. The script then attempts to exfiltrate any non-null 2FA codes collected this way. The number of codes can vary, and each code is exfiltrated to Flowerbed individually.

Collection

As demonstrated in the Persistence and credential access section, this script relies heavily on SOAP requests to collect victim information. To make these requests, the script aims to acquire the victim’s current CSRF token, which it attempts to access within the webpage’s local storage using localStorage.getItem("csrfToken"). If the script is unable to acquire this CSRF token, it will be unable to make any SOAP requests. In addition to the SOAP commands documented in the Persistence and credential access section, other SOAP commands executed to collect victim information are shown in Table 1.

The script attempts to collect the victim’s GAL through brute force by searching for each two-character combination from a character set of “abcdefghijklmnopqrstuvwxyz1234567890.-_”. These queries are conducted using 20 batches of SOAP requests with 77 “SearchGalRequest” SOAP commands in each batch except for the last request containing only 58.

During the gather_environment stage, the script attempts to determine which type of ZCS webmail client the victim is using. The script checks the user’s current URL to determine the client type being used, checking for certain indicators (shown in Table 2) to determine the client type. The corresponding value is then used as the payload when exfiltrating the client type.

As part of collection, the script attempts to harvest any emails not marked as “junk” from the last 90 days from the victim’s account. Emails are collected daily by an HTTP GET request to the URL path, “/home/~/?fmt=tgz&meta=0&query=date:-{DAY_OFFSET}d AND (not in:junk)”. The {DAY_OFFSET} value would be between 0 and 89 representing how many days ago the email was sent or received. To prevent redundant collection and exfiltration of emails, a variable with a name based on the email date being queried, using a format of zd_comp_YYYY-MM-DD, and value of true, is saved to the window.top.localStorage property. This variable is saved regardless of whether the email is successfully exfiltrated.  

According to Mozilla documentation, if the user is not in a private browsing session, any data stored to localStorage does not typically expire. This means that if the user happens to execute the script again from the same computer, the script avoids attempting to re-exfiltrate previously captured emails. However, the script always attempts to pull any emails with a {DAY_OFFSET} of zero. In other words, the script always pulls emails sent or received the same day it is run. After email results are returned from the query for each day of email activity, those results are then passed to Flowerbed as described in the Exfiltration section.

The script also provides LAUNDRY BEAR with telemetry on any errors that occur during the collection process. This is accomplished by executing any collection or exfiltration code through helper functions that contain error handling logic. If an error occurs, a payload containing information on the error itself, the context of the error happening, and the stage in which the error occurred is sent to Flowerbed as described in the Exfiltration section below. For cases where the error occurs within a SOAP request, “:api” is concatenated to the stage value in the payload. If an error occurs during the batch SOAP requests that occur when collecting the GAL of the victim, the stage value will use a format of gather_gal:{VAL}:api. The {VAL} placeholder indicates which batch request, a number from 0 to 19, the error occurred in. Errors that occur during the password autocomplete interception process will use “gather_autocomplete_password:dom” for the stage value. Finally, if an error occurs when attempting to collect or exfiltrate a specific day’s emails, the stage will include which day the error occurred on, using the previously defined placeholder {DAY_OFFSET}, with a format of sendArchive:day-{DAY_OFFSET}.

Exfiltration

At the end of each stage in the collection process, the script attempts to exfiltrate acquired information to Flowerbed. The script primarily relies on two forms of data exfiltration: DNS [T1048.003] and HTTPS. Some information is exfiltrated over both the DNS and HTTPS channels.

Prior to exfiltration, a randomized 10- or 11-character alphanumeric string is generated as an identifier for the victim. This identifier is included in the URL of both the DNS- and HTTPS-based exfiltration.  

DNS exfiltration

DNS exfiltration occurs through DNS A record queries. To ensure data exfiltrated through DNS is not corrupted when traversing through non-actor-controlled DNS infrastructure, Ulej maintains compliance with RFC 1035, Domain Names - Implementation and Specification, specifically accounting for the case insensitivity and subdomain length requirements. Base32 encoding is used to create a case-insensitive payload. Once the payload is encoded, a period (“.”) is added every 60 characters to ensure each subdomain is under 63 characters long. The script then creates a new image object sourced from a URL with the scheme defined in Figure 6. Any traffic involving DNS exfiltration will have “d-“ prefixing the victim identifier, and the subdomain immediately following indicates the type of information being exfiltrated.

When the script generates an image object, the browser tries to retrieve the complete domain of the URL specified as the source of the image. This triggers a DNS request sent to the actor-controlled server and processed by Flowerbed. Table 3 lists both the information exfiltrated via DNS and their corresponding data type identifiers in the DNS queries.  

HTTPS exfiltration

Any information exfiltrated via DNS is also exfiltrated through HTTPS, as well as additional data including email content, contacts, attachments, and error logging information. By using Let’s Encrypt certificates, this group can quickly deploy new infrastructure and leverage encrypted HTTPS communications with valid server certificates when exfiltrating information from the victim’s environment. The HTTPS exfiltration capability only uses two HTTP content types, defined in Table 4. Traffic associated with HTTPS exfiltration will use the URL scheme shown in Figure 7.  

Some of the data transmitted via HTTPS uses the standard JSON content type format. The script includes the information in a POST request to actor-controlled infrastructure.  

Table 5 provides a summary of the JSON-based exfiltration.

The script transmits all HTTPS exfiltration not identified in Table 5 using the Octet-Stream content type as binary data. The POST requests for this method include a filename in the “X-Filename” header. Traditionally, developers use headers prefixed with “X-” to denote custom headers that do not follow a defined standard. The purpose of including this header remains unclear since the Catcher capability ignores the provided filename when saving the data. Table 6 summarizes the data exfiltrated in this format.

The script sends all exfiltrated data identified in Table 6 to the Catcher service exactly as received from the SOAP request in a JSON payload, except for email exfiltration. For email exfiltration, the script sends it as a GZIP compressed archive [T1560]. Although most of the exfiltration consists of valid JSON, the script still attempts to exfiltrate all information identified in Table 6 using the application/octet-stream content typing rather than application/json.

At the beginning and end of the collection and exfiltration activity, during the sendStartPing and sendFinishPing stages respectively, the script submits a POST request with a JSON payload to indicate that the script is starting or finishing execution. Throughout execution, the script also logs error events and send the logs using similar JSON payloads. The script sends the JSON in a POST request to the URL documented in Figure 2, using a URL path of “/v/p” and with a “subtype” key that shows which type of action it logged (start, finish, or error).  

Catcher

Ulej exfiltrates information to Flowerbed to be handled by a service named Catcher. Catcher is a containerized Python application, running in Docker as part of Flowerbed, which is detailed in the Resource development section. It receives exfiltrated data and temporarily stores it, enabling its eventual transfer to infrastructure designed for long-term, secure storage.

Catcher acts as an HTTP server over port 8000 and a DNS server on port 53. As described in the Resource development section, the Flowerbed project uses an additional Docker container running an Nginx reverse proxy to enable HTTPS support. This reverse proxy uses a certificate generated by Let’s Encrypt and forwards all traffic with an SNI containing “*.i.*” to port 8000 within the Catcher container.

The DNS service can accept A, AAAA, MX, TXT, and CAA queries. For any MX, AAAA, or CAA queries, the server will always provide an empty response. The system only supports TXT records as needed to process Automatic Certificate Management Environment (ACME) requests, which enable the assignment of Let’s Encrypt certificates. If the server receives an A query, Catcher will always respond with the public IP address of the Flowerbed server.  

However, if a query includes a domain formatted as shown in Figure 6 and Figure 7, the service saves a log file in JSON format to disk containing the following details of the DNS query:

• Time of query,
• Source IP address for query,
• Queried domain, and
• Type of query.

The HTTP server typically responds with OK, except in cases where the path is “pixel.gif” when the response contains a 1x1 gif image with a SHA-256 hash of ef1955ae757c8b966c83248350331bd3a30f658ced11f387f8ebf05ab3368629. Like the DNS service, the HTTP service will only log entries when the domain found in the host header of the request follows the expected formatting as seen in Figure 6 and Figure 7. As the HTTPS exfiltration uses non-standardized binary and JSON-formatted payloads when exfiltrating to Catcher, Catcher will check the content type of the request. If the content type is set to “application/json”, Catcher encodes the data in Base64 and includes it in the JSON log entry written to disk. If the content type is set to any other value, Catcher leaves the Base64 payload in the JSON log entry blank and saves the payload to a separate file with the same filename as the JSON log entry with a “.bin” file extension. An HTTPS exfiltration event causes Catcher to save a JSON formatted log file to disk containing the following information from the HTTP request:

• Time,
• Source IP address,
• Request method,
• Host,
• Path,
• Query string,
• Headers, and
• Base64 payload.

These JSON event log files and binary output files are then initially saved to the directory /root/hits/tmp and later moved to the /root/hits/ready directory once processed. This prevents incomplete files, which are still being uploaded to Catcher, from premature exfiltration from the server. Approximately every 60 seconds, a likely automated workflow establishes a Secure Shell (SSH) connection with the server hosting Flowerbed for a few seconds, almost certainly exfiltrating the data processed by Catcher to non-public-facing infrastructure. The command in Figure 8 also executes hourly to remove all files last modified at least two days ago from the /root/hits/ready directory.

Response strategies

Mitigations

In many cases, by the time an organization identifies a compromise related to this campaign, numerous sensitive and proprietary emails have already been exfiltrated. The significant risk posed by this cyber threat emphasizes the importance for organizations that use ZCS and other similar webmail solutions to take proactive steps to mitigate this risk.

All organizations that use the ZCS webmail service should immediately prioritize ensuring that their ZCS is not running a vulnerable version. A patch for CVE-2025-66376 was released for both 10.1.13 and 10.0.18 versions of ZCS [D3-AH]. If immediate patching is not feasible, organizations should advise employees to use alternative mail clients to access email and avoid using the Classic ZCS webmail client until ZCS is updated to a non-vulnerable version [d3f:Isolate].

System administrators should closely monitor any Internet-connected ZCS or other email systems and the workstations that access those systems and promptly apply available software updates [D3-AH]. Administrators can maintain awareness of active vulnerability exploitation by referencing open source resources, including CISA’s Known Exploited Vulnerabilities Catalog and NCSC-UK’s Responding to active exploitation of vulnerabilities guidance.

Organizations should consider using a third-party authentication service that supports passkeys for authentication to mediate access to ZCS and other services that do not natively support passkeys. By doing so, organizations can work to eliminate the possibility of automated password collection from autocomplete or password reuse [D3-CH]. However, Application Passcodes may still be necessary and should be monitored closely.  

Organizations should implement network monitoring capabilities with collection and short-term retention of packet capture or NetFlow data and maintain log collection and storage [CPG 3.Q]. This will allow organizations to monitor for and identify suspicious network activity [CPG 4.B], such as:

• Significant amounts of outbound data being sent to IPs associated with VPS providers not used by the organization [D3-NTA];
• Frequent DNS queries for a suspicious domain with seemingly random subdomains [D3-DNSTA];
• A sudden spike of connections to a server associated with a recently established domain [D3-NTCD]; and  
• Connections to internal services, such as webmail, from VPN providers frequently leveraged by this group for nefarious activity, such as Mullvad VPN [D3-NTCD].

Additionally, for organizations that can inspect the content of outbound HTTPS connections via break-and-inspect infrastructure, security teams should identify traffic matching the characteristics described in the Exfiltration section of this advisory.

Indicators of compromise (IOCs)

Flowerbed infrastructure

The following indicators have been attributed to use by LAUNDRY BEAR for their campaign targeting ZCS’s webmail service as of the publication of this advisory. (Disclaimer: Due to the frequency of operational structure changes by this group, these indicators are intended solely for historic attribution purposes. Some indicators, such as IPs, compromised emails, and domains, may be outdated, so organizations should check for current activity before acting on these IOCs.) Table 7 provides details about the server infrastructure used to host Flowerbed, and Table 8 lists the corresponding SHA-1 hash values for the Let’s Encrypt certificates used by that infrastructure [D3-IAA].

LAUNDRY BEAR has used the following email addresses to procure resources used for this campaign:

• ivanka.zurabishvili@proton[.]me,
• zmul1@buildandconsulting[.]com,
• garrysmithme@pinmx[.]net, and
• hostingclient@pinmx[.]net.

Phishing distribution

LAUNDRY BEAR primarily relied on ProtonMail for distribution of malicious email. However, as stated above, LAUNDRY BEAR’s more recent efforts likely have shifted to distributing the payload through previous victims.  

The following email addresses have distributed payloads attributed to this campaign:

• c.laurent.ejfa@proton[.]me,
• j.moreau.epsc@proton[.]me,
• liberty.insights@proton[.]me,
• certain email addresses (presumably compromised) at the isofts.kiev[.]ua domain (i.e., ending with @isofts.kiev[.]ua), and
• certain email addresses (presumably compromised) at the navs.edu[.]ua domain (i.e., ending with @navs.edu[.]ua).

Additionally, the following are SHA-256 hashes of email samples containing the malicious payload attributed to this campaign:

• 98df604ecc57f884a2e6ce3266a0013ad64455cac48442c2312cfa4765007aaf,
• 60db9abae75cd8ccc49dd7ea5feb41677566dcd442f12ebc5745ffd2810fb874,
• b1f5beb1175fc5c7d1806a2f0d900eb124c54f0286c5c52b66eea7a6633adb1d, and
• 1517b3caa495f6c4e832df9c75fc94667e3c233773f7fa4e056d5e30e5ead760.

Post-compromise artifacts

Currently, the script does not remove artifacts. This leaves additional opportunities to identify victims of this activity. While emphasis should always be placed on consistent monitoring of network traffic and endpoint activity, there are a variety of persistent artifacts described below that can be used to identify victims of this campaign.

This Ulej capability relies on creating a significant number of SOAP requests to collect account information for exfiltration. ZCS logs from these requests are stored, by default, in the /opt/zimbra/log/mailbox.log file [D3-PA]. A significant amount of SOAP request activity that aligns with what was described in the Persistence and credential access and Collection sections of this advisory could indicate a potential compromise. Specific examples of high-risk SOAP request activity might include:

• Many SearchGalRequest command requests from a single user over a short period of time;
• Use of the CreateAppSpecificPasswordRequest command, especially in cases where it is creating an Application Passcode named “ZimbraWeb”; and
• Use of the GetScratchCodesRequest command.

While LAUNDRY BEAR uses the localStorage property to track what days had emails previously exfiltrated, defenders can use this property to identify victims of this campaign and determine the scope of exfiltrated information [D3-PA]. Review of the items stored in that property for an organization’s ZCS webmail client page on an endpoint device could indicate compromise if there are items named with a format of zd_comp_YYYY-MM-DD, as explained in the Collection section of this advisory.

While Application Passcodes have non-malicious purposes, in this case instances of these passcodes with the name “ZimbraWeb” are almost certainly malicious. The ZCS webmail application can support 2FA natively and does not require the use of an Application Passcode, so there is no reason that there should be one named “ZimbraWeb.”

In instances where organizations identify victims of this campaign, they should also examine the inbox of the suspected victim for the original phishing email [D3-MA]. If an email that has a payload exploiting CVE-2025-66376 is discovered, steps should be taken immediately to identify and quarantine other instances of emails with similar body content, senders, and subject lines to prevent further exploitation and exfiltration.  

Remediation

In the event an organization identifies activity associated with this campaign, that organization should take steps to minimize further exploitation. The organization should consider requesting that employees minimize use of the ZCS webmail client until the organization updates to a patched version that is not vulnerable to CVE-2025-66376.

Organizations should use identifiers from the IOCs section of this report to identify any individuals compromised by this campaign and record the date(s) of compromise(s) to determine the scale and scope of emails exfiltrated.

All users from the organization should have all Application Passcodes and 2FA scratch keys revoked. Affected organizations should require all employees to change passwords in line with establishing minimum password strength requirements [CPG 3.B] and creating unique credentials [CPG 3.C], specifically noting that compromised employees might have had any password stored in a password manager exfiltrated.

Works cited

[1] Netherlands General Intelligence and Security Service (AIVD) and Netherlands Defence Intelligence and Security Service (MIVD). AIVD and MIVD identify a new Russian cyber threat actor. 2025. https://www.aivd.nl/site/binaries/site-content/collections/documents/2025/05/27/aivd-en-mivd-onderkennen-nieuwe-russische-cyberactor/Advisory+AIVD+en+MIVD+Public+report+on+new+cyber+actor.pdf

[2] Microsoft Corporation. New Russia-affiliated actor Void Blizzard targets critical sectors for espionage. 2025. https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/

[3] Palo Alto Networks Unit 42. Russian Global Webmail Espionage. 2026. https://unit42.paloaltonetworks.com/russian-webmail-espionage/ 

[4] Proofpoint. TA488 Targets Zimbra Mailservers with Half-Click Exploits. 2026. https://www.proofpoint.com/us/blog/threat-insight/ta488-zcs-exploit

[5] Seqrite. Operation GhostMail: Russian APT exploits Zimbra Webmail to Target Ukraine State Agency. 2026. https://www.seqrite.com/blog/operation-ghostmail-zimbra-xss-russian-apt-ukraine/  

Footnotes

¹ Národní úřad pro kybernetickou a informační bezpečnost
² Forsvarets Efterretningstjeneste
³ Välisluureamet
⁴ Sotilastiedustelu
⁵  Suojelupoliisi
⁶ Direction générale de la sécurité intérieure
⁷ Agence nationale de la sécurité des systèmes d’information
⁸ Agenzia Informazioni e Sicurezza Esterna
⁹ Agenzia Informazioni e Sicurezza Interna
¹⁰ Serviciul de Informații și Securitate al Republicii Moldova
¹¹ Agencja Wywiadu
¹² Służba Kontrwywiadu Wojskowego
¹³ Centro Nacional de Inteligencia
¹⁴ Nationellt Cybersäkerhetscenter
¹⁵ MITRE and ATT&CK are registered trademarks of The MITRE Corporation. MITRE D3FEND is a trademark of The MITRE Corporation.

Acknowledgements

The authoring agencies acknowledge the contributions to this advisory from Palo Alto Networks Unit 42 and Proofpoint.

Disclaimer of endorsement

The information and opinions contained in this document are provided "as is" and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Organizations have no obligation to respond or provide information back to the authoring organizations in response to this joint advisory. If, after reviewing the information provided, an organization decides to provide information to the authoring organizations, reporting must be consistent with all applicable laws and policies.

Purpose

This document was developed in furtherance of the authoring agencies’ cybersecurity missions, including their responsibilities to identify and disseminate threats, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.

Contact

Appendix A: MITRE ATT&CK tactics and techniques

See Table 9 through Table 19 for all the threat actor tactics and techniques referenced in this advisory.

Appendix B: MITRE D3FEND countermeasures

See Table 20 for a mapping of several of the cybersecurity countermeasures mentioned in this advisory.

While app performance is often equated with a smooth UI and fast start times, memory serves as the silent foundation upon which these visible metrics are built. It's no secret that we're seeing a shift where device memory is more important than ever. Not only have we made strides in Android memory optimizations with Android 17, we're providing the tooling and API support to help you stay ahead of stricter memory requirements later this year.

To ensure device stability, starting in Android 17, the system will begin enforcing app memory limits based on the device's total RAM. If an app exceeds those limits, Android will kill the process with no associated stack trace.

Optimize image loading

Detect and fix memory leaks with Android Studio

Memory leaks in Android occur when your code holds onto an object's reference long after its lifecycle has ended. This prevents the Garbage Collector (GC) from reclaiming that memory, eventually leading to sluggish performance or OutOfMemoryError (OOM).

Android Studio Panda 3 features a dedicated LeakCanary profiler task, allowing developers to analyze real-time memory leaks and map traces within the IDE.

The LeakCanary profiler task in Android Studio actively moves the memory leak analysis from your device to your development machine, resulting in a significant performance boost during the leak analysis phase as compared to on-device leak analysis.

Additionally, the leak analysis is now contextualized within the IDE and fully integrated with your source code, providing features like go to declaration and other helpful code connections that drastically reduce the friction and time required to investigate and fix memory leaks.

Trim memory when app leaves visible state

Android can reclaim memory from your app or stop your app entirely if necessary to free up memory for critical tasks, as explained in Overview of memory management. Android will usually reclaim memory from your app when it’s not visible to the user, such as by discarding some of your app’s code and data pages in memory or compressing your heap allocations. When the user resumes your app and your app tries to access some memory that’s been reclaimed, the OS will swap that memory back in on demand. This swapping behavior can be slow, and cause unexpected jank or stutters in your app.

If you leave it to the OS to decide what memory to reclaim from your app, you may find that the OS reclaimed memory that you’ll need shortly after resuming your app. Instead, your app can voluntarily discard memory allocations that it can regenerate later, on demand and at a low cost. To do so, you can implement the ComponentCallbacks2 interface. You can implement onTrimMemory in your Activity, Fragment, Service, or even your custom Application class. Using it in the Application class is highly effective for global cache management.

The provided onTrimMemory() callback method notifies your app of lifecycle or memory-related events that present a good opportunity for your app to voluntarily reduce its memory usage.

In terms of memory lifecycle management, your implementation should focus exclusively on TRIM_MEMORY_UI_HIDDEN and TRIM_MEMORY_BACKGROUND. Since Android 14, the system has ceased delivering notifications for other legacy constants, which were formally deprecated in Android 15.

TRIM_MEMORY_UI_HIDDEN: This signal indicates that your application's UI has transitioned out of the user's view. This provides an opportunity to release substantial memory allocations tied strictly to the interface—such as Bitmaps, video playback buffers, or complex animation resources.

TRIM_MEMORY_BACKGROUND: At this level, your process is residing in the background and is now a candidate for termination to satisfy the system's global memory needs. To extend the duration your process remains in the cached state, and reduce the number of app cold starts, you should aggressively release any resources that can be easily reconstructed once the user resumes their session.

import android.content.ComponentCallbacks2
// Other import statements.

class MainActivity : AppCompatActivity(), ComponentCallbacks2 {

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    override fun onTrimMemory(level: Int) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

Note: The onTrimMemory integration may depend on SDK support. For instance, certain games rely on their game engine to enable this capability. Please check out the game memory optimization documents.

Advanced memory observability with ProfilingManager

To catch and diagnose memory issues in the field that cannot be reproduced locally, you should leverage the ProfilingManager API. Introduced in Android 15, this advanced observability API allows you to programmatically collect real-user Perfetto profiles.

For teams that lack a dedicated infrastructure to manage and host performance artifacts, Crashlytics is exploring a specialized solution to streamline this workflow. They are inviting developers to provide feedback.

Android 17 introduces new event-driven triggers, most notably TRIGGER_TYPE_OOM and TRIGGER_TYPE_ANOMALY:

• The OOM trigger automatically collects a Java heap dump at the exact moment an OutOfMemoryError crash occurs, providing precise allocation states. A collected OOM profile is provided the next time the app starts and registers the registerForAllProfilingResults callback.
• The Anomaly trigger detects severe performance issues, such as excessive binder spam or breached memory thresholds. The memory anomaly delivers a heap dump just prior to the system terminating the app.

  val profilingManager = 
applicationContext.getSystemService(ProfilingManager::class.java)
    val triggers = ArrayList()  


    triggers.add(ProfilingTrigger.Builder(
                 ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
    val mainExecutor: Executor = Executors.newSingleThreadExecutor()
    val resultCallback = Consumer { profilingResult ->
        if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
            // upload profile result to server for further analysis          
            setupProfileUploadWorker(profilingResult.resultFilePath)
        } 

    profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback)
    profilingManager.addProfilingTriggers(triggers)

Once you’ve collected the heap dump, you can download the profile from the server, or locally via adb pull and drag and drop the file into the Perfetto UI. To streamline your memory debugging workflow, use the Heap Dump Explorer, this is the new default view for heap dumps in Perfetto UI. This tool provides an intuitive interface for inspecting Java heap dumps, allowing you to visualize object allocation hierarchies, compute retained memory sizes, and identify the shortest path from garbage collection root. By leveraging the Heap Dump Explorer, you can rapidly pinpoint memory leaks, bloated retained objects such as excessive bitmap allocations, and analyze heap object allocations all in one place.

Conclusion

Optimizing bytecode with R8, adopting image loading best practices, and resolving memory leaks are critical steps toward delivering a high-quality user experience while managing resources effectively under pressure. Adopting these proactive measures helps maintain app stability and performance, preventing unexpected terminations while safeguarding user context. To further your performance expertise, explore our revised memory guidance.

To meet Android developer verification and updated Play Console Requirements, Play developers must register their Play apps in Play Console. While 99% of apps on Play have been registered automatically, you should check your Play Console Home page to register any remaining apps by September 30, 2026 to avoid global removal from Google Play and ensure a seamless user installation experience.

You can also use Play Console to register apps you distribute outside of Google Play to ensure they can be installed on certified Android devices.

Last year, we introduced Android developer verification to strengthen ecosystem security and stop malicious actors from hiding behind anonymity to release harmful apps. Millions of apps have been registered since the verification launched in March, covering nearly all installs on Google Play and a large majority of installs from outside of Google Play. We appreciate the feedback and partnership from industry leaders, developers, and Android communities that helped us design this experience and drive strong adoption.

Initial launch across seven stores and four countries

These new developer verification protections will take effect on September 30, 2026, starting with users in Brazil, Indonesia, Singapore, and Thailand.

This rollout is an industry-wide effort to create a safer ecosystem. We will begin by verifying app installations from the following stores:

• Google (Google Play)
• Honor (HONOR App Market)
• OPlus (OPPO App Market)
• Samsung (Galaxy Store)
• Transsion (Palm Store)
• vivo (V-Appstore)
• Xiaomi (GetApps)

Following this initial phase with our partners, we will expand these protections globally for all apps on certified Android devices in 2027.

Automate your workflow with new APIs

To further streamline app registration, we are launching a suite of developer-requested APIs to help you register apps in bulk or directly through your continuous integration and deployment (CI/CD) pipelines. The Android Developer ID Status API will let you check if a package name has already been registered, and the Android Developer Console API will let you register and manage package names directly within your development environment. Both APIs also support OAuth delegation, allowing third-party platforms, like Android app stores, to perform these operations natively on your behalf.

We'll launch these APIs over the next few months.

What’s next

• June 2026: Starting this month, we are rolling out a new system service that will be automatically installed on most Android devices. This service will be used later this year to verify developer registration.
• July 2026: We’ll launch the Android Developer ID Status API globally and begin early access for the Android Developer Console API. Early access also starts for limited distribution accounts on Android Developer Console. This new type of Android developer account is designed for students, hobbyists, and learners and lets you share your apps to up to 20 devices without a government-issued ID or a fee.
• August 2026: Limited distribution accounts and the new Android Developer Console API will launch globally. We’ll also launch an advanced flow for installing apps from unverified developers, which includes security checkpoints to resist coercion scams, while allowing power users to maintain the ability to sideload apps from unverified developers.
• September 30, 2026: App registration becomes required for participating stores in Brazil, Indonesia, Singapore, and Thailand. Unregistered apps can be sideloaded with Android Debug Bridge (adb) or advanced flow.
• 2027 and beyond: After incorporating the feedback from our partners, users, and developer community, we’ll expand the Android verification requirement globally.
  

Get started with Android developer verification

If you distribute apps in Brazil, Indonesia, Singapore, or Thailand via the stores listed above, please ensure your verification is complete by the September deadline.

• Google Play developers: Most Play developers are already verified, and over 99% of their apps have been registered. Go to your Play Console Home page to see your app’s verification status, and register apps you want to continue distributing that weren't automatically registered.
• Developers who distribute only outside of Google Play: Sign up for the Android Developer Console today to register your apps.

• Students and hobbyists: Sign up here for early access to limited distribution accounts to help us refine the feature with your feedback.

Thank you for helping us build a safer Android ecosystem. Stay tuned for more updates as we approach September and the 2027 global rollout.

Read more of this story at Slashdot.

Read more of this story at Slashdot.

The Cybersecurity and Infrastructure Security Agency (CISA) is releasing this advisory in response to ransomware actors leveraging unpatched instances of a vulnerability in SimpleHelp Remote Monitoring and Management (RMM) to compromise customers of a utility billing software provider. This incident reflects a broader pattern of ransomware actors targeting organizations through unpatched versions of SimpleHelp RMM since January 2025.

SimpleHelp versions 5.5.7 and earlier contain several vulnerabilities, including CVE-2024-57727—a path traversal vulnerability.¹ Ransomware actors likely leveraged CVE-2024-57727 to access downstream customers’ unpatched SimpleHelp RMM for disruption of services in double extortion compromises.¹ 

CISA added CVE-2024-57727 to its Known Exploited Vulnerabilities (KEV) Catalog on Feb. 13, 2025.

CISA urges software vendors, downstream customers, and end users to immediately implement the Mitigations listed in this advisory based on confirmed compromise or risk of compromise.

Download the PDF version of this report:

Mitigations

CISA recommends organizations implement the mitigations below to respond to emerging ransomware activity exploiting SimpleHelp software. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections. These mitigations apply to all critical infrastructure organizations.

Vulnerable Third-Party Vendors

If SimpleHelp is embedded or bundled in vendor-owned software or if a third-party service provider leverages SimpleHelp on a downstream customer’s network, then identify the SimpleHelp server version at the top of the file <file_path>/SimpleHelp/configuration/serverconfig.xml. If version 5.5.7 or prior is found or has been used since January 2025, third-party vendors should:

1. Isolate the SimpleHelp server instance from the internet or stop the server process.
2. Upgrade immediately to the latest SimpleHelp version in accordance with SimpleHelp’s security vulnerability advisory.²
3. Contact your downstream customers to direct them to take actions to secure their endpoints and undertake threat hunting actions on their network.

Vulnerable Downstream Customers and End Users

Determine if the system is running an unpatched version of SimpleHelp RMM either directly or embedded in third-party software.

SimpleHelp Endpoints

Determine if an endpoint is running the remote access (RAS) service by checking the following paths depending on the specific environment:

• Windows: %APPDATA%\JWrapper-Remote Access
• Linux: /opt/JWrapper-Remote Access
• MacOs: /Library/Application Support/JWrapper-Remote Access

If RAS installation is present and running, open the serviceconfig.xml file in <file_path>/JWrapper-Remote Access/JWAppsSharedConfig/ to determine if the registered service is vulnerable. The lines starting with <ConnectTo indicate the server addresses where the service is registered.

SimpleHelp Server

Determine the version of any SimpleHelp server by performing an HTTP query against it. Add /allversions (e.g., https://simple-help.com/allversions) to query the URL for the version page. This page will list the running version.

If an unpatched SimpleHelp version 5.5.7 or earlier is confirmed on a system, organizations should conduct threat hunting actions for evidence of compromise and continuously monitor for unusual inbound and outbound traffic from the SimpleHelp server. Note: This is not an exhaustive list of indicators of compromise.

1.  Refer to SimpleHelp’s guidance to determine compromise and next steps.³
2. Isolate the SimpleHelp server instance from the internet or stop the server process.
3. Search for any suspicious or anomalous executables with three alphabetic letter filenames (e.g., aaa.exe, bbb.exe, etc.) with a creation time after January 2025. Additionally, perform host and network vulnerability security scans via reputable scanning services to verify malware is not on the system.
4. Even if there is no evidence of compromise, users should immediately upgrade to the latest SimpleHelp version in accordance with SimpleHelp’s security vulnerabilities advisory.⁴

If your organization is unable to immediately identify and patch vulnerable versions of SimpleHelp, apply appropriate workarounds. In this circumstance, CISA recommends using other vendor-provided mitigations when available. These non-patching workarounds should not be considered permanent fixes and organizations should apply the appropriate patch as soon as it is made available.

Encrypted Downstream Customers and End Users

If a system has been encrypted by ransomware:

1. Disconnect the affected system from the internet.
2. Use clean installation media (e.g., a bootable USD drive or DVD) to reinstall the operating system. Ensure the installation media is free from malware.
3. Wipe the system and only restore data from a clean backup. Ensure data files are obtained from a protected environment to avoid reintroducing ransomware to the system.

CISA urges you to promptly report ransomware incidents to a local FBI Field Office, FBI’s Internet Crime Compliant Center (IC3), and CISA via CISA’s 24/7 Operations Center (report@cisa.gov or 1-844-Say-CISA).

Proactive Mitigations to Reduce Risk

To reduce opportunities for intrusion and to strengthen response to ransomware activity, CISA recommends customers of vendors and managed service providers (MSPs) implement the following best practices:

• Maintain a robust asset inventory and hardware list [CPG 1.A].
• Maintain a clean, offline backup of the system to ensure encryption will not occur once reverted. Conduct a daily system backup on a separate, offline device, such as a flash drive or external hard drive. Remove the device from the computer after backup is complete [CPG 2.R].
• Do not expose remote services such as Remote Desktop Protocol (RDP) on the web. If these services must be exposed, apply appropriate compensating controls to prevent common forms of abuse and exploitation. Disable unnecessary OS applications and network protocols on internet-facing assets [CPG 2.W].
• Conduct a risk analysis for RMM software on the network. If RMM is required, ask third-party vendors what security controls are in place.
• Establish and maintain open communication channels with third-party vendors to stay informed about their patch management process.
• For software vendors, consider integrating a Software Bill of Materials (SBOM) into products to reduce the amount of time for vulnerability remediation.
  • An SBOM is a formal record of components used to build software. SBOMs enhance supply chain risk management by quickly identifying and avoiding known vulnerabilities, identifying security requirements, and managing mitigations for vulnerabilities. For more information, see CISA’s SBOM page.

Resources

• Health-ISAC:Threat Bulletin: SimpleHelp RMM Software Leveraged in Exploitation Attempt to Breach Networks
• Arctic Wolf: Arctic Wolf Observes Campaign Exploiting SimpleHelp RMM Software for Initial Access
• CISA: #StopRansomware Guide

Reporting

Your organization has no obligation to respond or provide information back to FBI in response to this advisory. If, after reviewing the information provided, your organization decides to provide information to FBI, reporting must be consistent with applicable state and federal laws.

FBI is interested in any information that can be shared, to include boundary logs showing communication to and from foreign IP addresses, a sample ransom note, communications with threat actors, Bitcoin wallet information, decryptor files, and/or a benign sample of an encrypted file.

Additional details of interest include a targeted company point of contact, status and scope of infection, estimated loss, operational impact, transaction IDs, date of infection, date detected, initial attack vector, and host- and network-based indicators.

CISA and FBI do not encourage paying ransom as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, FBI and CISA urge you to promptly report ransomware incidents to FBI’s Internet Crime Complain Center (IC3), a local FBI Field Office, or CISA via the agency’s Incident Reporting System or its 24/7 Operations Center (report@cisa.gov) or by calling 1-844-Say-CISA (1-844-729-2472).

SimpleHelp users or vendors can contact support@simple-help.com for assistance with queries or concerns.

Disclaimer

The information in this report is being provided “as is” for informational purposes only. CISA does not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favor by CISA.

Version History

June 12, 2025: Initial version.

Notes

1. Anthony Bradshaw, et. al., “DragonForce Actors Target SimpleHelp Vulnerabilities to Attack MSP, Customers,” Sophos News, May 27, 2025, https://news.sophos.com/en-us/2025/05/27/dragonforce-actors-target-simplehelp-vulnerabilities-to-attack-msp-customers/.
2. For instructions for upgrading to the latest version of SimpleHelp, see SimpleHelp’s security vulnerability advisory.
3. To determine possibility of compromise and next steps, see SimpleHelp’s guidance.
4. For instructions for upgrading to the latest version of SimpleHelp, see SimpleHelp’s security vulnerability advisory.

• The profile backup mechanism has been enabled by default for all desktop platforms in Nightly, as well as Beta! The current plan is to have this ride out to Firefox 151 for Windows, macOS and Linux on May 18th!
  • This feature, when enabled, will create a copy of your profile data in the background and store it in a single file on your file system that you can restore from.
  • You will be able to manage this feature in Settings under Sync (for now)
    • 
  • You can read more about the feature here
• As followups to the recent addition to the WebExtension tabs API to support the new SplitView tabs feature, tabs.group() and tabs.ungroup() have been fixed to work correctly with split view tabs, and fixed split views being prepended instead of appended to tab groups when adopted into a new window – Bug 2029099 / Bug 2029534
• Adaptive autofill has been enabled on Nightly.
  • Previously, autofill only completed domains (e.g. typing red autofilled reddit.com). Now it can also complete full URLs for pages you visit often (e.g. red → reddit.com/r/firefox), learning from what you actually click in the address bar. If a suggestion isn’t helpful, you can now dismiss it so autofill learns what not to show you too.
    • If you run into issues or have feedback, you can file a bug here!
• Markus Stange [:mstange] implemented dynamic toolbar on top in RDM (#1978145), but also implemented some static skeleton UI so it’s closer to what we actually have in Firefox for Android
  • dynamic toolbar is behind a pref: devtools.responsive.dynamicToolbar.enabled
  • it can be put on top by setting devtools.responsive.dynamicToolbar.onTop, otherwise it’s at the bottom
  • 

Friends of the Firefox team

Resolved bugs (excluding employees)

Script to find new contributors from bug list

Volunteers that fixed more than one bug

• Amin Amir
• aoia7rz7l
• Chukwuka Rosemary
• DrSeed
• Frédéric Wang Nélar
• japandi
• John Iweh
• jonathancabera
• Josh Aas
• Keji Bakare
• kofoworola shonuyi
• konyhéa
• liz
• Mathew Hodson
• Okhuomon Ajayi
• Oluwatobi
• ROSHAAN
• Sam Johnson

New contributors (🌟 = first patch)

•  Anthony Mclamb: Disable the legacy Edge migrator
•  Amin Amir
  • 🌟Fix browsingContext.sys.mjs to assign to #contextCreatedHandled instead of contextCreatedHandled
  • Fix missing WITHOUT ROWID SQLite performance optimization in SERPCategorization.sys.mjs
  • 🌟 Amine Zroual: Omitted maxResults property not handled correctly in getRecentlyClosed
• any1here: install_sig_alt_stack incorrectly checks mmap’s return value
• 🌟 Armin Ulrich: Fix MessageHandlerRegistry.sys.mjs calling getExistingMessageHandler with an unused second argument
• japandi
  • Cannot remove amazon.com from top sites list
  • The height of the pinned tabs area should be responsive to the number of pins
  • Use cenum for nsIHelperAppLauncherDialog reason constants to enable better typescript annotations
• Nathan Johnson [:narjoDev]: Remove browser.display.use_system_colors pref
• DrSeed
  • Firefox shows vertical tabs in new windows despite “Hide tabs and sidebar” setting
  • The “Expand sidebar on hover” option is not kept after the vertical tabs are disabled and enabled again
• Keji Bakare:
  • Split view’s focus-outline is clipped on the right side of left tab
  • White space on the right side of left panel in split view
• 🌟 gotyaoi: Reload toolbar button is active on about:newtab
• Itoro James: [A11y][Keyboard Navigation]Cancelling a note via Keyboard Navigation still saves it
• John Iweh: The notification dot is not displayed if the tab is in a Split View
• 🌟 John Iweh: sidebar-shown attribute remains when sidebar.revamp is false
• 🌟 jonathancabera:
  • The Move tab to Split View option is also displayed for the tabs that are within the Split View
  • A Note with long text (1003 characters) is saved by pressing ENTER even if the “Save” button is disabled
  • Tab group guide line becomes disconnected under certain conditions related to split views in vertical tab mode
• Aloys: Remove logic that forces distribution language packs to be reinstalled when upgrading from Firefoxes older than 67
• liz:
  • Create test to ensure maxRenderCountEstimate is never being set to Infinity in virtual-list component in Fx View
  • Button accessible name does not convey its function: missing topic context (Settings dialog > Topics dialog > buttons Following/Unfollow/Blocked/Unblock)
• Mary cathline: Tab Group Label does not respect touch density in vertical tab bar
• 🌟 Brandon Lucier: Popups opened with window.open give window type normal instead of popup
• karan68: [dialog] New Shortcut dialog needs a label/accessible name
• 🌟 Vector: Button does not programmatically indicate that it opens a dialog (Recent activity section > story card > ••• disclosure > Delete from History button)
• 🌟 Osoble: Update font size and weight for synced tabs device name headers in Firefox View
• konyhéa:
  • Add test for sync admin disabled to browser_syncedtabs_errors_firefoxview.js
  • Check all second paramaters for TestUtils.waitForCondition in Fx View test files
  • Recently Closed Tabs, Tabs from Other Devices, and History pages should have Cmd / Ctrl + Click on a link open the link in the new background tab.
• Noble Chinonso: #shouldHandleEvent in SidebarTreeView.js compares event.keyCode to string values, causing Home/End keys to never be handled
• Pranjali Srivastava: Add a test to verify that the space above tabs is consistent across PB, LWT and sizemode (where appropriate)
• Okhuomon Ajayi:
  • More spacing is needed between the tab note icon and the close icon on the tab
  • The tabs in vertical mode collapsed state are positioned differently in Split View
  • Keep vertical split view tabs stacked vertically even when the sidebar is expanded when expand on hover is enabled
  • Vertical split view tabs can be too big or small when tabs are overflowing
• 🌟 Rishan: Fix duplicated arrow function in browser_history_sidebar.js
• Chukwuka Rosemary:
  • “Forget About This Site” context menu option missing from Firefox View history
  • Long strings are not displayed properly on the about:opentabs page search filed
  • Add test for Forget This Site option in Fxview history context menu.
• ROSHAAN:
  • 🌟Tab note background colour is incorrect for default light theme
  •  [win/linux] The splitter between content areas does not match Figma spec
  • Fix typo in OpenInTabsUtils.confirmOpenInTabs()
• Sameeksha: Disclosure button expanded/collapsed state not programmatically defined (Customize button)
• kofoworola shonuyi:
  • 🌟Actually hide or remove sidebar-shown attribute when in fullscreen.
  • Add a test for checking sidebar-shown attribute in fullscreen mode
• 🌟 Sayd Mateen: Page URL is displayed as tab name when page’s contains about:reader?</a></p> <p>