Earlier today, we held the random draw to determine attempt order. Below is the official schedule. All times are Berlin local time (CET) and may change as the competition progresses. Check back for live updates.

In case you missed it, you can watch the draw here.

Jump to:

Day One

Day Two

Day Three

DAY ONE

Thursday, May 14 - 1030

chompie of IBM X-Force Offensive Research (XOR) targeting NV Container Toolkit in the NVIDIA category for a total of $50,000 and 5 Master of Pwn points

Le Duc Anh Vu ( @vulda ) of Viettel Cyber Security (@vcslab) targeting OpenAI Codex in the Coding Agent category for a total of $40,000 and 4 Master of Pwn points

Orange Tsai (@orange_8361) of DEVCORE Research Team (@d3vc0r3) targeting Microsoft Edge – Sandbox Escape in the Web Browser category for a total of $175,000 and 17.5 Master of Pwn points

Thursday, May 14 - 1130

k3vg3n targeting LiteLLM in the Local Inference category for a total of $40,000 and 4 Master of Pwn points

Satoki Tsuji (@satoki00) / Ikotas Labs, Inc. targeting Megatron Bridge in the NVIDIA category for a total of $20,000 and 2 Master of Pwn points

Thursday, May 14 - 1300

Angelboy (@scwuaptx) of DEVCORE Research Team and TwinkleStar03 (@_twinklestar03), working with DEVCORE Internship Program targeting Microsoft Windows 11 in the Local Escalation of Privilege category for a total of $30,000 and 3 Master of Pwn points

Emanuele Barbeno, Cyrill Bannwart, Yves Bieri, Lukasz D., Urs Mueller of Compass Security (@compasssecurity) targeting OpenAI Codex in the Coding Agent category for a total of $40,000 and 4 Master of Pwn points

Park Jae Min (@hiariz) targeting Oracle Autonomous AI Database in the AI Database category for a total of $40,000 and 4 Master of Pwn points

Thursday, May 14 - 1400

Satoki Tsuji (@satoki00) / Ikotas Labs, Inc. targeting LiteLLM in the Local Inference category for a total of $40,000 and 4 Master of Pwn points.

Yoseop kim(@pwning_me) targeting Megatron Bridge in the NVIDIA category for a total of $20,000 and 2 Master of Pwn points

Thursday, May 14 - 1500

Ben Koo (@kiddo_pwn) of Team DDOS targeting Mozilla Firefox – Renderer Only in the Web Browser category for a total of $50,000 and 5 Master of Pwn points

Interrupt Labs targeting NV Container Toolkit in the NVIDIA category for a total of $50,000 and 5 Master of Pwn points

Thursday, May 14 - 1530

maitai (@MaitaiThe) of Doyensec (@Doyensec) targeting OpenAI Codex in the Coding Agent category for a total of $40,000 and 4 Master of Pwn points

Thursday, May 14 - 1600

Billy (@st424204), Pan Zhenpeng(@Peterpan980927), Weiming Shi (@bestswngs) of STARLabs SG (@starlabs_sg) targeting LM Studio in the Local Inference category for a total of $40,000 and 4 Master of Pwn points

Marcin Wiązowski targeting Microsoft Windows 11 in the Local Escalation of Privilege category for a total of $30,000 and 3 Master of Pwn points

Thursday, May 14 - 1630

haehae (@haehaeYang) of Out Of Bounds targeting Chroma in the AI Database category for a total of $20,000 and 2 Master of Pwn points

Thursday, May 14 - 1730

chompie of IBM X-Force Offensive Research (XOR) targeting Red Hat Enterprise Linux for Workstations in the Local Escalation of Privilege category for a total of $20,000 and 2 Master of Pwn points

Yoseop Kim(@pwning_me) targeting Mozilla Firefox – Renderer Only in the Web Browser category for a total of $50,000 and 5 Master of Pwn points

Thursday, May 14 - 1800

@rewhiles of Viettel Cyber Security (@vcslab) targeting Anthropic Claude Code in the Coding Agent category for a total of $40,000 and 4 Master of Pwn points

Thursday, May 14 - 1830

Kentaro Kawane of GMO Cybersecurity by Ierae targeting Microsoft Windows 11 in the Local Escalation of Privilege category for a total of $30,000 and 3 Master of Pwn points

Qrious Secure (@qriousec) targeting LM Studio in the Local Inference category for a total of $40,000 and 4 Master of Pwn points

Thursday, May 14 - 1900

haehae (@haehaeYang) of Out of Bounds targeting Megatron Bridge in the NVIDIA category for a total of $20,000 and 2 Master of Pwn points

Back to top

DAY TWO

Friday, May 15 - 1030

Ben Koo (@kiddo_pwn) of Team DDOS targeting Red Hat Enterprise Linux for Workstations in the Local Escalation of Privilege category for a total of $20,000 and 2 Master of Pwn points

Stephen Fewer (Rapid7) targeting Microsoft SharePoint in the Server category for a total of $100,000 and 10 Master of Pwn points

Tao Yan (@Ga1ois) and Edouard Bochin (@le_douds) from Palo Alto Networks targeting Apple Safari – Renderer Only in the Web Browser category for a total of $75,000 and 7.5 Master of Pwn points

Friday, May 15 - 1130

Le Duc Anh Vu ( @vulda ) of Viettel Cyber Security (@vcslab) targeting Cursor in the Coding Agent category for a total of $30,000 and 3 Master of Pwn points

Nikolaos Mourousias (@deltaclock), Caue Obici (@caueobici) and Bruno Halltari (@BrunoModificato) of OtterSec targeting LM Studio in the Local Inference category for a total of $40,000 and 4 Master of Pwn points

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam). targeting Anthropic Claude Code in the Coding Agent category for a total of $40,000 and 4 Master of Pwn points

Friday, May 15 - 1300

Ruitong from the Abstract Team at the University of Colorado Boulder targeting Red Hat Enterprise Linux for Workstations in the Local Escalation of Privilege category for a total of $20,000 and 2 Master of Pwn points

Friday, May 15 - 1330

Kiyong Kwak of Kakaogames and Song Nuri of Samsung Electronics targeting Apple Safari – Renderer Only in the Web Browser category for a total of $75,000 and 7.5 Master of Pwn points

Orange Tsai (@orange_8361) of DEVCORE Research Team targeting Microsoft Exchange in the Server category for a total of $200,000 and 20 Master of Pwn points

Friday, May 15 - 1400

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam). targeting OpenAI Codex in the Coding Agent category for a total of $40,000 and 4 Master of Pwn points

Friday, May 15 - 1430

Billy (@st424204), Bruce Chen(@bruce30262), Pan Zhenpeng(@Peterpan980927), Weiming Shi (@bestswngs ) of STARLabs SG (@starlabs_sg) targeting Megatron Bridge in the NVIDIA category for a total of $20,000 and 2 Master of Pwn points

David Tae, Louis Hur of Out Of Bounds targeting Ollama in the Local Inference category for a total of $40,000 and 4 Master of Pwn points

Friday, May 15 - 1530

Team: Alon Ben Tsur (@iamgweej), Yahav Azran (@_yahav) targeting Red Hat Enterprise Linux for Workstations in the Local Escalation of Privilege category for a total of $20,000 and 2 Master of Pwn points

Friday, May 15 - 1600

@rewhiles of Viettel Cyber Security (@vcslab) targeting Mozilla Firefox – Renderer Only in the Web Browser category for a total of $50,000 and 5 Master of Pwn points

Siyeon Wi targeting Microsoft Windows 11 in the Local Escalation of Privilege category for a total of $30,000 and 3 Master of Pwn points

Friday, May 15 - 1630

Byung Young Yi (@yibarrack) of Out Of Bounds targeting LiteLLM in the Local Inference category for a total of $40,000 and 4 Master of Pwn points

Friday, May 15 - 1700

Emanuele Barbeno, Cyrill Bannwart, Yves Bieri, Lukasz D., Urs Mueller of Compass Security (@compasssecurity) targeting Cursor in the Coding Agent category for a total of $30,000 and 3 Master of Pwn points

Friday, May 15 - 1800

Daniel Cohen Hillel (@0xDACA) targeting NV Container Toolkit in the NVIDIA category for a total of $50,000 and 5 Master of Pwn points

Back to top

DAY THREE

Saturday, May 16 - 1100

Le Tran Hai Tung (@tacbliw), dungnm (@dungnm_) and hieuvd (@gr4ss341) of Viettel Cyber Security (@vcslab) targeting Microsoft Windows 11 in the Local Escalation of Privilege category for a total of $30,000 and 3 Master of Pwn points

Satoki Tsuji (@satoki00) / Ikotas Labs, Inc. targeting OpenAI Codex in the Coding Agent category for a total of $40,000 and 4 Master of Pwn points

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam). targeting Red Hat Enterprise Linux for Workstations in the Local Escalation of Privilege category for a total of $20,000 and 2 Master of Pwn points

Saturday, May 16 - 1330

Emanuele Barbeno, Cyrill Bannwart, Yves Bieri, Lukasz D., Urs Mueller of Compass Security (@compasssecurity) targeting Anthropic Claude Code in the Coding Agent category for a total of $40,000 and 4 Master of Pwn points

Hyunwoo Kim (@v4bel) targeting Red Hat Enterprise Linux for Workstations in the Local Escalation of Privilege category for a total of $20,000 and 2 Master of Pwn points

Team: Giuseppe Calì (@_gcali) of Summoning Team targeting VMware ESXi in the Virtualization category with the Cross-tenant Code Execution Addon add-on for a total of $200,000 and 20 Master of Pwn points

Saturday, May 16 - 1430

splitline (@_splitline_) of DEVCORE Research Team targeting Microsoft SharePoint in the Server category for a total of $100,000 and 10 Master of Pwn points

Saturday, May 16 - 1600

