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 June 2026

For June, Adobe released 11 bulletins addressing 123 unique CVEs in Adobe Acrobat Reader, ColdFusion, Experience Manager, Experience Manager Forms, InDesign, InCopy, Substance 3D Sampler, Content Credentials SDK, Dreamweaver, Format Plugins, and Adobe Campaign Classic. A total of 11 of these CVEs were reported through the ZDI program.

Here’s this month’s overview table:

Obviously, the update for Campaign Classic should be on the top of your deployment list if you’re a user. A CVSS 10 is rare; two in the same bulletin is pretty much a unicorn. Adobe says there are no active attacks, but I would expect heavy research into creating one. The update for Coldfusion is also a Priority 1, but again, no known attacks is the wild. I suspect the Reader patch will also receive a lot of attention as malicious PDFs are common in ransomware attacks. The update for Experience Manager may be large, but it’s mostly just cross-site scripting (XSS) bugs.

Microsoft Patches for June 2026

This month, Microsoft released a new record 208 CVEs Windows and Windows components, Office and Office Components, Microsoft Edge (Chromium-based), Azure, .NET and Visual Studio, Github Copilot, Defender, Exchange Server, Hyper-V, Secure Boot, and BitLocker. At least, that’s my count. Microsoft’s tools seem to be having some issues, as they initially included a CVE from 2020 in this release. Regardless, the count is over 200, and I counted several times.

One of these bugs came through the ZDI program, but bugs submitted during Pwn2Own Berlin remain unpatched. If you include the Chromium and other third-party bugs, the total CVE count for June comes to a staggering 571 CVEs. 38 of these cases are rated Critical while the rest are rated Important in severity.

I’ve been counting CVEs on Patch Tuesday since 2017, and this is by far the largest monthly release in that time. The previous record was 177 set last year. It is extraordinary that Microsoft can produce so many patches in a single month, but it does raise concerns. How many of these cases were found using AI tools? How many patches were generated using AI to assist in coding or testing? What quality issues may exist in these patches? And likely most importantly, is this the new normal? The last two months were also large releases. Should sysadmins adjust their processes for prioritization and patch deployment based on this new volume of updates? Unfortunately, Microsoft is not providing those answers right now. Hopefully that changes in the future. BTW – just a note – the current number of CVEs shipped by Microsoft this year exceeds the total number of CVEs shipped in all of 2018.

One of the bugs patched by Microsoft this month is listed as under active exploitation and three others are listed as publicly known at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the bug being exploited in the wild.

-   CVE-2026-41091 - Microsoft Defender Elevation of Privilege Vulnerability
Since Microsoft doesn’t provide info on how widespread exploitation is, we must read some tea leaves. For this patch, several different people were acknowledged, which indicates multiple parties say this is in the wild, meaning exploitation is likely significant. The good news is that most people won’t need to take action as Defender updates itself. However, if you don’t have this configured or are in an isolated environment, you’ll need to update to the latest version.

-    CVE-2026-45657 - Windows Kernel Remote Code Execution Vulnerability
This CVSS 9.8 bug allows remote, unauthenticated attackers to execute code at SYSTEM level without user interaction. Yup – this is wormable. The problem lies in the way the kernel handles TCP/IP. This was listed as “Exploitation Less Likely” by Microsoft, but rest assured that every researcher and bug shop on the planet is reversing this patch right now trying to create an exploit. Test and deploy this patch quickly.

-    CVE-2026-47291 - HTTP.sys Remote Code Execution Vulnerability
Our second CVSS 9.8 bug of the month, this also allows remote, unauthenticated attackers to execute code on affected systems without user interaction. However, there is a caveat. Systems using the default MaxRequestBytes registry value used by the Windows HTTP stack are not affected by this bug. You can edit your registry settings if you need protection while you test and deploy the patch. The bulletin includes instructions and even a PowerShell script for doing this action. Microsoft lists this as “Exploitation more likely”, so I would definitely check your registry settings.

-    CVE-2026-44815 - DHCP Client Service Remote Code Execution Vulnerability
Here’s another CVSS 9.8 that has an odd incongruity. Although the CVSS says no permissions are required for exploitation, the write-up states it must be an “authenticated” user. I would err on the side of caution here and believe the CVSS. If that’s correct, then we have another bug where a remote, unauthenticated attacker could execute code on affected systems without user interaction. And since the DHCP client is on every OS, it’s a juicy target. This is another one to test and deploy with haste.

-    CVE-2026-45585/CVE-2026-50507 - Windows BitLocker Security Feature Bypass Vulnerability
If you’ve followed the ongoing saga of Nightmare Eclipse vs. MSRC, the bugs should look familiar. One is definitely a fix for “YellowKey”, while the other appears to be a fix for “GreenPlasma”. The researcher has promised a “bone shattering” drop on June 14, so let’s hope Microsoft is able to reach some understanding with the researcher before more 0-days are released. Also, there is a script provided by Microsoft as a mitigation, but the better strategy is to test and deploy the updates.

 Here’s the full list of CVEs released by Microsoft for June 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 release, the scariest-looking one is actually nothing to concern yourself with at all. The CVSS 10 bug in Azure HorizonDB has already been addressed by Microsoft and is just being documented now. That’s also the case for five others. Of course, there wouldn’t be a release without Office bugs that have the Preview Pane as an attack vector. There are multiple in June. There’s a handful of bugs in the Remote Desktop Client, but these rely on connecting to a malicious RDP server. There are three patches for Hyper-V that allow for guest-to-host code execution. The bug in Active Directory requires authentication, but any authenticated user can hit it. For the Windows Directory Service vulnerability, it needs to be listening for TFTP. You have blocked that everywhere, right? The bug in Azure Network Adapter is somewhat unique as you need to update your Linux kernel to be protected. The bug in Azure Kubernetes allows an attacker to break out of a container and gain control of the AKS worker node. Finally, the bug in the Kerberos Key Distribution Center (KDC) seems unlikely, but if exploited, it could allow authenticated attackers to get code execution on affected systems.

Moving on to the other code execution bugs, there are the ubiquitous open-an-own bugs in Office components like Excel and Word. The code injection bug in Exchange Server looks troubling, but it requires a machine-in-the-middle (MiTM), so exploitation is unlikely. The bugs in SharePoint require authentication, but you should note that the patch applies to both SharePoint Server 2016 and SharePoint Enterprise Server 2016. The two bugs in UPnP are interesting. Both can lead to code execution by causing an error during the handling of specially crafted data, which could lead to a Use After Free (UAF) bug. The bugs in RDP Client all require connecting to a malicious RDP server, but it’s not clear why some are rated Critical and some are rated Important. The NTFS vulnerability requires a user to mount a virtual hard drive on an affected system. The last RCE bug this month is in Azure Stack Edge and requires the attacker to send a specially crafted file upload request that includes a manipulated file name or path, leading to code execution.

There are more than 60 Elevation of Privilege (EoP) bugs in this month’s release, and 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. A notable exception is in Exchange Server, where a user on Outlook Web Access (OWA) could gain access to other mailboxes. The bug in Visual Studio Code could allow attackers to gain permissions associated with the MCP Server’s managed identity. The bugs in Windows SDK and Windows UI Automation Manager could let attacker go from low integrity up to medium integrity code execution. The bug in Bluetooth just allows “elevated” privileges without really describing what elevated might be.

Moving on to the more than 20 security feature bypass (SFB) bugs in the June release, there are a total of 10 that impact Secure Boot. All carry scope change (S:C) in the CVSS, meaning successful exploitation affects security boundaries beyond the vulnerable component itself — specifically the ability to load untrusted code at boot, bypass Virtual Secure Mode, and undermine boot integrity guarantees. CVE-2026-45654 explicitly calls out VSM exposure. The bulk of these are credited to Alon Leviev (STORM), which is notable given his prior BootKitty/BlackLotus-adjacent research. The bugs in the Windows Boot Manager have a similar impact as the Secure Boot bugs. The UEFI Secure Boot vulnerabilities go a layer deeper. They require either local admin or physical access but could allow for the running of untrusted code even before the OS loads. Rootkits anyone? The four bugs in BitLocker all require physical access but could yield encrypted data if exploited. The bug in Windows Administration Protection allows attackers to bypass the feature that prevents standard-user apps from performing admin-level actions. The bug in Visual Studio Copilot Chat could be the most interesting non-boot bug here as it allows authentication impersonation. Mark of the Web (MotW) and Excel vulns could bypass user warnings. Lastly, the bug in PC Manager bypasses expected user controls.

Turning our attention to the mass of spoofing bugs in the release, we instantly see 18 impacting SharePoint Server. Fortunately, these are simply cross-site scripting (XSS) bugs. It’s the Exchange bugs we should really watch for. One is an XSS that an attacker can exploit by convincing an Exchange administrator to open a malicious link or message, which then runs code in the admin's web session. That's a meaningful privilege escalation path. Another is listed as an SSRF-based attack, but no other details are available. The last is a lower-impact XSS with limited confidentiality/integrity loss. The bug in Bing Search (remember Bing?) is a classic search result spoofing. The bug in Azure Stack Edge is interesting as it could allow access to resources outside the vulnerable component's security boundary. The bug in Office for Android requires user interaction. The Office Project Server bug is an authenticated XSS with low impact. The final spoofing bug is in Azure Attestation but has already been addressed. You should still verify you are protected by following the instructions in the write-up from Microsoft.

There are 30 different information disclosure bugs in this release, and fortunately, the vast majority of these simply result in info leaks consisting of unspecified memory contents or memory addresses. The two bugs in Visual Studio require user interaction and could “disclose information over a network.” How obtuse. The bug in GitHub Copilot and Visual Studio Code could disclose discloses a sign-in access token for a user's work account. That's a meaningful credential exposure, not just random memory. That leaves the two bugs in Exchange Server. One could allow an authenticated user to gain information about which network services that the Exchange server can reach. The other sounds much like the spoofing bug in OWA as it allows attackers to see information in mailboxes they should not have access to.

I’ve never been a fan of the “tampering” category, as it could mean so many different things. For example, the bug in .NET simply says it could allow an unauthorized attacker to perform tampering locally. Similarly, the bug in Visual Studio says the same, expect here the tampering occurs over a network. Microsoft doesn’t even bother with a CWE for the tampering bug in the DHCP Server, so your guess is as good as mine.

There are seven DoS bugs in the June release, and as usual, Microsoft provides little to no actionable information about the vulnerabilities. The most interesting is the bug in HTTP.sys, which is listed as publicly known. This is an uncontrolled resource consumption, rated "Exploitation More Likely," and publicly disclosed. Since, HTTP.sys sits at the core of IIS and Windows web services, a network-accessible DoS here can take down any Windows server running HTTP-based services. Based on the Acknowledgement, it looks like this bug may have been found using AI. There are no real details for the other bugs, but based simply on the impact, I would focus on the Kerberos and TCP/IP bugs if you had to prioritize.

No new advisories are being released this month.

Looking Ahead

The next Patch Tuesday will be on July 14 and will be the last one before Black Hat/DEFCON. It’s usually a big release, so strap in and hang on. I’ll be back then to give you my full thoughts. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

A remote code execution vulnerability exists in the HTTP Protocol Stack for Microsoft Internet Information Services implemented in HTTP.sys. The vulnerability is due to invalid validating incoming HTTP requests.

A remote, unauthenticated attacker can exploit this vulnerability by sending crafted HTTP packets to the target system. Successful exploitation of this vulnerability can result in a denial-of-service condition, or, in the worst case, code execution with kernel privileges.

The Vulnerability