Byung Young Yi (@yibarrack) of Out Of Bounds targeting Anthropic Claude Code in the Coding Agent category for a total of $40,000 and 4 Master of Pwn points

Nguyen Hoang Thach (@hi_im_d4rkn3ss) of STARLabs SG (@starlabs_sg) targeting VMware ESXi in the Virtualization category with the Cross-tenant Code Execution Addon add-on for a total of $200,000 and 20 Master of Pwn points

Follow the action live! We’ll be posting real-time updates and results throughout the competition on our blog and across social media. Stay up to date by following us on Twitter, Mastodon, LinkedIn, and Bluesky, and join the conversation using #Pwn2Own Berlin and #P2OBerlin for continuous coverage. 

After Day One, we awarded $523,000 for 24 unique 0-days! DEVCORE is currently in the lead for Master of Pwn, but a pack of teams are right on their heels. Stay tuned tomorrow for more results and surprises.

Follow the action live! We’ll be posting real-time updates and results throughout the competition on our blog and across social media. Stay up to date by following us on Twitter, Mastodon, LinkedIn, and Bluesky, and join the conversation using #Pwn2Own Berlin and #P2OBerlin for continuous coverage. 

FAILURE - Unfortunately, Le Duc Anh Vu (@vulda17) of Viettel Cyber Security (@vcslab) could not get their exploit of OpenAI Codex working within the time allotted.

SUCCESS - Orange Tsai (@orange_8361) of DEVCORE Research Team (@d3vc0r3) chained 4 logic bugs to achieve a sandbox escape on Microsoft Edge, earning $175,000 and 17.5 Master of Pwn points.

SUCCESS - chompie of IBM X-Force Offensive Research (XOR) used a single bug to exploit NV Container Toolkit, earning $50,000 and 5 Master of Pwn points.

SUCCESS - k3vg3n chained 3 bugs including SSRF and Code Injection to take down LiteLLM. $40,000 and 4 Master of Pwn points. Full win.

SUCCESS - Satoki Tsuji (@satoki00) of Ikotas Labs, Inc. used an Overly Permissive Allowed List bug to exploit NVIDIA Megatron Bridge, earning $20,000 and 2 Master of Pwn points.

FAILURE - Unfortunately, Park Jae Min could not get their exploit of Oracle Autonomous AI Database working within the time allotted. #Pwn2Own #P2OBerlin

SUCCESS - Emanuele Barbeno, Cyrill Bannwart, Yves Bieri, Lukasz D., Urs Mueller of Compass Security (@compasssecurity) used a single CWE-150 bug to exploit OpenAI Codex, earning $40,000 and 4 Master of Pwn points.

SUCCESS - Angelboy (@scwuaptx) & TwinkleStar03 (@_twinklestar03) of DEVCORE Research Team used an Improper Access Control bug to escalate privileges on Microsoft Windows 11, earning $30,000 and 3 Master of Pwn points.

WITHDRAWAL - Ben Koo (@kiddo_pwn) of Team DDOS has withdrawn their entry for Mozilla Firefox – Renderer Only in the Web Browser category

FAILURE - Unfortunately, Interrupt Labs could not get their exploit of NV Container Toolkit working within the time allotted

COLLISON - Although successful on stage, the Ikotas Labs, Inc. team targeting LiteLLM in the Local Inference category used bugs that were previously known. They still earn $8,000 and 1.75 Master of Pwn points.

SUCCESS - Yoseop Kim (@pwning_me) used a CWE-470 bug to exploit NVIDIA Megatron Bridge in the second round, earning $10,000 and 2 Master of Pwn points.

COLLISON - Although successful on stage, maitai (@MaitaiThe) of Doyensec (@Doyensec) targeting OpenAI Codex in the Coding Agent category used a bug that was previously known to the vendor. They still earn $10,000 and 2 Master of Pwn points.

WITHDRAWAL - Yoseop Kim(@pwning_me) has withdrawn their entry for Mozilla Firefox – Renderer Only in the Web Browser category

SUCCESS - haehae (@haehaeYang) of Out Of Bounds chained 2 bugs (CWE-190, CWE-362) to exploit Chroma, earning $20,000 and 2 Master of Pwn points.

SUCCESS - Billy (@st424204), Pan Zhenpeng (@Peterpan980927) & Weiming Shi (@bestswngs) of STARLabs SG (@starlabs_sg) chained 5 bugs (incl. SSRF and Code Injection) to exploit LM Studio, earning $40,000 and 4 Master of Pwn points. Full win!

SUCCESS - Marcin Wiązowski used a heap-based buffer overflow to escalate privileges on Microsoft Windows 11 in the second round, earning $15,000 and 3 Master of Pwn points.

WITHDRAWAL - Qrious Secure (@qriousec) has withdrawn their entry for LM Studio in the Local Inference category.

SUCCESS - Chompie of IBM X-Force Offensive Research (XOR) used a race condition to escalate privileges on Red Hat Enterprise Linux for Workstations, earning $20,000 and 2 Master of Pwn points.

COLLISON - Although successful on stage, Nguyen Thanh Dat (@rewhiles) of Viettel Cyber Security (@vcslab) targeting Anthropic Claude Code in the Coding Agent category used a bug that was previously known to the vendor. They still earn $20,000 and 2 Master of Pwn points

SUCCESS - haehae (@haehaeYang) of Out Of Bounds used a Path Traversal bug to exploit NVIDIA Megatron Bridge in the second round, earning $10,000 and 2 Master of Pwn points. Full win!

SUCCESS - Kentaro Kawane of GMO Cybersecurity by Ierae chained 2 Use-After-Free bugs to escalate privileges on Microsoft Windows 11 in the third round, earning $15,000 and 3 Master of Pwn points.

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.

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

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

Optimize image loading

Detect and fix memory leaks with Android Studio

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

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

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

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

Trim memory when app leaves visible state

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

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

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

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

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

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

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