HTTP.sys is the kernel-mode HTTP protocol driver in Microsoft Windows. It provides HTTP request parsing, response caching, and SSL/TLS termination for Internet Information Services (IIS) and other applications that register URL prefixes. The driver listens on configured TCP ports (commonly 80 for HTTP and 443 for HTTPS) and processes inbound HTTP/1.x and HTTP/2 requests at the kernel level.

When operating over HTTPS, HTTP.sys delegates TLS processing to the Windows Secure Channel (SChannel) provider. Inbound TCP data is decrypted on a per-record basis: each TLS record constitutes an independent unit of encryption and is decrypted separately by SChannel before being delivered to HTTP.sys as a distinct plaintext buffer. A single TLS 1.3 application data record has the following structure:

The decrypted payload of each TLS record is delivered independently to the HTTP parser via

UlHttpBufferReceiveEvent(), regardless of how many TLS records the underlying TCP connection coalesces into a single TCP segment. This behavior is distinct from plaintext HTTP connections, where the Windows TCP stack coalesces multiple segments into a single receive indication before the data reaches HTTP.sys.

The HTTP parser maintains a per-request state object that includes a dynamically grown buffer reference array. The capacity field stores the current number of allocated slots in the buffer reference array. The count field stores the number of slots currently in use. The ref_array_ptr field points to the dynamically allocated array of 8-byte buffer reference entries.

An integer overflow vulnerability exists in HTTP.sys. The vulnerability is due to insufficient bounds checking when growing a buffer reference array during HTTP/1.x header parsing. When HTTP.sys receives data for an HTTP/1.x request, it allocates a UL_REQUEST_BUFFER structure for each receive indication and tracks these buffers in the per-request reference array described above. The count field records the number of active buffer references, and the capacity field records the total number of allocated slots.

As the HTTP parser (UlpParseNextRequest()) processes header lines, it calls an inline buffer reference routine each time a new receive buffer is consumed. When count reaches capacity, the routine grows the array by reallocating it with five additional slots. The new allocation size is computed as 0x28 + capacity * 8, the contents of the existing array are copied via memmove using count * 8 as the copy length, and capacity is incremented by 5 as a 16-bit unsigned integer addition. No overflow check is performed on this addition.

After 13,107 growth events, capacity reaches 0xFFFB. The next growth adds 5, producing 0x10000, which truncates to 0x0000 in the 16-bit field. On the subsequent buffer reference addition, count (which is now 65,536 or greater) exceeds the zero capacity, triggering another growth. The allocation size computation 0x28 + 0 * 8 produces a 40-byte allocation, but the memmove copies count * 8 bytes (approximately 524,256 bytes) from the old buffer into the 40-byte allocation. This results in a kernel pool heap buffer overflow of over 500 kilobytes.

Each buffer reference corresponds to one receive buffer delivered to the HTTP parser. For plaintext HTTP connections, the Windows TCP stack coalesces received segments into large indications, and UlpMergeBuffers() further combines buffers within HTTP.sys. Over TLS connections, each TLS record is decrypted independently by SChannel and delivered as a separate buffer through UlHttpBufferReceiveEvent() into UlpCopyIndicatedData(). If each TLS record contains exactly one complete header line (terminated by CRLF), the HTTP parser fully consumes the buffer without setting the partial-parse flag, causing UlpAdjustBuffers() to advance to the next buffer via its non-merge path. This creates a 1:1 correspondence between TLS records sent and buffer references accumulated.

To trigger the overflow, an attacker crafts an HTTP request in which each header line is encapsulated in a separate TLS application data record. Given a minimum header line size of approximately 4 bytes and a required count of 65,536 buffer references, the total request size comes to roughly 262,144 bytes. The MaxRequestBytes registry value (at HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters) must be configured to a value of at least 262,144 bytes for the server to accept a request of this size. The default value of 16,384 bytes limits the request to approximately 4000 header lines, which is insufficient to trigger the overflow. As a mitigation, keeping MaxRequestBytes at or below 65,535 bytes represents the most conservative configuration to prevent this attack.

A remote unauthenticated attacker could exploit this vulnerability by sending a specially crafted HTTP/1.x request over a TLS connection to an affected server. Successful exploitation results in unexpected system termination due to a memory access exception in the context of the kernel. Under specific memory layout conditions, exploitation could result in arbitrary code execution in the context of the kernel.

Notes:

• The vulnerability is only reachable through HTTP/1.x header parsing over TLS connections. HTTP/2 and HTTP/3 use different parser paths that do not interact with the buffer reference array.

• Body data parsing (Content-Length or chunked transfer encoding) does not add entries to the buffer reference array. Only header parsing triggers buffer reference growth.

• At a sending rate of 10 milliseconds per TLS record, the overflow requires approximately 11 minutes to trigger.

Source Code Walkthrough

The following code snippet was taken from HTTP.sys version 10.0.26100.7705. Comments added by TrendAI Research have been highlighted.

In UlpParseNextRequest():

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the TCP port 443.

The traffic on the affected port(s) is TLS-encrypted. The detection device must be able to decrypt the TLS traffic before applying the following detection method. The detection device should monitor for HTTPS connections.

An HTTP/1.x request [1] consists of a request line followed by zero or more header field lines, each terminated by CRLF. The following grammar defines the relevant structure:

Decrypted traffic inspection:

After decrypting the TLS session, the detection device must parse the HTTP/1.x request headers. The detection device must count the number of distinct header field lines present in a single HTTP request. If the number of header field lines in a single request exceeds 1,000, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Encrypted traffic heuristics:

Where decryption is not available, the detection device should inspect the pattern of TLS application data records within the encrypted session. If each TLS application data record contains a single short payload and the total number of such records on a single connection exceeds 1,000, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Notes:

• The preferred detection method (header line count) requires the ability to decrypt TLS traffic, for example through TLS inspection, a decrypting proxy, or possession of the server's private key. This method directly observes the attack indicator and produces low false-positive and false-negative rates.

• The TLS record heuristic operates on encrypted traffic and does not require decryption. This method is more prone to false positives (legitimate applications that send many small TLS records, such as interactive streaming sessions, may trigger the heuristic) and to false negatives (the threshold is based on observable record sizes rather than the actual header count that determines exploitability). Where possible, decrypted traffic inspection should be preferred.

• The attack requires approximately 11 minutes of sustained connection to accumulate sufficient header lines. Connection duration monitoring may serve as a supplementary detection heuristic.

Conclusion

This vulnerability was patched by Microsoft in the June 2026 release cycle. They note several mitigations that include editing the registry to ensure unpatched systems are not vulnerable to exploitation. However, the best method to ensure this bug has been fully remediated is to test and deploy the vendor-supplied patch.

Special thanks to Yazhi Wang and Jonathan Lein 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.

For Jun 2026, Apple released 37 unique CVEs across iOS 26.5.2 / iPadOS 26.5.2, macOS Tahoe 26.5.2, Safari 26.5.2. Since Apple doesn’t provide CVSS scores or other severity information, we’re left to speculate on which of these bugs is the most severe. The overwhelming majority (31 of 37) are WebKit/WebRTC bugs reachable through malicious web content. Most of those are crash/DoS bugs rather than code execution, so the real risk lives in the small set of kernel bugs and the handful of WebKit sandbox escapes. However, there are a couple that stand out.

-    CVE-2026-43724 (Kernel) – According to Apple, “An app may be able to cause unexpected system termination or write kernel memory.” A kernel memory write is the highest-value primitive here: it's the privilege-escalation half of a full exploit chain and leads to complete device control. The bug was credited to Hyunwoo Kim (@v4bel), who is known to be a serious kernel researcher.

-    CVE-2026-39868 (Kernel) – Another kernel bug, this one could “cause unexpected system termination or corrupt kernel memory.” This is kernel memory corruption, and notably credited to a roster of elite offensive researchers (STAR Labs, Positive Technologies, Baidu Security). This kind of attribution usually signals a weaponizable, possibly Pwn2Own-grade bug rather than a theoretical crash.

-    CVE-2026-43725 / CVE-2026-43701 (WebKit) – Apple states these bugs could allow a website to process restricted web content outside the sandbox. I'm flagging this sandbox-escape pair over the many WebKit crash bugs because a sandbox escape is the bridge that turns a web-content bug into a path toward the kernel issues above. It's the most dangerous remotely-triggered class in the release.

Here’s a look at all the bugs released by Apple this month:

We’ll continue these macOS updates if people find them useful. Stay tuned for the regularly schedule Patch Tuesday blog covering Adobe and Microsoft.

Pwn2Own Ireland returns for 2026, and it’s the third year for this event in the Emerald Isle. Despite the dreary Irish skies (and the threat of a random banshee), we had an amazing event, even if we did end up in a jail at the end. With that in mind, we’re excited to return to Cork this fall for yet another great Pwn2Own event. We’ll also be returning to some of the great pubs Ireland has to offer in the evenings and wrapping the event up at a special location (stay tuned for that announcement).

As for the contest itself, it will run from October 6-9, 2026. As always, we’ll have a random drawing to determine the schedule of attempts on the first day of the contest, and we will proceed from there. Registration closes at 5:00 p.m. Irish Standard Time on Oct 1st, 2026. There are no exceptions for late entries, so if you have questions, please contact us at pwn2own@trendmicro.com (note the address). We will be happy to address your issues or concerns directly.

Due to the overwhelming amount of registrations and last-minute entries for our Pwn2Own Berlin event, we’re changing who can enter the contest a bit to ensure it’s fair for all researchers. To enter, you must have received an aggregate bounty payment totaling at least $15,000 during their life-time participation in ZDI. This includes past Pwn2Own events and our regular bug bounty program. We recognize there may be some who haven’t participated in the past with great exploits to demonstrate, so we will also accept up to 10 new contestants at our discretion. We’re capping the number of entries to 80 this year. Once we have 80 qualifying entries, we will close registration. That means if you want to enter, it is in your best interest to contact us sooner rather than later. Please read the rules thoroughly to ensure you meet all the requirements.

Now on to this year’s target categories. We’ll have seven different categories for this year’s event:

-- Mobile Phones
-- Smart Home Devices
-- Wellness
-- Printers
-- Messaging
-- AI Infrastructure
-- AI Coding Agents

Let’s take a look at each category in more detail, starting with mobile phones.

The Target Phones

Back in Amsterdam where this contest originated, it was originally dubbed “Mobile Pwn2Own” and our focus was strictly on phones. Mobile handsets remain at the heart of this event, and some of the Samsung entries from last year were absolutely smashing. As always, these phones will be running the latest version of their respective operating systems with all available updates installed. Last year we also introduced the USB attack vector, but no one submitted an entry for it. We’ll see if that changes this year.

Otherwise, contestants must compromise the device by browsing to content in the default browser for the target under test or by communicating with the following short-distance protocols: near field communication (NFC), Wi-Fi, or Bluetooth. The awards for this category are:

Back to top

Smart Home Devices

As you might have noticed, we have eliminated most of the consumer-related devices from this year’s event. However, there are still a few “pro-sumer” devices that still could have an impact on enterprises, and the first of these categories are the devices that control other devices and services. An attempt in this category must be launched against the target’s exposed network services, RF attack surface, or exposed features from the contestant’s laptop within the contest network.

Back to top

Wellness Category

This is one of the new categories this year and our first foray into the world of healthcare devices. However, we don’t intend to make this too easy. Entries that require physically pressing any button on the target, or the use of any information, code or PIN printed on the device, are out of scope. Entries that require the contestant to be paired to the target prior to the start of the attempt are not in scope. An attempt in this category must be launched against the target’s exposed network services, RF attack surface, or exposed features from the contestant’s laptop within the contest network.

Back to top

Rage Against the Printers