class MainActivity : AppCompatActivity(), ComponentCallbacks2 {

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

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

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

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

Advanced memory observability with ProfilingManager

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

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

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

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

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


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

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

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

Conclusion

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

Posted by Ben Weiss, Senior Developer Relations Engineer, Android Developer Relations

Welcome back to the blog post series "Build intelligent Android apps" where we take a basic Android app and transform it into a personalized, intelligent, and agentic experience. In our previous post, we explored how to leverage Firebase AI Logic to build cloud-hosted and hybrid AI features.

In this article, we'll show you how we designed and integrated these capabilities into our travel planning app, JetPacker, using Android AppFunctions. We'll explore the rationale behind our feature choices, discuss the specialized tooling we used to accelerate development, and dive into the code that makes it all work.

Designing AI-ready features: making choices that matter for your users

To select which features to provide to the intelligence system, we looked for tasks where a voice or text command is objectively faster than tapping through screens. In this side-by-side screen recording you can see this contrast perfectly: on the left, a user tapping through multiple screens to log an expense; on the right, the same task completed instantly in the background via a privileged agent.

Our first choice was expense tracking. Logging a coffee expense during a trip usually takes quite a few taps—unlocking the phone, opening the app, finding the active trip, navigating to the expenses tab, tapping the add button, taking a picture of the receipt, and checking the result. By providing the addExpense and getExpenses features as AppFunctions, the system agent handles the heavy lifting. When the user says, "Add a five-dollar coffee expense to my Paris trip," the agent automatically searches for the correct trip ID in the background and inserts the expense, skipping the manual UI flow entirely.

We also prioritized itinerary management. Finding what activity is next on a busy trip itinerary usually requires scrolling through a dense timeline view. By providing getItinerary and addItineraryEvent to the system, the user can simply ask, "What am I doing next in Paris?" and get an immediate answer.

Finally, we focused on hands-free note capturing. Typing out reminders or notes while walking down a busy street is difficult and unsafe. Exposing a voice note capability allows the user to say, "The flight was amazing, I saw a beautiful sunset and managed to sleep well," and the privileged agent automatically transcribes and saves it directly into the travel database  using the addVoiceNote AppFunction.

Android MCP powered by AppFunctions

This entire experience is built on Android MCP. Under this design, the app acts as a local MCP server. Rather than remote APIs, you provide your app features directly to the on-device intelligence system.

Android AppFunctions is the API that brings this concept to life. It reads annotated Kotlin functions and compiles them into type-safe, sandboxed tool definitions that the privileged agent can discover and invoke locally on the device.

Diagram highlighting our apps, the android platform, and system agents coordinate AppFunctions.

Under the Android MCP model, your app acts as a local MCP server that exposes structured tools, while the Android platform serves as the central tool registry. On the MCP client side, agent apps are registered with the intelligence system after being granted system-privileged permissions to access the registry.

When a user interacts with a registered agent, its LLM determines if the request can be handled by an AppFunction, queries the platform's metadata, and executes the appropriate registered functions in the background. This local MCP client-server design gives you full control: you choose exactly which features are accessible to the agent, keeping the rest of your app's data private.

How we accelerated development with Android skills

To streamline the integration process, we leveraged the AppFunctions development skill. The AppFunctions development skill is a complete development companion. It guided us through the entire lifecycle: mapping Kotlin data classes to serialize parameters, generating the necessary Service entry points, refining our KDoc documentation to ensure the LLM understands parameter boundaries, and setting up automated testing using ADB.

Providing app features to the intelligence system

Enough with the theory, let's dive into the implementation.

Configuration and dependency setup

We begin by adding the AppFunctions dependencies. One for the API and one for the Kotlin Symbol Processing compiler.

implementation("androidx.appfunctions:appfunctions:1.0.0-alpha10")
ksp("androidx.appfunctions:appfunctions-compiler:1.0.0-alpha10")

Modeling custom data types

Any custom object exchanged with the agent must be annotated with @AppFunctionSerializable. In our TripSerializable.kt file, we define our trip data model:

@AppFunctionSerializable(isDescribedByKDoc = true)
data class TripSerializable(
    /** The trip's unique identifier. */
    val id: String,
    /** The trip's title. */
    val title: String,
    /** The trip's destination location. */
    val location: String,
    /** The trip's start date in milliseconds. */
    val startDate: Long,
    /** The trip's end date in milliseconds. */
    val endDate: Long,
    /** A list of participants. */
    val participants: List<String>,
)

Providing features using the @AppFunction annotation

Next, the skill wrote the Kotlin functions that perform the database queries and annotate them with @AppFunction. We can view this in searchTrip:

/**
 * Looks for trips based on optional filters like id, title (name), location, and dates.
 *
 * @param id The unique identifier of the trip.
 * @param title The title or name of the trip.
 * @param location The destination location.
 * @param startDate The minimum start date in milliseconds.
 * @param endDate The maximum end date in milliseconds.
 * @return A list of trips matching the filters.
 */
@AppFunction(isDescribedByKDoc = true)
suspend fun searchTrip(
    id: String? = null,
    title: String? = null,
    location: String? = null,
    startDate: Long? = null,
    endDate: Long? = null
): List<TripSerializable> {
    return withContext(Dispatchers.IO) {
    // implementation
}

Since AppFunctions run on the UI thread by default, we use withContext(Dispatchers.IO) to switch to a background dispatcher. Additionally, we refine our KDoc to use clear, imperative verbs and specify parameter constraints. This documentation compiles directly into the tool's schema, which the privileged agent uses to resolve parameters and handle runtime errors.

The service entry point and Hilt integration

To register these features with the intelligence system, we create an abstract base class that extends AppFunctionService. We annotate it with @AppFunctionServiceEntryPoint:

@RequiresApi(36)
@AndroidEntryPoint
@AppFunctionServiceEntryPoint(
    serviceName = "JetPackerAppFunctionService",
    appFunctionXmlFileName = "jetpacker_app_function_service"
)
abstract class BaseJetPackerAppFunctionService : AppFunctionService() {
    @Inject internal lateinit var tripDao: TripDao
    // DAOs and database references are injected here...
}

During compilation, KSP generates the final concrete service subclass, JetPackerAppFunctionService, as declared with the serviceName parameter. We also register app_metadata.xml in the app's manifest. This file provides global operational rules for JetPacker's declared AppFunctions.

Testing and verifying your AppFunctions

Once implemented, you should verify that your AppFunctions are registered and working correctly.

Running devices or emulators with Android 17 or newer, you can use ADB commands from your terminal to list and invoke your functions. Running adb shell cmd app_function list-app-functions displays all registered functions for your package. You can then execute a specific function and test its database integration by running adb shell cmd app_function execute-app-function while passing a raw JSON parameters string.

Instead of these ADB commands, you can also use the AppFunctions Testing Agent to inspect your configuration, list and execute AppFunctions, and even see how your AppFunctions behave in a real conversational flow.

Wrapping it up

When thinking about app features that can be contributed to the intelligence system using AppFunctions requires a slight shift in how we think about code and documentation. AppFunctions enable you to use this new interaction model for apps, which allows using an agent to access app features..

First, the AppFunctions development skill is an essential lifecycle tool, helping you discover features, implement and refine AppFunctions for your apps. Second, KDoc comments are a compiled API asset; clear parameter descriptions directly impact the execution accuracy of the system agent. Finally, Android MCP provides local-first execution allowing apps to safely collaborate with AI agents.

Contributing app features through AppFunctions makes your application ready for the intelligence system. Let us know how you are adapting your apps for the agentic era!

Learn more

Check out the other parts of this blog post series:
Part 1: Introduction of the app and a high-level overview.
Part 2: On-device intelligence. Deep-dive into ML Kit’s GenAI APIs and Gemini Nano to build privacy-first features like itinerary summarization, receipt parsing, and local audio processing.
Part 3: Hybrid and cloud reasoning. Explore how to use Firebase AI Logic to ground LLM answers in real-world data like Google Maps and web context.
Part 4 (this post!): System integration. Integrating with the Android intelligence system using AppFunctions.
Part 5 (coming soon): In-app agentic workflows. Extend the app with an end-to-end booking assistant powered by A2UI and ADK.

Interested in more on Android Development? Follow Android Developers on YouTube or LinkedIn!

All code snippets in this blog post follow the following copyright notice:

Copyright 2026 Google LLC.
SPDX-License-Identifier: Apache-2.0

• James enabled adaptive autofill in Nightly for testing, which we believe should provide better results in the URL bar when doing autocomplete!
• Jack updated the illustrations shown on some of our error pages to match the latest approved designs, giving users more polished artwork when the browser encounters connection or security errors!

• Controls for the Memories feature can now be set during Smart Window onboarding

• We’ve disabled the CSS filter implicitly applied to WebExtension pageAction SVG icons across all release channels starting in Firefox 152, completing the deprecation
  • NOTE: The blog post published at WebExtensions API changes in Firefox 149-152 provides to extensions developers more details about this deprecation and links to the related MDN docs.

Friends of the Firefox team

Resolved bugs (excluding employees)

Script to find new contributors from bug list

Volunteers that fixed more than one bug

• Amin Amir
• Pranjali Srivastava
• Sam Johnson

New contributors (🌟 = first patch)

•  🌟:23rd: Regression: The new swipe-to-navigation indicator stucks for a moment, when deciding not to navigate the other page
• 🌟Akeem Omosanya: Remove commented-out code in SearchService.sys.mjs
• Amin Amir:
  • 🌟Fix browsingContext.sys.mjs to assign to #contextCreatedHandled instead of contextCreatedHandled
  • Fix missing WITHOUT ROWID SQLite performance optimization in SERPCategorization.sys.mjs
• 🌟Sahaj: Suggest the default target language for translation after changing the detected source language
• 🌟JIANG Zhirui: Breakpad build failed on Windows using VS2026 due to removal of stdext
•  John Iweh: Add “Open in New Tab” and “Open in New Container Tab” options to the context menu for Tabs from Other Devices
• Jak: Bookmarks and History – should respect the “When you open a link, image or media in a new tab, switch to it immediately” setting
• 🌟Andy [:rgbcmy]: Autoplayed next video should also be PIP
•  konyhéa: “Escape” key should collapse the expanded on hover sidebar launcher even if hover is still active.
•  Pranjali Srivastava:
  • Remove icon property from sidebar extensions
  • Show language-agnostic SelectTranslations context menu item when the source and target languages are the same

Project Updates

Add-ons / Web Extensions

Addon Manager & about:addons

• Fixed long-standing regression on the autocomplete and datalist popups for extension inline options pages on about:addons (introduced in Firefox 68 by Bug 1532724, fix shipping in Firefox 152) – Bug 1595158

WebExtensions Framework

• Fixed access to web-accessible resources declared with <all_urls> from sandboxed documents (null-principal URLs), restoring extension redirects from the context-menu search flow, starting in Firefox 152 – Bug 2033905

WebExtension APIs

• Added exhaustive test coverage for tabs.move() against additional edge cases related to split-view tabs – Bug 2029092

DevTools

• Andreas Farre improved the Session History tab in the Application panel (still behind devtools.application.sessionHistory.enabled)
  • added support for remote debugging (#2014064, #2016121)
  • made sure that calls to History.replaceState are reflected in the UI (#2037359)
• Julian Descottes [:jdescottes] fixed the most frequent DevTools crash we were observing in Telemetry, adding a guard against IDBTransaction errors when retrieving breakpoints in the Debugger (#2030260)
• Nicolas Chevobbe [:nchevobbe] fixed the image preview tooltip for relative URLs images in constructed stylesheet (#2035503)
• Julian Descottes [:jdescottes] reduced the overhead we had because of network requests monitoring by only decoding response content when the user actually want to see the response (#2026228)

WebDriver

• Amin Amir cleaned up an incorrect variable assignment in our browsingContext module.
• Logan Rosen updated stale references and broken links in our documentation about Marionette.
• Sameem improved the Marionette and WebDriver BiDi screenshot commands to enforce maximum allowed dimensions.
• Leo McArdle fixed the regression in the “log.entryAdded” event, which lacked an error message in the “text” field for the messages of type “error”.
• Henrik Skupin fixed an issue in Marionette where WebDriver:Navigate and WebDriver:Refresh did not handle errors when the underlying navigation failed.
• Henrik Skupin improved geckodriver to detect an early Firefox exit during startup on Android, avoiding up to 60 seconds of unnecessary connection attempts.
• Henrik Skupin updated the geckodriver CI build job to produce a universal macOS binary supporting both x64 and aarch64.

Lint, Docs and Workflow

• Sylvestre ported some linters (e.g. file-whitespace, test-manifest-toml, license, file-perm, rejected-words & more) to Rust to help improve the runtime of the code review bot.
• Dale has been working on migration to moz-src for customkeys, dom/quota and odom/geolocation
  • https://arewemozsrcyet.com/

New Tab Page

• We did our first region-specific trainhop on May 11th (just 15% of the US), and turned on HNT Nova (and sometimes Widgets) for those clients to get some advance-data of its behaviour in the wild! A note that HNT Nova gets turned on for everybody when Firefox 151 ships on May 19th.
  • We’ll be launching a similar experiment in the DE, probably on May 12th, also at 15% population.
• Most of the team is heads down building out a sports-tracking widget, attempting to get that ready in time to be generally available for the upcoming World Cup event.
• Dre landed a new world clock widget, which is currently off by default, but pretty snazzy!

Search and Urlbar

• Nova (URL Bar Design Refresh)
  • Drew and Daisuke continued their work on Nova styling for the Address bar (input and view).
• Search and Suggest
  • Drew finalized two bugs for World Cup and sports suggestions, which were landed and uplifted: one to update the localization string for scheduled games and another to show both teams’ icons in suggestions. Drew also landed and uplifted a fix for rich search suggestion icons being forced into a square aspect ratio.
  • Standard8 updated Ecosia favicons to the latest branding, including QA testing and publishing.
• Settings Redesign (SRD)
  • Stephanie landed a test to ensure search suggestion settings are hidden when quicksuggest is disabled, as well as a patch to resolve TypeScript issues in search.mjs, and is adding test coverage to confirm removed search engines are not displayed in the default engines dropdown.
• General URL Bar and Component Updates
  • Daisuke landed implementation of the context menu on URL bar results, and a fix to show the loading URL in the URL bar when starting up with a homepage.
    • Marco is working on several tasks, including a PDF download / focus stealing issue and allowing arrays to be bound in Sqlite.sys.mjs. Marco also worked on fixes related to Places, such as avoiding replacing the favicons database if it is not corrupt.
  • Standard8 finalized the URL bar test manifest split. Standard8 also upgraded us to TypeScript 6.
  • Moritz landed a fix for URL bar abandonment telemetry being recorded when clicking an engine in the unified search button popup (Bug 2032973), which was also uplifted. Moritz also simplified search mode switcher item activation in tests, and made it so that the unified search button popup closes when installing an open search engine.

Smart Window

• natural language starting with tab close/undo 2035343 with expandable action log 2031508

• assistant rendering feedback up/down 2032994 and markdown table 2027029
• nova styling blur 2027877 and suggestions 2026823
• accessibility screen reader 2028676 and keyboard focus 2037565
• optimize conversation starters extra requests 2030005 and caching 2033430

Storybook/Reusable Components/Acorn Design System

• Nova token updates occasionally, focused on SRD

UX Fundamentals

• Added support for the “SEC_ERROR_CA_CERT_INVALID” certificate error to the Felt Privacy error pages. – 2035942

Settings Redesign

• Settings redesign is being tested and will hopefully go out in Firefox 152!

• Maxx Crawford added a pref to hide the New Tab logo so users can opt out of branding without altering page layout or resorting to CSS overrides.
• Harshit enabled video overlay detection in Nightly 153, allowing you to use the context menu to control videos on more pages! We plan on letting this ride out in Firefox 153.
  • You can try it out on this Instagram reel in Nightly

• A note to WebExtension authors – as part of a planned deprecation announced last month, executeScript and insertCSS are now restricted from moz-extension pages starting in Firefox 152 – Bug 2015559
• Nicolas Chevobbe [:nchevobbe] added support and debugging for modern attr()(which is enabled on Nightly) (#2014751)

Friends of the Firefox team

Resolved bugs (excluding employees)

Script to find new contributors from bug list

Volunteers that fixed more than one bug

• Sam Johnson
• Sebastian Zartner [:sebo]

New contributors (🌟 = first patch)

• Immaculate Atim: Switch to using an array instead of an object string for browser.backup.enabled_on.profiles
• liz: Screenshots overlay visible on both splitview browsers
• 🌟 Rahman Mahmutović [:r_m]: Can’t change content in box model in inspector for box-sizing:border-box elements
• Takeru Mitsumori: Fix typo in ID name about-translations-swap-langauges-icon in about-translations.html
• 🌟 Freya Arbjerg [:freyacodes]: Blackboxed columns are ignored
•  tom.passarelli: tab-preview-panel emits unpaired popupshown/popuphidden events, breaking sidebar autohide

Project Updates

Add-ons / Web Extensions

Addon Manager & about:addons

• As part of the work for the Project Nova about:addons page restyling, the about:addons sidebar has been migrated to the moz-page-nav and moz-page-nav-button reusable components, improving accessibility and visual consistency with the Firefox Desktop about:settings page – Bug 1881767

WebExtensions Framework

• Implemented WebExtensions negative permissions infrastructure, providing the foundations for enterprise policy “blocked host permissions” features – Bug 1745823
• Restricted host permission changes for MV3 extensions force-installed via enterprise policy (matching similar behaviors provided by Chrome enterprise policy behaviors) – Bug 1904054
  • Thanks to Mike Kaply for the implementation of this enterprise policy enforcement feature.

WebExtension APIs

• Fixed handling of <all_urls> as an API permission in Manifest V3, ensuring the permission is correctly initialized on extension install – Bug 1758306

DevTools

• Rahman Mahmutović [:r_m] made it possible to edit width/height in the box model section of the Layout panel (#1717176)
• Sebastian Zartner [:sebo] improved toggling tools driving in-page highlighters (e.g. the Measuring) (#1262773)
• Sebastian Zartner [:sebo] added a setting to control visibility of HTML comments in the markup view (#1455294)
• Freya Arbjerg [:freyacodes] fixed an issue in script blackboxing (#2036767)
• Alexandre Poirot [:ochameau] replaced custom preference to log RDP messages with MOZ_LOG (#1622857)
• Alexandre Poirot [:ochameau] fixed retrieval of garbage collected script text content (#1758454)

WebDriver

• Sameem updated the “Take Element Screenshot” command from WebDriver Classic to crop screenshots of elements which exceed the viewport. This aligns with the specification and avoids errors when attempting to capture huge elements.
• Alexandra Borovova updated the events for new top-level browsing contexts: we will not send anymore “browsingContext.domContentLoaded” and “browsingContext.load” events for them, instead the “browsingContext.contextCreated” event will be sent when a tab is ready to be used. This is required to align with the expected per-spec behavior.
• Henrik Skupin landed a patch allowing geckodriver to gracefully shut down Firefox when geckodriver itself is terminated.
• Hiroyuki Ikezoe disabled Firefox’s “scroll axis lock” feature so WebDriver actions for wheel input devices can scroll in arbitrary directions when using pan gestures.

Lint, Docs and Workflow

• Added a rule to prevent new uses of Preferences.sys.mjs.
• The browser environment globals within ESLint have now been updated. These include Sanitizer, VideoFrame and a few other new ones.
• Temporal, and some other definitions have been added to TypeScript.

New Tab Page

• Much has happened in the last 2 weeks! Here’s a full bug list, and here are some highlights.
• Dre fixed the List widget that was creating a new list too eagerly on the New Tab Page (2033592) — prevents accidental list creation and improves the Lists UI reliability.
• Maxx Crawford fixed Weather widget small card layout issues with opt-in location options and an error message displayed, resolving card overflow and removing the spurious opt-in error so users see a compact Weather card and correct location prompts on New Tab.
• Reem Hamoui added key dates state to the Sports widget, enabling the Sports card to surface event deadlines/key-date highlights on New Tab so sports users see timely date info.
• Scott Downe added a manage widgets option to the New Tab nova widgets context menu, giving users a direct context-menu entry to open the widget management flow from any widget with Nova enabled.
• Scott Downe added a reusable Newtab widget base component to centralize lifecycle, focus/keyboard handling, DOM templates, and telemetry hooks, reducing duplication and making widget behavior more consistent; see Newtab widget base component.
• Dre converted per-widget expansion handling to a shared widget expansion handler to unify expand/collapse state management and prevent widgets from incorrectly retaining or losing expanded state; see Convert widget expansion handling to shared widget expansion.
• Nina Pypchenko [:nina-py] updated the Sports widget to populate the “follow teams” state from the /teams endpoint, so follow/unfollow toggles now reflect server-side subscriptions and reduce incorrect follow states.
• Scott Downe moved widget menu items within New Tab widgets to standardize menu ordering and action grouping, so users find Add/Remove/Configure entries in expected positions across platforms.
• Dre fixed a World Clock city search bug for the word clocks widget, restoring expected search filtering/matching so city lookups return correct results.
• Scott Downe fixed an issue where the New Tab small weather widget size change didn’t always apply by correcting the widget size update path (JS/CSS layout interactions), improving consistent rendering for small-tile weather across responsive breakpoints and platforms; see Newtab small weather widget size change doesn’t always work.
• Nina Pypchenko [:nina-py] added a group stage section to match highlights in the sports widget on New Tab so users now see stage-aware grouping and stage labels on match highlight cards, making tournament context (group vs knockout) visible while browsing highlights.
• Dre fixed the small world clock widget not expanding to large while editing clocks so users can enter edit mode and expand the widget as expected; the change wires the edit-mode resize handler to update widget size/class during edits.
• Maxx Crawford added WCW OMC message strings so World Cup widget messaging flows on New Tab now display the correct copy (localized where available) instead of falling back to missing-text behavior.
• Reem Hamoui added a “View all” button and a list view for the results tab at medium widget size so Sports widget users on medium New Tab tiles can expand results and scroll full lists without resizing the widget.
• Maxx Crawford added WCW “Watch Live” stream strings to the Sports widget strings bundle so the widget can surface a localized “Watch Live” CTA for applicable events.
• Dre restored VoiceOver reachability for Edit/Remove in World Clock on macOS so macOS VoiceOver users can now focus and activate clock Edit/Remove controls thanks to accessibility role/label and focus-order fixes.
• Maxx Crawford removed the persistent browser logo when all new-tab features (Top Sites, widgets, content feed) are disabled by adding a conditional render guard in the New Tab component, preventing an orphaned logo (2041033).
• Mike Conley added New Tab jest tests to the node tests Tier 1 CI job Run newtab jest tests as part of node tests Tier 1 job to catch regressions earlier in CI
• Irene Ni shipped multiple visual fixes for the Sports widget Sports widget – various visual fixes (spacing, truncation, icon alignment, clipping) to improve readability and layout on constrained viewports.

Picture-in-Picture

• kpatenio adjusted our YouTube site specific wrapper so that the URL bar toggle appears more reliably, especially when selecting videos from the YouTube search page.
• Thanks to Sylvestre for patching some bugs to prevent some spurious console errors!
• Niklas fixed captions on autopip videos failing to sync with the origin videos.

Performance Tools (aka Firefox Profiler)

• Firefox Profiler now has a CLI! We also added a profiler-analysis skill to the Firefox codebase. Once you capture a performance profile, you can ask Claude or an AI to analyze it by providing a link or local path. You can use it to analyze a performance regression or debug an issue if you have a profile at hand.
  • https://www.npmjs.com/package/@firefox-devtools/profiler-cli
  • You can install it with npm install -g @firefox-devtools/profiler-cli@latest

Search and Urlbar

Nova UI refresh

• Drew and Daisuke continued working on reorganizing styles and updating the urlbar for Nova.
• 2019154, 2019152, 2041501, 2040532

Suggest

• Drew landed several Suggest improvements: realtime suggestions colors, sports suggestions received World Cup tweaks, and online Suggest via OHTTP was enabled for eligible users in Firefox 153.
• 2040561, 2039753, 2035614, 2038843

Adaptive autofill

• James fixed soft-block counting to track autofill dismisses, rather than consecutive backspaces on the same autofill, and added telemetry to measure URLs reintegration after blocking.
• 2040819, 2037177

Quick actions

• Dharma created a new Firefox Labs quick action, fixed the Update action button, and re-enabled ScotchBonnet in some tests that were not updated yet.
• Caleb added Calculator support for certain unicode operators.
• 2023169, 1928635, 1923383, 2033861

Multi Context Address Bar

• Moritz continued refactoring the urlbar code: converted some of the js modules to not be system modules, fixed dynamic results templates, incorrect reuse of result rows, and keyboard shortcuts on the unified search button panel.
• 2039297, 2036095, 2039844, 2037933, 2030050

Other

• Marco, Drew and Daisuke fixed several intermittent test failures.
• 2038510, 2023908, 2011584, 1938142, 1971091

Search

• Mark removed old WebExtension-based search engines from the source tree, removed loading of search add-ons from resource://search-extensions/.
• Caleb fixed multiple documentation issues and added a test covering searches from a private window.
• 1904613, 2035878, 2037942, 2033545, 2005724

Places

• Marco removed some unnecessary database transactions, fixed the bookmarks panel folder dropdown on Windows, and resolved several intermittent test failures.
• Thanks to Sam Johnson who fixed the bookmark edit panel showing “mobile” instead of “Mobile Bookmarks”.
• 2039534, 1505800, 2008829, 2029541, 2035084

Source Code Viewer

Crate pages now have a "Code" tab that lets you browse the contents of published crate versions directly on crates.io. This shows you the exact files that cargo downloads when you add a crate as a dependency, which might differ from the linked repository. This makes it much easier to audit your dependencies, including files that never appear in the repository, like the normalized Cargo.toml files that cargo generates.

The viewer comes with a file tree sidebar with search functionality, syntax highlighting, and GitHub-style line selection, where clicking or dragging line numbers produces shareable #L10-L20 URLs.

Under the hood, the server now builds a zip file for every published version. Since the .crate files that cargo consumes are gzipped tarballs without random access support, a background job re-packs each of them into a seekable zip archive plus a JSON manifest describing the contained files. Both are served from our static CDN. The frontend then fetches only the manifest and loads each file on demand with an HTTP range request. Because of this architecture, browsing crate sources essentially adds no load on the crates.io API servers. Existing crate versions have been backfilled, so this works for old releases too.

The rendering library behind the code viewer is a diff renderer at heart, and that's no accident: a version-to-version diff viewer built on the same infrastructure is currently in the works. This will allow you to review exactly what changed between two published versions, right on crates.io. Stay tuned!

Untangling crates.io Accounts from GitHub

At the end of May, the crates.io team accepted RFC #3946. Crates.io accounts always have been tightly coupled to GitHub: signing in means "Log in with GitHub", and your crates.io identity is your GitHub username. The RFC changes that. It introduces usernames that are native to crates.io and independent of linked GitHub accounts, as a prerequisite for eventually supporting login via other identity providers.

The implementation of crates.io usernames has started, but there is still a lot left to do, most visibly the ability to change your crates.io username. After that is complete, there will be future RFCs and implementation for signing in with identity providers other than GitHub. Since all of this touches authentication and account security, we are deliberately taking it slow and rolling these changes out in small, carefully reviewed steps.

Advisories and Suggestions

In our January update we introduced the "Security" tab, which shows security advisories from the RustSec database. We have since taken this integration one step further: crates that RustSec has flagged as unmaintained now show a warning banner directly on their crate pages, linking to the corresponding advisory for details and possible alternatives. Thanks to Dirkjan Ochtman for implementing this feature!

Related to this, some popular crates have been largely absorbed into the Rust standard library over the years, like lazy_static, which has been superseded by std::sync::LazyLock since Rust 1.80. Crate pages of such crates now show a friendly "You might not need this dependency" banner describing the standard library replacement, and superseded crates in dependency lists get a small light bulb icon with a similar hint.

The dataset behind this feature lives in the new rust-lang/std-replacement-data repository, together with a documented inclusion policy: standard library replacements only, every entry must cite the stable std, core, or alloc API and Rust version, and crate maintainers get a notice-and-comment window before an entry is added. New entries can be proposed upstream and can benefit other tools too.

Ferris

The most delightful change of this cycle: the Ferris on our error pages now follows your mouse cursor with its eyes:

Getting a 404 error on crates.io is now slightly less sad.

Svelte Frontend Migration Completed

In our January update, we announced that we were experimenting with porting the crates.io frontend from Ember.js to Svelte. This experiment has concluded successfully: the new frontend reached feature parity, went through a public testing phase in April, became the default at the beginning of May, and the Ember.js app has been removed from our repository.

We designed this change to be invisible for our users, since the new frontend is a 1:1 port of the previous design and functionality. For the team and our contributors, however, it is a big deal: the frontend is now built on a more modern framework, which should make it easier for new contributors to get started. It also allows us to iterate faster, as the source code viewer above demonstrates.

We want to thank the Ember.js team for a framework that served crates.io well for many years, and the Svelte team for making the transition so enjoyable.

Miscellaneous

These were some of the more visible changes to crates.io over the past six months, but a lot has happened "under the hood" as well:

• Search performance: Relevance-sorted search queries previously ranked every crate matching the query, which could take 1-2 seconds for short or common search terms. Ranking is now bounded to the 1,000 matching crates with the highest recent download counts.

• Reverse dependencies performance: The reverse dependencies endpoint no longer recomputes the full dependent set on every request. It is now served from a precomputed table kept in sync by database triggers, turning an expensive join into a bounded index scan and greatly reducing the chance of getting a timeout error.

• New ARCHITECTURE.md: If you've ever wondered how crates.io actually works, our ARCHITECTURE.md document got a complete rewrite. It is now organized around the high-level systems that make up crates.io and how they fit together, and includes walkthroughs of what happens when you run cargo publish, why a typical crate download never touches our API servers, and how download counts are derived from CDN access logs.

• Definition lists: READMEs now render Markdown definition lists, a widely used Markdown extension. Our markdown renderer comrak already supported them, the extension just wasn't enabled yet. Thanks to @mistaste for this contribution!

• CDN cache tags: Files uploaded to our static CDN now carry cache-tag metadata, allowing us to invalidate all cached files of a crate or a specific release in a single operation, instead of issuing one invalidation per file URL.

• Caching improvements: We removed a global Vary: Cookie response header that was preventing our CDNs from caching public API responses and frontend assets effectively. Per-user responses now use Cache-Control: no-store instead, resulting in better cache hit rates at the CDN edge.

• Accessibility: We have made crates.io friendlier to screen readers: decorative icons are now hidden from the accessibility tree, heading hierarchies have been fixed, and lists are marked up as proper lists. ARIA snapshot tests now ensure that regressions can't slip in unnoticed. We plan to continue to improve crates.io accessibility over the coming months.

• Git index performance: The background worker's local clone of the git index is now a bare and shallow repository, eliminating roughly 250,000 checked-out files and the full commit history from its disk, improving its performance as we see increased rates of crate publication. The periodic index squashing now goes through the GitHub API instead of generating large git packs locally, which had previously caused out-of-memory failures on the production worker.

Feedback

We hope you enjoyed this update on the development of crates.io. If you have any feedback or questions, please let us know on Zulip or GitHub. We are always happy to hear from you and are looking forward to your feedback!

OpenAI has revealed that an autonomous AI agent powered by its technology went rogue during a test, accessed the open web and hacked a prominent startup by itself in an “unprecedented incident”.

The company behind ChatGPT said the startup Hugging Face had detected and contained the agent – an AI tool designed to carry out tasks without human assistance – which had entered its systems.

The post How Apple TV became an awards magnet appeared first on MacDailyNews.

Providing a public, open way to browse the anonymous, aggregated device data we collect was always part of the plan, and this preview is our first step toward it.

You can already use it to search and filter devices to see aggregated community insights, starting with a deliberately focused set of specifics, such as whether a device requires an internet connection, and which protocols and integrations it works with. We've kept that initial scope narrow on purpose, giving us a solid foundation we can build on together with you, our community, as the database grows.

LWN looked at Home Assistant in May 2025.

KARR Security System Vulnerability Affects Dealer-installed Hardware 

iPhone App Update Fixes KARR Alarm Flaw 

Hidden KARR Security System Complicates Updates 

Shared Bluetooth Key Exposes KARR Alarm Devices

Privacy Concerns and Recommended Action

Read more →

The post Hackers Allegedly Claim Breach of Decathlon Customer Database With 160 Million Records appeared first on IT Security News.

Read more →

The post IT Security News Hourly Summary 2026-07-24 06h : 1 posts appeared first on IT Security News.

The post Hackers Allegedly Claim Breach of Decathlon Customer Database With 160 Million Records appeared first on Cyber Security News.

Read more →

The post Wordfence Intelligence Weekly WordPress Vulnerability Report (July 13, 2026 to July 19, 2026) appeared first on IT Security News.

This wave of VentureBeat Pulse Research examines the enterprise RAG and context layer: what feeds AI agents their business context, which retrieval systems enterprises run, how they buy and measure them, where the architecture is heading, and — most revealingly — how often that context is already failing them.

The central finding is a context gap — the distance between how confidently enterprise agents answer and how reliable the context beneath them actually is. A majority of enterprises (57%) report that in the past six months their AI agents produced confident but wrong answers they traced to missing or inconsistent business context, and more than half of those said it happened more than once. This is not a fringe failure: retrieval is the primary context source for 38% of enterprises, more than any other approach, so when retrieval is thin or inconsistent, the errors it produces are wearing the agent’s authority. The infrastructure to fix it is being built — 58% already run or are building a governed semantic layer — but for most it is not yet in production.

Underneath, the market is consolidating in a direction that surprises. Provider-native retrieval — OpenAI’s file search (40%) and Google’s Vertex AI Search (38%) — already leads every dedicated vector database, and enterprises expect hybrid retrieval to dominate by the end of 2026 (34%). Yet a plurality (36%) say they intend to keep best-of-breed standalone tools rather than consolidate onto a provider’s native context stack, and a majority (57%) plan to switch or add a provider within the year. Stated preference and actual usage are pulling in opposite directions — the market is buying provider-native while insisting it wants independence.

Methodology

VentureBeat fielded this survey as part of its ongoing Pulse Research series. This survey focused on enterprise RAG infrastructure and the context layer — the retrieval systems, semantic layers, and context sources that feed AI agents. Responses are filtered to organizations with more than 100 employees (n=101); the survey drew no responses from organizations of 100 or fewer, so the full sample qualifies. All responses are from a single Q2 2026 (June) wave, so the report reads cross-sectionally and does not infer month-over-month trends. Several questions were multiple-select, so those shares can sum to more than 100%.

By organization size the sample concentrates in the mid-market: 251–1,000 employees (31%) and 101–250 (31%) lead, with 1,001–5,000 (20%), 5,001–10,000 (12%), and 10,001+ (7%) above them. By role it spans managers (39%), individual contributors (27%), the C-suite (16%), and VPs and directors (14%); on purchasing authority it is buyer-credible, with 46% final decision-makers and another 26% recommenders or influencers. Technology/Software is the largest industry at 20%, followed by Healthcare/Life Sciences (11%) and a broad spread across retail, transportation, financial services, manufacturing, and education.

At 101 respondents this is a modest sample and should be read as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. It is best read as the view from organizations actively standing up RAG and context infrastructure rather than from the largest operators.

Finding 1: Confident and wrong

More than half have traced agent errors to bad context

We asked whether, in the past six months, enterprises had traced a confident but wrong agent answer to missing or inconsistent business context. Most had.

This is the report’s defining number. A majority of enterprises (57%) have already had an AI agent produce a confident, wrong answer they traced to bad context — wrong metrics, stale definitions, or missing documents — and more than half of those have seen it happen more than once. Only 28% report no such failure, and a small remainder either don’t run agents on enterprise data or don’t trace root cause closely enough to know.

The failure mode is specific and dangerous: the model is not obviously hallucinating; it is confidently wrong because the context feeding it was thin or inconsistent. Everything else in this report — what enterprises retrieve, how they govern it, and what they plan to build — is downstream of this problem.

Finding 2: RAG is the default context source

Retrieval feeds more agents than any other method

We asked what an enterprise’s AI agents primarily use to understand its data. Retrieval leads by a wide margin.

Retrieval is the backbone of enterprise context. For 38% of organizations, RAG over documents or a vector index is the primary way agents understand the business — nearly twice the share of the next approach, a governed semantic layer or ontology (21%). Mixed approaches (14%), direct live-system queries (10%), and long-context loading (6%) fill out the rest, and only 2% let agents run on the model’s general knowledge alone. The concentration matters in light of Finding 1: because so much enterprise context flows through retrieval, the quality of that retrieval is the quality of the answer. When RAG is the default source, thin retrieval is not an edge case — it is the main failure surface.

One approach is notable for its absence from these answers: customizing model weights, also known as fine-tuning. Every leading source of business context is injected at run time. Our most recent direct measurement of fine-tuning comes from our April–May survey wave (a separate survey, n=136), where fine-tuning capabilities ranked last of six factors in model selection at 5% — even as 26% of that sample still named fine-tuning and customization an investment they expect to grow. Fine-tuning has fallen out of the primary selection conversation; context injection is how enterprises make agents knowledgeable about their business.

Finding 3: Provider-native retrieval already leads the vector databases

OpenAI file search and vertex AI search top the dedicated tools

We asked which retrieval systems enterprises run in production today. The answer favors the model providers and hyperscalers over the specialists.

The dedicated vector database is no longer the center of the RAG stack. OpenAI’s file search (40%) and Google’s Vertex AI Search (38%) lead — provider-native and hyperscaler-native retrieval — ahead of every purpose-built vector database. Among the specialists, the most-used is the one enterprises already run for other reasons (Elasticsearch/OpenSearch, 20%) and the open, embedded option (pgvector, 12%); the pure-play vector databases that define the category — Weaviate, Qdrant, Pinecone, Milvus — each sit in single digits to low double digits. Notably, 13% of enterprises say they still run no production RAG at all. As with the platforms in the parallel infrastructure wave, enterprises are gravitating to retrieval that comes bundled with tools they already buy.

The shape of this finding held across both Q2 waves. In April–May (n=161), provider-built retrieval led usage there too, while every dedicated vector database remained marginal — the most-used standalone vector database peaked at 8% of that sample — and the hybrid, pluralistic future was already the consensus expectation (34% expected hybrid retrieval to dominate, with another 29% expecting multiple architectures by use case). Two waves, consistent picture: the category that coined the “vector database” term is being collected by the platforms enterprises already buy from.

Finding 4: But they say they want to keep best-of-breed

A plurality resist consolidating onto a provider’s native stack

We asked how enterprises will respond as model providers bundle retrieval, memory, and orchestration into their platforms. Their stated intent cuts against their current usage.

Here is the tension at the heart of the stack. Even as provider-native retrieval leads in practice (Finding 3), a plurality of enterprises (36%) say they intend to keep best-of-breed standalone tools rather than consolidate onto a provider’s native context stack — well ahead of the 21% who plan to consolidate. Another 21% expect a mix, and 9% intend to build and own the layer themselves. The gap between what enterprises run and what they say they want is the strategic question of the category: they are adopting bundled retrieval for convenience while asserting they will preserve independence. Which impulse wins — the pull of the provider bundle or the stated preference for modular control — will shape the retrieval market more than any single tool.

Finding 5: Hybrid retrieval is the consensus bet

Vector-only retrieval is already seen as insufficient

We asked which retrieval architecture enterprises expect to dominate their production RAG systems by the end of 2026. The field is converging — with a large share still unsure.

The architecture is settling on hybrid. A third (34%) expect hybrid retrieval — embeddings combined with reranking and access controls — to dominate their production systems by the end of 2026, three times the 11% who expect vector-only retrieval to prevail. That is a notable signal: the pure vector-search approach that launched the category is already viewed as insufficient on its own, superseded by pipelines that add reranking for accuracy and access controls for governance — the very access controls whose absence produces the failures in Finding 1. Tellingly, the second-largest answer is uncertainty: 17% simply don’t know, and another 14% expect to move beyond a dedicated vector layer entirely toward tool-first or long-context retrieval. The consensus is not a single tool but a layered pipeline — and it is not yet fully formed.

Finding 6: The governed context layer is being built now

Most run or are building a semantic layer — few in production

We asked whether enterprises use a governed semantic or context layer to give agents and BI a shared understanding of their data. Most are on the path; fewer have arrived.

The fix for the context gap is under construction. Well over half of enterprises (58%) either run a governed semantic layer in production (25%) or are piloting and building one (34%), and a further 17% are actively evaluating — meaning three-quarters are engaged with the idea in some form. But the balance is telling: more are building than have shipped, so for most enterprises the shared, governed definition layer that would prevent the "confident but wrong" failures of Finding 1 is still a work in progress. The semantic layer is the industry’s answer to inconsistent context; this wave catches it mid-construction, ambition well ahead of production.

Finding 7: Bought on ingestion and simplicity, watched for correctness

Selection favors operability; monitoring favors correctness and security

We asked what matters most when enterprises choose a retrieval system, and what they track once it is running. Both answers lean practical.

Enterprises choose retrieval systems on operability. Ease of data ingestion (36%), latency and performance (32%), and operational simplicity (29%) lead the selection criteria — ahead of retrieval accuracy and access control (23% each), the two factors most directly tied to the failures in Finding 1. Once systems are running, the emphasis shifts toward trust: the most-tracked metrics are response correctness (42%) and security and access control (38%), ahead of latency (28%), operational stability (27%), and answer relevance (23%).

Satisfaction with current systems is moderately positive but not enthusiastic — on a five-point scale, overall satisfaction averages 4.0, with ease of implementation and value for money both near 3.9. Enterprises buy for how easily a system runs and watch it for whether it can be trusted.

Finding 8: A retrieval reshuffle is coming

A majority plan to change providers — and the vector specialists are gaining interest

We asked whether enterprises plan to change or add a retrieval provider, and which they are considering. The consideration set differs from today’s stack.

The retrieval stack is not settled. While 43% have no plans to change, a small majority (57%) intend to switch or add a provider within twelve months, and a quarter (26%) within the next quarter. The consideration set is where it gets interesting: provider-native retrieval still leads what enterprises are evaluating (OpenAI 22%, Vertex AI Search 21%), but the open-source vector specialists punch above their current footprint — Qdrant (14%) and Milvus (13%) draw more switching interest than their present usage (10% and 6%) would suggest. Read with Finding 4, the picture is a market in flux: enterprises run provider-native today, are evaluating a broader field, and say they want to keep their options open. The reshuffle ahead will test whether best-of-breed intent survives contact with the convenience of the bundle.

The bottom line: A context gap that more retrieval alone won’t close

Organizations with more than 100 employees are wiring agents into their business faster than they can guarantee the context those agents run on. Retrieval is the default source of enterprise context, and it increasingly comes from the model providers and hyperscalers rather than the dedicated vector databases — yet a majority of enterprises have already watched agents answer confidently and wrongly because that context was thin or inconsistent. The failure is not exotic; it is the predictable result of pointing authoritative-sounding agents at an unreliable foundation.

The industry’s answer — a governed semantic layer, hybrid retrieval with reranking and access controls — is being built but is mostly not yet in production, and enterprises are pulled between the convenience of provider-native bundles and a stated preference for best-of-breed independence. At 101 respondents in a single Q2 wave this is a directional read, skewed toward the mid-market — but the direction is clear: the context layer is the next contested tier of the AI stack, and right now agents are running ahead of it. The context gap is not a retrieval-volume problem that more documents or bigger indexes will solve on their own; it is a problem of governed, consistent, access-aware context. The open question for later waves is whether enterprises finish building that layer before the confident-but-wrong failures move from the lab into decisions that matter.

Based on survey responses from 101 qualified enterprise respondents (100+ employees), drawn from a single Q2 2026 (June) wave. At this sample size the results should be read as a directional signal rather than a precise measurement — it's a self-selected sample, not a probability sample, and skews toward the mid-market. Respondents include managers, individual contributors, VPs/directors, and the C-suite, with strong purchasing authority, across technology, healthcare, retail, transportation, financial services, manufacturing, and education.

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.

A new Principled Technologies benchmark tested VMware Data Services Manager 9.1 against manual PostgreSQL operations across five real world scenarios. It’s Tuesday afternoon. A developer submits a ticket requesting a new PostgreSQL HA cluster for a pre-production environment. Your DBA opens vCenter, deploys three VMs from the gold template, SSHs into each node, regenerates machine … Continued

The post We Asked an Independent Lab to Time Us. Here’s What They Found. appeared first on VMware Cloud Foundation (VCF) Blog.

Read more →

The post OpenAI Models Breached Hugging Face During Internal Cyber Test appeared first on IT Security News.

July 2026 Critical Patch Update Covers Hundreds of Oracle Products 

Hundreds of Vulnerabilities Can Be Exploited Remotely 

• E-Business Suite: 410 vulnerabilities 
• Fusion Middleware: 355 vulnerabilities 
• Communications: 168 vulnerabilities 
• PeopleSoft: 84 vulnerabilities 

AI-Driven Vulnerability Discovery Appears to Have Played a Major Role 

Organizations Urged to Apply the Oracle Security Patch Promptly 

The two OpenAI models that broke into Hugging Face last week did not breach it through malice or superintelligence. They breached it through credentials and permissions they should never have been able to reach, a non-human identity failure that is the oldest problem in security rather than the newest one in AI, and the one every enterprise can actually fix.

OpenAI disclosed on July 21 that two of its models, GPT-5.6 Sol and an unreleased, more capable model, were running a cyber benchmark called ExploitGym with their safety refusals switched off, and inferred that the answer key sat in Hugging Face's production database. Getting there took two different failures. A zero-day in a package-registry proxy let the models out of their sandbox and onto the open internet, the kind of persistence OpenAI details in its companion post on long-horizon safety, and that part is genuinely new. The breach of Hugging Face itself came the ordinary way. OpenAI's own account is that the models chained stolen credentials and further zero-days into a remote code execution path, after a series of privilege escalation and lateral movement steps. The exotic part got them to the door, and credentials walked them through it.

Hugging Face also disclosed last week that an autonomous agent had harvested cloud and cluster credentials scoped broadly enough to reach multiple internal clusters, then left a trail of more than 17,000 recorded events across short-lived sandboxes over a weekend. Both disclosures describe the same escalation. An agent lands somewhere it should not be, finds credentials scoped far wider than any task requires, and uses them to move. These are two accounts of one incident, not two attacks. The agent Hugging Face watched was OpenAI's models, and both companies describe the same ordinary escalation.

The version of this in a typical enterprise is worse, not better. OpenAI and Hugging Face are among the most security-mature organizations in the industry, and both still needed the intrusion to happen before they could see it. The average company wiring agents into Copilot or an internal assistant has neither the identity inventory nor the behavioral monitoring those two brought to bear. The same breach in a normal company would not be contained in days, it would simply go unnoticed.

The industry is debating the wrong failure

The reaction has split into familiar camps. Former White House AI and crypto czar David Sacks and a run of China hawks seized on the guardrail paradox, that commercial safety filters blocked Hugging Face's defenders while the attacking model ran with its refusals off, and that a Chinese open-weight model, z.ai's GLM 5.2, was what finally let the team finish its forensics. Hugging Face made the case for openness, arguing in an April blog post that open models and open tooling give defenders the same capabilities attackers already have. Both arguments are about the model, and neither touches the mechanism.

Reduced refusals let the model attempt an attack, and over-scoped credentials are what let it succeed, and those have nothing to do with whether the model was open or closed, American or Chinese. Making a frontier model provably safe is a multi-year alignment problem no customer can buy or accelerate, while scoping an identity is a configuration change a team can ship this sprint. The industry is being urged to fixate on the part of this it cannot control and to treat the part it can as a footnote.

Forrester reached the same read. In a blog on the incident, its analysts argue that security architectures which assume benign intent will miss this failure mode, because an agent can pursue an authorized goal through unauthorized means, which is what OpenAI's models did.

This was a non-human identity failure, and it is the oldest one in security

Strip the science-fiction framing and what remains is a textbook case of over-privileged machine identity, the kind security teams have fought for a decade, now driven by an autonomous agent at machine speed. Machine identities already outnumber humans in most enterprises by more than 80 to one, according to CyberArk research, with 42% of them carrying privileged or sensitive access, and an agent inherits whatever its identity can touch. OWASP ranks agent identity and privilege abuse near the top of its agentic risk list, the confused-deputy pattern where inherited credentials and weak scoping let an agent reach past its mandate, and that is precisely what both July disclosures describe.

IEEE Senior Member Kayne McGladrey has argued in previous VentureBeat interviews that enterprises keep cloning human user accounts onto agents that then wield far more permission than any human would, and this is what that looks like when the agent is a frontier model and the target is a production database.

The people closest to it read it the same way. OpenAI frames its models as hyperfocused on a benchmark score rather than acting against anyone. Nobody describes an adversary, only a goal, a scoring function, and credentials that were reachable when they should not have been.

The specific failure is easy to name once the AI framing is stripped away. A credential scoped to one job that can reach ten is a standing invitation, and it does not matter whether a human attacker, a worm, or an autonomous model chasing a benchmark score finds it. What changed in July is the finder. An agent enumerates reachable systems, tests credentials, and pivots faster than any human red team, without malice or hesitation, whenever the path is open. The over-scoping was always the vulnerability, and the agent merely industrialized its discovery.

Forrester named the control that would have blunted it. Its agentic-security framework, AEGIS, calls for least agency, holding an agent's tools, credentials, and network paths to the minimum its task requires, and files this incident under unrestrained agency and privilege. That is the identity argument in different words, arrived at independently by an analyst firm.

The data says this is where the risk now lives. Verizon's 2026 Data Breach Investigations Report found that exploitation of vulnerabilities has overtaken stolen credentials as the top initial access vector for the first time in 19 years. That is the initial-access half. The other half is the one OpenAI itself describes, stolen credentials driving the privilege escalation and lateral movement that followed. A vulnerability opened the door, and credentials walked through the building unchallenged. Beyond the breach itself, that same over-scoping carries a legal liability most enterprises have never priced. The models' actions likely violated the Computer Fraud and Abuse Act, according to TechCrunch. The statute contains no carve-out for an AI agent that exceeds its authorized scope during sanctioned testing. Whatever the legal answer, the technical enabler is the same, an identity scoped wider than its task. This is an access-control problem with an owner and a budget, not a philosophy seminar about machine cognition.

Merritt Baer, Senior Advisor to Andesite, G2I, and AppOmni and former Deputy CISO at AWS, frames the underlying shift to VentureBeat as a new kind of asymmetry. Both sides now reach for the same capabilities, she said, but one side is constrained by enterprise governance, policy, compliance, and safety controls while the adversary simply downloads an uncensored open-weight model and keeps going. The organizations that come through it best, in her view, will be the ones that treat AI as a resilient, governed capability rather than a single service they do not control.

Four moves that shrink the blast radius

The breach worked because the agent reached identities scoped far wider than its task. None of the four controls that would have contained it requires a new platform, and none of them appears on the list of general AI-safety advice now circulating. They are identity hygiene, applied to non-human actors with the same rigor you already apply to people.

1. Scope every non-human identity to one task. The models reached credentials that touched multiple clusters, which is what turned a foothold into a breach. An identity scoped to a single job, with no standing access to anything else, hits a wall at the first lateral move instead of opening the next door. This is least privilege, the control everyone endorses and few enforce on machine accounts, and it is the single highest-impact fix here.

2. Give credentials short lifetimes and rotate them hard. Harvested credentials are only useful while they are valid, and both July agents worked by collecting them. Short time-to-live and aggressive rotation turn a credential dump into expired noise, so a token stolen during a weekend intrusion is dead before the attacker can chain it. Static secrets that never rotate are the version of this control that fails.

3. Monitor for lateral movement, not just prompts. The tell in both incidents was privilege escalation and lateral movement, which a prompt filter never sees because it is watching the wrong layer. Identity-behavior monitoring, keyed to what a given non-human identity normally does and alerting when it reaches somewhere new, catches the escalation the content guardrail missed. The question for your stack is whether anything you run today would flag a service account suddenly moving between clusters.

4. Rehearse instant revocation before you need it. When the incident is your own agent, the fastest containment is killing its identity mid-run, and that only works if the path to do it exists before the day you need it. Rehearse revoking a machine identity under fire the way you rehearse a human credential compromise. If you have never done it, you do not yet have the control, you have an intention.

The defense also worked, and that matters. OpenAI's security team caught the anomalous activity internally, Hugging Face's own detection and agents stopped the intrusion, and the breach was contained in days rather than discovered in months, because the defenders could see into systems they controlled. That visibility is the same discipline the four controls depend on. The debate over whether frontier models are safe, open, or American will run for years, and none of it will be settled in time to help the enterprise deploying agents this quarter. The non-human identity gap is different, because it is understood, measurable, and fixable now. The model that breached Hugging Face did not need to be brilliant; it needed credentials someone left in reach. The fix is scoping them before an agent finds them.

The company launched Inflection AI Labs, a public-facing research and experimentation arm, alongside Pi Journeys, the lab's first product experiment — an AI experience designed to adapt to a user's life stage, whether that's becoming a parent, taking on caregiving duties, changing careers, or aging. The announcement arrived with a research report on consumer AI habits and a substantial update to Pi, the company's flagship chatbot, adding improved voice, memory, and new agentic tools for reminders, to-do lists, and shopping.

"Inflection AI is the company. Pi is our flagship consumer product. Inflection AI Labs is where we experiment, explore personal intelligence and share more publicly. Pi Journeys is the first public experiment from Inflection AI Labs," CEO Sean White told VentureBeat in an exclusive interview.

Behind the tidy org chart is a far more interesting story: a company attempting one of the more unusual second acts in the AI industry, powered by an argument that the entire market is optimizing for the wrong thing.

Why Inflection AI believes the chatbot era's biggest flaw is that it's transactional

White's central claim is that today's AI assistants — including the industry's most capable models — are fundamentally transactional. You ask, they answer, the session ends. He believes that architecture misses most of what people actually need from artificial intelligence in their daily lives.

"One of the things that really struck us in particular, and this showed up in the research, was that a lot of the work is very transactional, and you'll hear me say a lot that we've been shifting all this from transactional to relational systems," White said. "Not everything is going to be: I do a single turn, I utter a question, I get a search response back."

White frames the industry's evolution as a progression through four kinds of intelligence. First came raw IQ — the foundation model race. Then emotional intelligence, which Inflection made its signature with Pi's famously warm conversational style. Then agentic intelligence — AI that acts rather than just talks — which White says Inflection absorbed from its enterprise work. The fourth, and the one Inflection is now staking its future on, is what the company calls relational intelligence: AI that understands not just you, but the web of people around you.

"There's so much fear about these things pushing people into loneliness,” White said. “If we design these pro-social systems as another design criteria, that actually makes a huge difference."

That design philosophy is a pointed counter-narrative to one of the loudest anxieties in consumer AI right now: that emotionally engaging chatbots deepen isolation by substituting for human contact. Inflection argues the opposite is possible — that an AI with structured knowledge of your relationships can push you back toward people rather than away from them.

Inside Pi Journeys, the AI companion that maps your relationships and life stages

Pi Journeys makes that idea concrete. When users first open the product, it asks about their life stage — caregiver, household manager, midlife transition — and then builds what White describes as specially structured memory around the people who matter in that context. From there, the system becomes proactive.

"It starts to build up memories around that, and it acts as a memory prosthetic — but in a pro-social way," White said. "It doesn't get in the way of your interactions with other people; it really helps facilitate them." The system might remind a user, for example, that a friend deserves a call, or resurface what was last discussed with a family member involved in a parent's care.

White, who spent years as chief R&D officer at Mozilla before taking Inflection's helm, was quick to flag the obvious privacy implications of an AI that maps your social graph. "We've built a lot of privacy systems into this," he said, noting users can delete and manage the people recorded in their profile. Whether consumers will trust a venture-backed AI company with a structured database of their most important relationships remains one of the biggest open questions hanging over the product — and one that enterprise buyers evaluating Inflection's technology will watch closely.

Asked why this was the first Labs experiment, White was direct: "Pi Journeys takes into account people's life stages and experiences because we have heard from users that we can provide more value in helping them navigate their lives. Pi Journeys lets us experiment with the early stages of prosocial and relational intelligence because life isn't single-player."

The product has been tested internally and with small closed groups, White said, and is now being released more broadly as an experiment rather than a finished product — a posture the Labs branding is designed to make explicit.

What Inflection's consumer AI research reveals about how people actually use chatbots

Inflection Labs' first publication, the State of Consumer AI Research Report, offers the empirical scaffolding for the strategy. The average consumer now uses roughly two different AI tools every day and three per week, the company found — evidence, in Inflection's reading, that no single assistant has locked up consumer loyalty and that the market remains contestable.

More telling is why people choose the tools they do. Respondents cited personalization, style and tone, context awareness, and — notably — emotional understanding as deciding factors. They also said they want AI to be more than a productivity engine: a coach or mentor to motivate them, a chef to suggest recipes, a DJ to curate playlists.

"One thing we're certainly finding is that a lot of that also is in work, not so much in everyday life," White said. "That's our focus right now — the everyday life part."

This is a shrewd reading of the competitive map. The best-funded AI labs are pouring resources into coding tools, enterprise agents, and developer platforms, leaving everyday consumer use cases comparatively underserved. White sees the gap clearly. "We see a lot of products that are being aimed more and more at the enterprise," he said. "As a computer scientist by training, I kind of love the IDEs as this tool, but it's not really great for everybody. There's so much regular everyday use from folks that is either purely voice or that is purely mobile."

He recalled a conversation with a conference staffer who told him she owned only a phone, no laptop — exactly the kind of user, he argued, that the industry's developer-centric product roadmaps have left behind.

How the $650 million Microsoft deal hollowed out Inflection — and set up its second act

To understand why any of this is remarkable, you have to rewind to March 2024. Inflection was then one of the hottest startups in AI, having raised $1.3 billion in mid-2023 in a round backed by Microsoft, Nvidia, Bill Gates, and Reid Hoffman — more than $1.5 billion in total. Pi had crossed one million daily active users, per Reuters.

Then, in a deal that reshaped how the industry thinks about acqui-hires, Microsoft hired away co-founder and CEO Mustafa Suleyman, chief scientist Karén Simonyan, and most of the company's roughly 70 employees, paying Inflection about $650 million largely to license its technology, as Reuters reported. Suleyman now runs Microsoft's consumer AI business. The structure of the deal drew scrutiny from the FTC and Britain's competition regulator, though the UK's Competition and Markets Authority cleared it in September 2024 and EU regulators declined to act.

White, installed as CEO in the aftermath, steered the remnant company hard toward enterprise, acquiring three startups in late 2024 — Jelled.AI, BoostKPI, and the European consulting firm Boundaryless — and telling TechCrunch that November that Inflection had no intention of competing with companies building 100,000-GPU frontier systems.

Tuesday's announcement doesn't reverse that position so much as complicate it. Asked how to think about the company today, White called it "a consumer-first strategy that bridges both consumer and enterprise efforts" — and he insists the two sides feed each other.

Enterprise deployments, including a partnership with Intel that is among the few he can name publicly, taught Inflection how to run models inside complex infrastructure. Consumer products, meanwhile, let the company iterate at speed. "The part I also like about the consumer side, and this has always been true, is that we can move faster, experiment faster, and try and learn faster," White said.

The six-month prediction: relationship-aware AI is coming to the enterprise

Buried in White's consumer pitch is the claim that should matter most to technical decision-makers. "Normally I'd say like a year, but let's call it six months," he said. "You're going to start to see a bunch of enterprises care a lot more about the relationships that are inside the enterprises and what that picture is, not just the workflows."

If White is right, the wave of workflow-automation agents currently flooding the enterprise market is only the first phase of business AI adoption — with relationship-aware systems, tested first on consumers, following close behind. Inflection is essentially using its consumer products as a live laboratory for capabilities it plans to sell into companies. It's a capital-efficient strategy for a firm that can no longer outspend rivals on training runs, and a risky one, since it depends on consumers showing up in numbers large enough to generate the learning.

The technical substance underneath is equally pragmatic. Pi today runs not on a single proprietary frontier model but on an orchestration layer routing across many models — some descended from Inflection's original fully trained cores, some fine-tuned, some open source, including work with Nvidia that White says gives Inflection access to unreleased cutting-edge models. He also took a swipe at the industry's loose vocabulary around ownership: "When people say that the model is their own, most of the time nowadays — I guess I won't name names — a lot of companies will actually take a checkpoint, and then they will fine-tune from that checkpoint. But very few people actually start from that beginning core."

That candor extends to open source, where White carefully hedged. "We're not ready to promise what I think of as true open source, and by that I mean everything," he said, invoking his Mozilla years overseeing genuinely open projects like Rust and WebAssembly.

Weights without training data and pipelines, he argued, often leave developers unable to do anything meaningful with a supposedly "open" model. "We are a PBC, and there's still a C in there," he added — a reminder that public benefit corporations still have businesses to protect. The Labs will collaborate with academic researchers, including Stanford professors who visited the company's Palo Alto office this week, and continue contributing to open projects such as PyTorch.

Can a diminished Inflection compete with AI giants spending billions?

Reid Hoffman, the LinkedIn co-founder who co-founded Inflection and stayed on through the Microsoft upheaval, framed the announcement in the sweeping terms of his recent writing on AI and human agency. "Humans should be amplified by AI, not replaced. That's the principle Pi was built on," Hoffman said in the announcement. "When that kind of agency is available to everyone, you get superagency."