Printers have long been the source of jokes and memes, but they are also an often overlooked attack surface in your office. The printer category always produces some interesting results, often by playing music it shouldn’t or the occasional Rick Roll. We’ve reduced the number of targets in this category this year, but we still expect to see some interesting exploits in these oft unheralded targets.

Back to top

The Messaging Category

We introduced WhatsApp as a target last year and came close to seeing a functioning exploit. Sadly, that didn’t happen. However, WhatsApp is used by more than three billion people globally, and some of the messages transmitted can be quite sensitive. That’s why we are bringing it back and hoping for some better results. We know the bugs are out there. We’re just hoping the right researcher decides to show us an exploit that leads to code execution. All of the target handset will be available as clients. Here’s the full prize list for Messaging category:

Back to top

AI Infrastructure Category

We introduced these targets at Pwn2Own Berlin, and we saw such…uh…enthusiasm from the community that we decided to immediately bring them back for our Ireland event. An attempt in this category must be launched from the contestant’s laptop. Here’s a look at the targets and awards in the AI Infrastructure category:

Back to top

AI Coding Agent Category

Let’s face it. At some point or another, we’ve probably all vibe coded something. There’s no shame in that, but how secure are the tools we use for vibe coding? Well, let’s take the most popular choices and find out. A successful entry must interact with a contestant-controlled resource (e.g. web page, repository, media file) to exploit a vulnerability within the coding agent. The attack vector of the entry must be a common coding agent use case. There are few things out of scope here as well. UI spoofing or misrepresentation unrelated to permission prompts, model jailbreaks or prompt outputs that do not cross security boundaries, and vulnerabilities that require unsafe or permission-less modes are just a few of the things not allowed. As this is a recently updated category, please read the rules carefully to ensure your entry qualifies. Here’s a look at the targets and awards in the AI Coding Agent category:

Back to top

Master of Pwn

No Pwn2Own contest would be complete without crowning a Master of Pwn, which signifies the overall winner of the competition. Earning the title results in a slick trophy, a different sort of wearable, and brings with it an additional 65,000 ZDI reward points (instant Platinum status in 2027).

For those not familiar with how it works, points are accumulated for each successful attempt. While only the first demonstration in a category wins the full cash award, each successful entry claims the full number of Master of Pwn points. Since the order of attempts is determined by a random draw, those who receive later slots can still claim the Master of Pwn title – even if they earn a lower cash payout. As with previous contests, there are penalties for withdrawing from an attempt once you register for it. If the contestant decides to remove an Add-on Bonus during their attempt, the Master of Pwn points for that Add-on Bonus will be deducted from the final point total for that attempt. For example, someone registers for the Apple iPhone 15 with the Kernel Bonus Add-on. During the attempt, the contestant drops the Kernel Bonus Add-on but completes the attempt. The final point total will be 20 Master of Pwn points.

The Complete Details

The full set of rules for Pwn2Own Ireland 2026 can be found here. They may be changed at any time without notice. We highly encourage potential entrants to read the rules thoroughly and completely should they choose to participate. We also encourage contestants to read this blog covering what to expect when participating in Pwn2Own.

Registration is required to ensure we have sufficient resources on hand at the event. Please contact ZDI at pwn2own@trendmicro.com to begin the registration process. (Email only, please; queries via social media, blog post, or other means will not be acknowledged or answered.) If we receive more than one registration for any category, we’ll hold a random drawing to determine the contest order. Registration closes at 5:00 p.m. Irish Standard Time on Oct 1st, 2025.

The Results

We’ll be blogging and tweeting results in real-time throughout the competition. Be sure to keep an eye on the blog for the latest information. Follow us on Twitter at @thezdi and @trendaisecurity, and keep an eye on the #P2OIreland hashtag for continuing coverage.

We look forward to seeing everyone in Cork, and we look forward to seeing what new exploits and attack techniques they bring with them.

©2026 Trend Micro Incorporated. All rights reserved. PWN2OWN, ZERO DAY INITIATIVE, ZDI, TrendAI, and Trend Micro are trademarks or registered trademarks of Trend Micro Incorporated. All other trademarks and trade names are the property of their respective owners.

The post Cl0p Targets Internet-Exposed Windchill Servers in Global Engineering Data-Theft Campaign appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

A remote code execution vulnerability has been reported in Microsoft Windows Notepad. The vulnerability is due to improper validation of links in Markdown files.

A remote attacker could exploit this vulnerability by enticing the victim to download and interact with a malicious file. Successful exploitation of this vulnerability could result in the execution of arbitrary commands in the security context of the victim's account.

The Vulnerability

Microsoft Windows comes with a default text-editing application called Windows Notepad. Historically, this application offered only minimal editing features. However, modern versions of Windows include an improved and extended Notepad by default. This new version supports multiple file formats, Markdown rendering, and Copilot-enhanced features.

Markdown is a lightweight markup language that allows users to create formatted text using a simple syntax. It is widely used for writing documents, blog posts, and README files. It supports a wide range of formatting options, including (but not limited to) headers, styled text, numbered and bulleted lists, and links. Markdown supports two main link formats: standard and inline. The standard link format is:

          [link-name](link/path)

When rendered, only the link text ("link-name") is shown to the user.

The inline links use the following format:

          <link/path>

When rendered, they are transformed into the equivalent standard link:

          [link/path](link/path)

A remote code execution vulnerability has been reported in Microsoft Windows Notepad. The vulnerability is due to improper validation of links when handling Markdown files.

When Notepad opens a file, if the application detects that the file requires special rendering (in this case, Markdown), the input file is tokenized. Tokenization in this context means splitting the raw file text into a sequence of small, recognizable pieces ("tokens") that the renderer can process one by one. Detection is performed based on the file extension. Only the ".md" extension was found to trigger Markdown rendering, as the application uses a fixed string comparison to determine whether Markdown should be rendered by calling sub_1400ED5D0(). Markdown files are rendered token by token.

Function sub_140170F60() handles clicking on links in Markdown files. It filters the link value, and passes it to ShellExecuteExW() call.

The filtering performed on the link is found to be insufficient, as it allows using malicious crafted protocol URIs, such as "file://" and "ms-appinstaller://", to execute arbitrary files in the security context of victim. ShellExecuteExW() uses the configured protocol handlers and may expose additional exploitable protocols depending on the system configuration.

A remote attacker could exploit this vulnerability by enticing the victim to download a malicious crafted Markdown file, open it, and click on a malicious link. Successful exploitation of this vulnerability could result in the execution of arbitrary commands in the security context of the victim's account.

Notes
• Files using the ".md" file extension are not registered to be opened by Notepad by default. However, when opened manually in Notepad, they are rendered as Markdown, which allows the vulnerability to be triggered.
• Any "\\" sequences are converted to "\" in the attacker-controlled link path prior to passing it to the ShellExecuteExW() call.

Source Code Walkthrough

The following code snippet was taken from Notepad.exe version 11.2508. Comments added by TrendAI researchers have been highlighted.

In sub_140170F60():

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the following application protocols that can be used to deliver an attack to exploit this vulnerability:
• FTP, over ports 21/TCP, 20/TCP
• HTTP, over port 80/TCP
• HTTPS, over port 443/TCP
• IMAP, over port 143/TCP
• NFS, over ports 2049/TCP, 2049/UDP, 111/TCP, 111/UDP
• POP3, over port 110/TCP
• SMTP, over ports 25/TCP, 587/TCP
• SMB/CIFS, over ports 139/TCP, 445/TCP

The detection device must inspect traffic transferring a Markdown file with the file extension ".md". If such a file transfer is found, the detection device must search the file content for links.

The detection device must check whether the link paths contain the strings "file:" or "ms-appinstaller:".

If "file:" was found, the detection device must search the Markdown file contents using the following case-insensitive regular expression:

(\x3C|\[[^\x5d]+\]\()file:(\x2f|\x5c\x5c){4}

If "ms-appinstaller:" was found, the detection device must search the Markdown file contents using the following case-insensitive regular expression:

(\x3C|\[[^\x5d]+\]\()ms-appinstaller:(\x2f|\x5c\x5c){2}

If any of the regular expressions matches, the link contains a path to a remote resource. The traffic must be considered malicious; an attack exploiting this vulnerability is likely underway. This guidance should also detect the public PoC that was recently posted on GitHub.

Notes

•  The string matches are case-insensitive.
•  The detection guidance is based on the vendor-provided patch. However, the patch restricts the links to local-only files and HTTP(S) URIs, which may result in a huge number of false positives. Because of that, the detection guidance focuses on formats that may access and execute remote files. Due to that, it may result in false negatives.
•  The vulnerable function uses the configured protocol handlers and may expose additional exploitable protocols depending on the system configuration.

Conclusion

This vulnerability was patched by Microsoft in the February 2026 release cycle. They note no workarounds but do list user interaction as a prerequisite to exploitation. To fully remediate the vulnerability, the proper action is to test and deploy the provided vendor patch.

Special thanks to Nikolai Skliarenko and Yazhi Wang 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.

A command injection vulnerability has been reported in Arista NG Firewall. The vulnerability is due to improper validation of user data in the diagnostics component.

A remote, authenticated attacker could exploit this vulnerability by sending crafted requests to the target server. Successful exploitation could result in arbitrary command execution under the security context of the root user.

The Vulnerability

Arista NG Firewall is an open-source firewall appliance. It was originally developed under the name Untangle. Some features of Arista Firewall include spam blocking, bandwidth control, and IPS, etc. NG Firewall can be managed through a web user interface, or a JSON-RPC API using HTTP.

HTTP is a request/response protocol described in RFCs 7230 - 7237 and other RFCs. A request is sent by a client to a server, which in turn sends a response back to the client. An HTTP request consists of a request line, various headers, an empty line, and an optional message body

where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF). SP represents a space character. Parameters can be passed from the client to the server as name-value pairs in either the Request-URI, or in the message-body, depending on the Method used and Content-Type header. For example, a simple HTTP request passing a parameter named “param” with value “1”, using the GET method might look like:

A corresponding HTTP request using the POST method might look like:

If there is more than one parameter/value pair, they are encoded as '&'-delimited name=value pairs:

          var1=value1&var2=value2&var3=value3...

The component relevant to this report is the JSON-RPC endpoint. A JSON object has the following syntax:

•            An object is enclosed in curly braces {}.
•            An object consists of zero or more items delimited by a comma (",") character.
•            An item consists of a key and a value. A key is delimited from its value by a colon (":") character.
•            A key must be a string (enclosed in quotes).
•            A value must be a valid type. Valid types include string, number, JSON object, array, Boolean, or null.
•            An array is an object enclosed in square braces []. An array consists of zero or more string, number, JSON object, array, Boolean or null type-objects delimited by a comma (",") character.

An example JSON object is as follows:

The following is an example of a JSON-RPC request to the runTroubleshooting() method that is relevant to this report:

A command injection vulnerability has been reported in Arista NG Firewall. The vulnerability is due to improper validation of user data that is used in a command line. The runTroubleshooting() method of the class NetworkManagerImpl will be used to handle JSON-RPC requests to the runTroubleshooting method. The command parameter passed to the method will be the first element in the params JSON array in the body of the request. This value must be one of the strings in the TroubleshootingCommands enum defined in the NetworkManager class. The second parameter of the method will contain additional arguments passed to the JSON-RPC call.

The method will first iterate through each of the additional arguments and combine each key value pair into a single string, separated by a "=" character that will later be used as an environment variable. Next, a switch case statement is used to ensure the provided command is one of the values in TroubleshootingCommands. Each command value will be processed using the same code.

The method will next iterate through each environment variable, and inspect it for the following common command injection strings:

          ; & | > $(

If any are found, the request will be rejected, and an exception is thrown. If each environment variable is valid, the method execEvil() is called to create and execute a command line for the network-troubleshooting.sh script, with the environment variables passed as a parameter. The execEvil() method in turn will call Runtime.getRuntime().exec() to run the script, with the second parameter passing the environment variables that will be used by the script. Each command value will have a function in network-troubleshooting.sh, such as run_dns() for the “DNS” command value. Each function will follow a similar structure, by creating a CMD string using the environment variables passed by exec() and then calling eval to execute it.

However, the values of the parameters passed to the runTroubleshooting JSON-RPC method are not completely sanitized before it is used in the command line. While the parameters passed to the endpoint are inspected for some shell metacharacters, the list is incomplete. For example, the backtick character (`) is not included in the check and may be used to inject a command.

For example:

The example above will write and execute a python script on the server to achieve code execution without using any restricted characters.

A remote, authenticated attacker could exploit this vulnerability by sending a JSON-RPC request to the runTroubleshooting method containing a crafted “HOST” or “URL” parameter containing shell metacharacters not present in the runTroubleshooting() check. Successful exploitation in the worst case will result in arbitrary command execution under the security context of the root user.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the following ports:
          - HTTP, over port 80/TCP
          - HTTPS, over port 443/TCP

Traffic to Arista NG Firewall may be encrypted and must be decrypted prior to applying this guidance.

The detection device must search for HTTP POST requests made to the request-URI /admin/JSON-RPC. If found, the body of the request must be parsed as JSON. The JSON object in the body must be inspected for a method key, and its value must be inspected to contain the substring runTroubleshooting. If found, the object must also be inspected for the JSON key "params", with a value containing a JSON array. The first entry in the JSON array must be inspected for any of the following strings:

If found, the second entry in the array must be inspected for a JSON object, and inspected for any of the following keys:

If either is found, the corresponding value to the key must be inspected for any of the following command injection characters:

If found, the traffic should be treated as suspicious; an attack exploiting this vulnerability is likely underway.

The following regular expression can be applied to find malicious requests:

          /\x22(HOST|URL)\x22\s*:\s*\x22(?:[^\x22\\]|\\.)*?[\x60\x27\x24\x3c]/

Notes:

• String matching on the request-URI and all JSON strings should be done in a case sensitive manner.
• The JSON strings may be encoded and must be decoded prior to applying this guidance.
• The request-URI may be URL-encoded and must be decoded before applying this guidance.

Conclusion

This vulnerability has been addressed by Arista with their Security Advisory 0123. They note that the Arista Edge Threat Management - Arista Next Generation Firewall (Formerly Untangle) is affected by this bug, but other product versions are not. They also state the following mitigation can be applied:

Do not allow non-authorized administrative access or access to the administrative browser.

However, the more appropriate action is to apply the provided vendor security patch by upgrading to version 17.4 or higher.

Special thanks to Jonathan Lein and Simon Humbert 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.

Willkommen zurück, meine Damen und Herren, zu unserem zweiten Wettbewerb in Berlin! That’s correct (if Google translate didn’t steer me wrong). After our inaugural competition last year, Pwn2Own returns to Berlin and OffensiveCon. Outside of our shipping troubles, we had an amazing time and can’t wait to get back.

Last year, we added Artificial Intelligence as a category with great results. This year, we’re expanding this and splitting it into multiple different categories: AI Databases, Coding Agents, Local Inferences, and a separate category for NVIDIA products. In last year’s contest, NVIDIA targets had wins, losses, and collisions, so it will be interesting to see how they fare this year. The folks from AWS wanted to get into the fray as well, so they stepped up to co-sponsor this year’s event, which allows us to increase the reward for bugs in Firecracker. Of course, we have all of the returning categories as well, including web browsers, containers, servers, virtualization, and operating systems. There’s more than $1,000,000 in cash and prizes available for contestants. Last year, we awarded $1,078,750 for 28 unique 0-days over the three-day event. We’ll see if we can eclipse those numbers in 2026.

The contest begins on May 14, but registration closes on May 7, so don’t delay in getting those submissions in. We’re hoping for maximum participation, so set aside your vibe coding and show us what you can really do. We’re looking forward to some cutting-edge exploitation on display. For 2026, we have a total of 31 targets across 10 categories. Here is a full list of the categories for this year’s event:  

-- Virtualization
-- Web Browser
-- Enterprise Applications
-- Servers
-- Local Escalation of Privilege
-- Containers
-- AI Database
-- Coding Agents
-- Local Inference
-- NVIDIA

Of course, no Pwn2Own competition would be complete without us crowning a Master of Pwn (Meister von Pwn?). Since the order of the contest is decided by a random draw, contestants with an unlucky draw could still demonstrate fantastic research but receive less money since subsequent rounds go down in value. However, the points awarded for each unique, successful entry do not go down. Someone could have a bad draw and still accumulate the most points. The person or team with the most points at the end of the contest will be crowned Master of Pwn, receive 65,000 ZDI reward points (enough for Platinum status), a killer trophy, and a pretty snazzy jacket to boot.

Let's look at the details of the rules for this year's event.

Virtualization Category

Some of the highlights for each contest can be found in the Virtualization Category, and we’re thrilled to see what this year’s event could bring with it. As usual, VMware is the main highlight of this category as we’ll have VMware ESXi return with an award of $150,000. Last year produced the first ESXi exploits in Pwn2Own history, so it will be interesting to see if we get more. Microsoft also returns as a target and leads the virtualization category with a $250,000 award for a successful Hyper-V Client guest-to-host escalation. Kernel-based Virtual Machine (KVM) is our final target in this category with a prize of $50,000.

There’s an add-on bonus in this category as well. If a contestant can escape the guest OS, then gain arbitrary code execution on the virtualization target and obtain arbitrary code execution in the guest operating system on a separate virtual machine managed by the same targeted virtualization target, they’ll earn another $50,000. That could push the payout on a ESXi bug to $200,000. This bonus is for KVM and ESXi only. Here’s a detailed look at the targets and available payouts in the Virtualization category:

Back to top

Web Browser Category

While browsers are the “traditional” Pwn2Own target, we’re continuously tweaking the targets in this category to ensure they remain relevant. We re-introduced renderer-only exploits a couple of years ago, and this year, we’ve increased the award to $75,000. In fact, we’ve increased the awards across the board for this category. Here’s a detailed look at the targets and available payouts:

Back to top

Enterprise Applications Category

Enterprise applications return as targets with Adobe Reader and various Office components on the target list once again. Attempts in this category must be launched from the target under test. For example, launching the target under test from the command line is not allowed. Prizes in this category run from $50,000 for a Reader exploit with a sandbox escape or a Reader exploit with a kernel privilege escalation, and $150,000 for an Office 365 application. Word, Excel, and PowerPoint are all valid targets. Microsoft Office-based targets will have Protected View enabled where applicable. Adobe Reader will have Protected Mode enabled where applicable.

This year, we’re adding a bonus for Copilot data exfiltration and Copilot action execution. Microsoft just patched a bug like this in Excel, so we know they are out there. If you’re able to exploit Copilot in addition to a Microsoft application, you’ll earn an additional $50,000. There are quite a few rules and scenarios around this add-on, so be sure to read the rules carefully and contact us with questions. Here’s a detailed view of the targets and payouts in the Enterprise Application category:

Back to top

The Server Category

The Server Category for 2026 focuses solely on the server components we’re most interested in. These servers are often targeted by everyone from ransomware crews to nation/state actors, so we know there are exploits out there for them. The only question is whether we’ll see any of the competitors bring one of those exploits to Pwn2Own. Last year, the bugs demonstrated in SharePoint ended up being exploited in the wild, so we know people are looking for these with great interest. Microsoft Exchange has been a popular target for some time, and it returns as a target this year as well, with a payout of $200,000. This category is rounded out by Microsoft Windows RDP/RDS, which also has a payout of $200,000. Here’s a detailed look at the targets and payouts in the Server category:

Back to top

Local Escalation of Privilege Category

This category is a classic for Pwn2Own and focuses on attacks that originate from a standard user and result in executing code as a high-privileged user. A successful entry in this category must leverage a kernel vulnerability to escalate privileges. Red Hat Enterprise Linux for Workstations returns as our Linux-based target, while Apple macOS, and Microsoft Windows 11 return as targets in this category. Prior exploits in this category have won Pwnie awards, so they’re always interesting to see. Here’s a detailed look at the targets and payouts in this category:

Back to top

The Container Category

We’re excited to have this category return for its third season, and we’re hopeful that even more contestants will target one of these container targets. For an attempt to be ruled a success against these three, the exploit must be launched from within the guest container/microVM and execute arbitrary code on the host operating system. Again, with help from AWS, Firecracker returns as a target with a prize of $100,000. Here are the targets and payouts for this category:

Back to top

AI Database Category

In the past, AI Hackathons have focused on using AI to develop vulnerabilities or other offensive frameworks. We’re opening up the models and various components themselves for exploitation. The first AI sub-category focuses on databases. An attempt in this category must be launched from the contestant’s laptop. Here’s a look at the targets and awards in the AI Database category:

Back to top

The Coding Agent Category

Let’s face it. At some point or another, we’ve probably all vibe coded something. There’s no shame in that, but how secure are the tools we use for vibe coding? Well, let’s take the most popular choices and find out. A successful entry must interact with a contestant-controlled resource (e.g. web page, repository, media file) to exploit a vulnerability within the coding agent. The attack vector of the entry must be a common coding agent use case. There are few things out of scope here as well. UI spoofing or misrepresentation unrelated to permission prompts, model jailbreaks or prompt outputs that do not cross security boundaries, and vulnerabilities that require unsafe or permission-less modes are just a few of the things not allowed. As this is a new category, please read the rules carefully to ensure your entry qualifies. Here’s a look at the targets and awards in the AI Coding Agent category:

Back to top

The Local Inference Category

We couldn’t leave local inference and LLMs out of Pwn2Own. These products claim to provide enhanced data privacy, zero-cost inference, lower latency, and fully offline functionality. We’ll see how the security stacks up. An attempt in this category must be launched from the contestant’s laptop within the contest network. Here are the targets and payouts for the Local Inference category:

Back to top

The NVIDIA Category

Our last AI sub-category focuses solely on NVIDIA products. For network accessible targets, an attempt must be launched from the contestant's laptop within the contest network. For NV Container Toolkit, the attempt must be launched from within a crafted container image and execute arbitrary code on the host operating system. For Megatron Bridge, entries that leverage vulnerabilities pertaining to pickle deserialization or that leverage a vulnerability when “trust_remote_code=true” are out of scope. Here are the targets and payouts for the NVIDIA category:

Back to top

Conclusion

The complete rules for Pwn2Own Berlin 2026 are found here. As always, we highly encourage entrants to read the rules thoroughly if they choose to participate. If you are thinking about participating but have specific configuration or rule-related questions, email us. Questions asked over X (nee Twitter), BlueSky, or other means will not be answered. Registration is required to ensure we have sufficient resources on hand at the event. Please contact ZDI at pwn2own@trendmicro.com to begin the registration process. Registration for onsite participation closes at 5 p.m. Central European Time on May 7, 2026.

Be sure to stay tuned to this blog and follow us on Twitter, Mastodon, LinkedIn, or Bluesky for the latest information and updates about the contest. We look forward to seeing everyone in Germany, and we hope to see some of the best in the world show what they can do – vibe coded or not.

With special thanks to our Pwn2Own Berlin 2026 partners AWS, for providing their expertise and technology.

© 2026 Trend Micro Incorporated. All rights reserved. PWN2OWN, ZERO DAY INITIATIVE, ZDI, ZERO DAY INITIATIVE, TrendAI, and Trend Micro are trademarks or registered trademarks of Trend Micro Incorporated. All other trademarks and trade names are the property of their respective owners.

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.