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. 

Following an action-packed Day One where $523,000 was awarded for 24 unique 0-day vulnerabilities, Day Two added another $385,750 and 15 unique 0-days, bringing event totals to $908,750 with 39 unique vulnerabilities overall. DEVCORE holds a commanding lead for Master of Pwn with 40.5 points and $405,000, but with one day still to go, anything can happen. Here are the standings as of Day Two but we'll see what the final day of the contest brings. Stay tuned!

We’ll be posting real-time updates and results throughout the competition right here 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, Tao Yan & Edouard Bochin of Palo Alto Networks could not get their exploit of Apple Safari – Renderer Only working within the time allotted.

FAILURE - Unfortunately, Stephen Fewer of Rapid7 could not get their exploit of Microsoft SharePoint working within the time allotted.

SUCCESS - Ben Koo (@kiddo_pwn) of Team DDOS used a use-after-free bug to escalate privileges on Red Hat Enterprise Linux for Workstations in the second round, earning $10,000 and 1 Master of Pwn point.

SUCCESS - Dialed in! Nikolaos Mourousias (@deltaclock), Caue Obici (@caueobici) & Bruno Halltari (@BrunoModificato) of OtterSec used a Code Injection bug to exploit LM Studio in the second round, earning $20,000 and 4 Master of Pwn points. Full win!

COLLISON - Although successful on stage, Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting Claude Desktop in the Coding Agent category used a bug that was previously known. They still earn $10,000 and 2 Master of Pwn points.

SUCCESS - Le Duc Anh Vu (@vulda17) of Viettel Cyber Security (@vcslab) exploited Cursor, earning $30,000 and 3 Master of Pwn points. Full win!

WITHDRAWAL - Kiyong Kwak of Kakaogames and Song Nuri of Samsung Electronics has withdrawn their entry for Apple Safari – Renderer Only in the Web Browser category.

FAILURE - Unfortunately, Ruitong of Abstract Team, University of Colorado Boulder could not get their exploit of Red Hat Enterprise Linux for Workstations working within the time allotted.

SUCCESS - Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) exploited OpenAI Codex in the second round, earning $20,000 and 4 Master of Pwn points.

COLLISON - Although successful on stage, Billy (@st424204), Bruce Chen (@bruce30262), Pan Zhenpeng (@Peterpan980927) & Weiming Shi (@bestswngs) of STARLabs SG (@starlabs_sg) targeting NVIDIA Megatron Bridge used a bug that was previously known. They still earn $2,500 and 1 Master of Pwn point.

WITHDRAWAL - Alon Ben Tsur (@iamgweej), Yahav Azran (@_yahav) have withdrawn their entry for Red Hat Enterprise Linux for Workstations in the Local Escalation of Privilege category.

SUCCESS - Orange Tsai (@orange_8361) of DEVCORE Research Team chained 3 bugs to achieve Remote Code Execution as SYSTEM on Microsoft Exchange, earning $200,000 and 20 Master of Pwn points.

SUCCESS / COLLISON - David Tae & Louis Hur of Out Of Bounds targeted Ollama, hitting a one-vulnerability collision with a previous attempt and earning $28,000 and 3 Master of Pwn points.

FAILURE - Nguyen Thanh Dat (@rewhiles) of Viettel Cyber Security (@vcslab) could not get their exploit of Mozilla Firefox – Renderer Only working within the time allotted.

SUCCESS - Cyrill Bannwart, Emanuele Barbeno, Yves Bieri, Lukasz D., Urs Mueller (@compasssecurity) of Compass Security exploited Cursor in the second round, earning $15,000 and 3 Master of Pwn points.

SUCCESS - Siyeon Wi used an integer overflow bug to escalate privileges on Microsoft Windows 11 in the fourth round, earning $7,500 and 3 Master of Pwn points.

SUCCESS / COLLISON - Byung Young Yi (@yibarrack) of Out Of Bounds targeted LiteLLM, hitting a one-vulnerability collision with a previous attempt and earning $17,750 and 3.75 Master of Pwn points.

SUCCESS - Confirmed! 0xDACA (@0xDACA) & Noam Trobishi (@NTrobishi) used a use-after-free bug to exploit NV Container Toolkit in the second round, earning $25,000 and 5 Master of Pwn points.

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.

Maximize app performance and ROI with the R8 Configuration Analyzer

A premium experience is only as good as its foundation, and a performant foundation is what allows your app to scale across the Android ecosystem. This is especially true with the release of Android 17, which introduces conservative, device RAM-based app memory limits to target extreme memory leaks and outliers before they cause system-wide instability. To stay below these new system thresholds and prevent your app from being terminated, having a lean footprint is no longer optional: it’s a critical requirement.

This year, we’re making it easier to build highly optimized, fast apps by introducing the R8 Configuration Analyzer in Android Studio. R8 is your most powerful tool for improving app performance, but its effectiveness is often limited by overly broad "keep rules" that prevent the compiler from stripping away unused code. The new Configuration Analyzer provides optimization, obfuscation, and shrinking scores, allowing you to identify specific rules that are preventing the benefits of R8 optimization.

By optimizing their R8 configurations, developers at Monzo achieved a 30% improvement in cold starts and a 35% reduction in ANRs. Smaller, faster code isn't just about efficiency; it's about ensuring your app has the memory headroom to deliver delight on every form factor, from the phone to the car.

Extend your reach with a unified approach to Widgets on Phones, Watches and Cars

User interaction is shifting toward quick, glanceable moments—short bursts of information that keep users connected without needing to open the full app. To help you increase the reach of your app content, we are unifying the development experience across the Android ecosystem with Jetpack Glance. By using a consistent, Compose-based model, you can elevate the content most important to your users straight to the phone’s home screen, Wear Widgets (previously Tiles!), and cars with a familiar workflow.

In order to help users engage with your content and features, even outside your app, we are making widgets more expressive and adaptive with RemoteCompose. On Wear OS, RemoteCompose allows you to use the Compose tools you’re already comfortable with to define UI logic that renders natively on remote surfaces, ensuring that your glanceable experiences remain highly performant and responsive even on resource-constrained hardware. On mobile and cars, RemoteCompose is used as a new framework giving Widgets new expressive capabilities.

You can use Jetpack Glance (together with RemoteCompose on Wear) to deliver a cohesive user journey. Whether it’s viewing flight status on the car dashboard, checking a gate change on a watch, or managing a boarding pass from a phone widget, this shared approach maximizes your app’s presence while keeping your development effort focused and efficient.

For more details, check out the premium Android experience YouTube playlist.

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.

Every year, Google I/O brings new announcements and resources across ecosystems and products, including Android development. As development shifts toward AI and agent-assisted tooling, we’ve expanded our offerings to better support you, however you decide to build for Android.

To help you stay up to date, here is a summary of the top 3 announcements for Android Developer Productivity at I/O.

1. Android CLI is now stable

Android CLI is now stable at version 1.0, with more capabilities and integrations.

The latest version of Android CLI introduces many new features, like programmatic version lookup and support for Journeys, and bridging capability to allow agents to integrate directly with Android Studio, via the studio command.

Running Android Studio alongside the agent and Android CLI enables more efficient navigation in your project, more precise output, and access to Android Studio’s unique tooling, such as performance profilers, Compose Previews, and Android Device Streaming.

Android CLI now integrates seamlessly with Android Studio

Additionally, Google Antigravity now officially supports Android development, with the Android resources bundle, which includes the Android CLI and skills.

You can either install the bundle during onboarding after installation, or later from the Settings > Customizations > Build With Google Plugins menu. This provides Antigravity with all the powerful tools and knowledge of Android CLI to enable it to perform core tasks—from creating projects to deploying your app on a new virtual device—much more easily and efficiently.

Google Antigravity now offers the Android resources bundle

Android CLI is now available through more package managers: like npm and homebrew. For more information, check out the Android CLI blog post and official documentation.

2. Android skills keep growing

To help models gain expertise for specific development patterns that follow our best practices, we are continuing to expand our repository of Android skills, available through Android CLI and GitHub.

Android skills ground LLMs in specialized workflows and domain knowledge, for the most common and more complex user journeys they might struggle with. We’ve shipped a fresh new batch of skills, with now more than 17 skills for areas such as:

• Adaptive UI
• Display Glasses and Jetpack Compose Glimmer for XR
• Migration to CameraX
• Perfetto SQL and Trace Analysis
• Jetpack Compose Styles API
• AppFunctions
• Verified email retrieval with Android Credential Manager
• Engage SDK integration
• Testing setup
• Wear OS Jetpack Compose Material3

Android skills keep growing

You can browse skills and install using the Android CLI commands:

android skills list
android skills add –skill=<skill-name>

For more information, check out the official documentation.

3. Android Bench adds new models

Earlier this year, we launched Android Bench - our leaderboard for testing LLMs on real-world Android development challenges and tasks, with the goal of accelerating model improvements, so you have more helpful options for AI assistance.

Latest results from Android Bench leaderboard

You asked us to evaluate open models. So, at I/O, we added more commonly used ones, including our local model Gemma 4, to the leaderboard. We also added the latest models including Gemini 3.5 Flash.

We are also working on increasing the difficulty of challenges we’re giving LLMs, including creating long running tasks, to continue encouraging improvements. These tasks will be coming soon to Android Bench. Check out the Android Bench leaderboard to see the latest results.

Android development anywhere

By expanding our AI-assisted Android development offerings to Antigravity, through Android CLI and Android skills, and solidifying with the pro capabilities and production grade polish of Android Studio, we’re supporting Android developers wherever they choose to build.

Have fun bringing your ideas to life faster and easier than ever before - we’re excited to see what you build in this new era of agentic development.

Check out the full Developer productivity at Google I/O 2026 YouTube playlist for more information.

Today we're releasing Android 17 and making it available on most supported Pixel devices. Look for new devices running Android 17 in the coming months.

Android 17 marks the start of our transition to an intelligence system, putting your apps at the center. It's shifting to an adaptive-first development standard by introducing mandatory large-screen resizability, all while delivering next-generation privacy, security, media, camera, and performance. We'll cover all that in this post, as well as how we're bringing together next generation tools, libraries, and agent skills to help your apps embrace the opportunity.

Throughout the past year, from our Canary channel to our Beta releases, we’ve collaborated with you in the developer community to build a platform you and your users can trust. To that end, this moment marks the availability of the source code at the Android Open Source Project (AOSP). This allows you to examine the source code for a deeper understanding of how Android works.

Let's dive deeper into Android 17.

An intelligence system

With deep integration between hardware, software and AI, we’re transforming Android from an operating system to an intelligence system. It's about delivering new helpful experiences that anticipate user needs, and it brings more opportunities for engagement with your apps. To that end, Android 17 expands the capabilities of AppFunctions, a platform API with a corresponding Jetpack library. It allows you to contribute your app's unique capabilities as orchestratable "tools" for Android MCP, the on-device equivalent of the Model Context Protocol. AI agents and assistants (like Google Gemini) can discover and execute AppFunctions to perform workflows on behalf of the user with direct access to the app's local state.

The Jetpack library, currently in alpha, makes adding AppFunctions as easy as annotating a class and adding KDoc comments.

/**
 * A note app's [AppFunction]s.
 */
class NoteFunctions(
    private val noteRepository: NoteRepository
) {
    /**
     * Adds a new note to the app.
     *
     * @param appFunctionContext The execution context.
     * @param title The title of the note.
     * @param content The note's content.
     */
    @AppFunction(isDescribedByKDoc = true)
    suspend fun createNote(
        appFunctionContext: AppFunctionContext,
        title: String,
        content: String
    ): Note {
        return noteRepository.createNote(title, content)
    }
}

We’ve also launched an AppFunctions agent skill that analyzes your app’s key workflows, automatically generates the required Kotlin code, optimizes your KDocs for LLM tool-calling, and provides ADB commands for testing and debugging.

The Gemini integration is currently in a private preview with trusted testers, but you can begin preparing your apps now. In addition to ADB commands to execute your AppFunctions, we've provided a test agent app that includes an interface to discover and execute your app functions and simulate an AI agent integration. Join our integration early access program at goo.gle/eap-af for a chance to be among the first apps to deploy AppFunctions to production.

Adaptive-first

Your users no longer rely on a single form factor; they transition between phones, foldables, tablets, laptops, automotive displays, and immersive XR environments. Now, with over 580 million large screen devices in the hands of users and the forthcoming launch of Googlebooks, the next generation of ChromeOS built on the Android stack, adaptive is no longer just a technical goal. It’s a massive opportunity to reach highly engaged users, which is one of the reasons we're shifting to an adaptive-first development standard.

No resizability/orientation restrictions on large screens

To ensure apps deliver a premium experience across all form factors, including mobile devices running in desktop mode on connected displays, Android 17 (API level 37) removes the developer opt-out for orientation and resizability restrictions on large screen devices (sw > 600 dp) for apps targeting API level 37. The system will ignore legacy manifest attributes and runtime APIs, including screenOrientation, setRequestedOrientation(), resizeableActivity=false, and aspect ratio constraints (minAspectRatio/maxAspectRatio). Games (based on app category in Google Play) remain exempt. Your app must be ready to adapt to any window size, respect the user's preferred device posture, and support free-form windowing natively.

Next-gen multitasking: App Bubbles, Bubble Bar, and desktop interactive PiP

Android 17 introduces powerful new windowing capabilities that redefine how users multitask, demanding even greater layout flexibility from your apps:

• App Bubbles: Moving beyond the messaging bubbles API, users can now transform any app into a floating bubble by long-pressing its icon on the launcher. This feature is available across phones, foldables, and tablets, enabling lightweight multitasking for any workflow.
• The Bubble Bar: On large screens (tablets and foldables), the system taskbar now includes a dedicated Bubble Bar to organize, transition between, and dock these floating app bubbles.
• Desktop interactive PiP: In desktop environments, Android 17 introduces interactive Picture-in-Picture (PiP). Unlike traditional PiP windows which are read-only, these pinned windows remain fully interactive while staying always-on-top of other application windows.

App Bubbles and Bubble Bar in action

Activity recreation updates

To prevent disruptive state loss and stutter, Android 17 updates the default behavior for Activity recreation. The system will no longer restart activities by default for typical configuration changes that do not require a full UI redraw (including CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_TOUCHSCREEN, and CONFIG_COLOR_MODE).
Instead, running activities will receive these updates via onConfigurationChanged(), enabling smooth transitions. If your application explicitly relies on a full restart to reload resources for these changes, you must now explicitly opt-in using the new android:recreateOnConfigChanges manifest attribute.

Continue On

Android 17 adds Continue On to help users seamlessly transition a task between Android devices. The user sees a suggestion for the most recently opened app from their mobile device in their tablet taskbar, providing a one-tap affordance to launch the app and deep-link where they left off. Continue on can support app-to-web transitions, including falling back to using the web if the app isn't installed.

Handoff Suggestion on a Tablet

class MyHandoffActivity : Activity() {

    ...

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // Do stuff
    ...
    // Enable handoff
    setHandoffEnabled(true, null)
  }

  // Override and implement onHandoffActivityDataRequested
  override fun onHandoffActivityDataRequested(handoffRequestInfo: HandoffActivityDataRequestInfo) : HandoffActivityData {
    // Create and return handoff data
  }
}

Go adaptive-first with Jetpack Compose

To help you adapt your apps to meet the new Android 17 requirements, we've launched the Jetpack Compose adaptive skill. This AI-powered developer workflow helps you implement the best adaptive practices:

• Adaptive navigation: Automatically transition between bottom navigation bars on mobile and edge-anchored navigation rails on large screens using NavigationSuiteScaffold from the Material 3 Adaptive library.
• Multi-pane layouts: Implement list-detail and supporting pane layouts natively using Navigation 3 Scenes (ListDetailSceneStrategy and SupportingPaneSceneStrategy) instead of fragile fragment transactions.
• FlexBox & Grid APIs: Utilize Compose 1.11's dynamic layout components to easily adjust row and column spans on the fly, ensuring your content always fills the space beautifully.
• Advanced non-touch input: Leverage Compose 1.11's enhanced trackpad and mouse support, including native focus rings and new APIs (like TrackpadInjectionScope and performTrackpadInput) to easily test and deliver a true "laptop-class" experience on Googlebooks and Desktop Mode.
• Dynamic window states: Leverage Compose's reactive state model to seamlessly adapt your UI when the app transitions from full screen to a floating App Bubble or an interactive Desktop PiP window, ensuring a premium experience even at minimal dimensions.

Android is Compose-first

Compose offers the easiest way to build adaptive apps, and that's just one of the many reasons we believe that all Android UI should be built with Compose. To that end, Android development is now Compose-first. All new Android APIs, libraries, tools, and developer guidance will be built exclusively for Jetpack Compose. Legacy View components (in the android.widget package) and View-based Jetpack libraries (like Fragments, RecyclerView, and ViewPager) are now in maintenance mode. They will receive only critical bug fixes, and no new features.

TIP
Ready to migrate? Use our AI-driven XML to Compose Migration Skill to automatically analyze your legacy View layouts and convert them into highly-adaptive Compose code.

Performance & efficiency

App performance means a smooth user interface, fast app start times, and efficient multitasking; Android 17 has impactful improvements in all of these areas.

App memory limits

Memory usage is one of the silent foundations of overall performance. When a foreground app or service grows unchecked, memory management spikes CPU and battery utilization and eventually leads to the termination of other well-behaved cached apps and background jobs, ultimately forcing slower cold starts and impaired multitasking. 

Starting in Android 17, the system will enforce strict app memory limits based on a device's total RAM, abruptly terminating offending processes. New things to help you navigate these tighter requirements:

• R8 Optimizer: The R8 optimizer significantly reduces your app's bytecode memory footprint by shrinking classes, methods, and fields into shorter names, and stripping out unused code and resources. Use R8 in full mode along with the new R8 configuration analyzer to make sure your app is getting the most from R8.
  

• LeakCanary in Android Studio Panda: The profiler now features native LeakCanary integration as a dedicated task, fully integrated with your IDE and source code.
• ApplicationExitInfo: If your app is terminated by these limits, getDescription() from ApplicationExitInfo will return "MemoryLimiter:AnonSwap".
• On-Device Anomaly Detection: Part of ProfilingManager, you can leverage trigger-based profiling using TRIGGER_TYPE_ANOMALY to automatically capture heap dumps when the memory limit is reached.

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

val triggers = ArrayList<ProfilingTrigger>().apply {
  add(ProfilingTrigger.Builder(
    ProfilingTrigger.TRIGGER_TYPE_ANOMALY).build())
}
profilingManager.addProfilingTriggers(triggers)

And, we're working to surface more in-field memory metrics to you within Google Play Console.

Generational garbage collection

Android 17 introduces more frequent, less resource-intensive young-generation collections to ART's Concurrent Mark-Compact garbage collector (GC). By separating short-lived objects from stable, long-lived ones, the system runs frequent, lightweight "young-generation" sweeps rather than expensive full-heap scans, drastically reducing CPU usage, power drain, and UI stutter. Our testing has shown significant improvements in GC interference with application threads and a reduction in the maximum memory resident set size (RSS). ART improvements are also available to over a billion devices running Android 12 (API level 31) and higher through Google Play System updates.

Lock-Free MessageQueue

For apps targeting SDK 37 or higher, the core android.os.MessageQueue now implements a lock-free architecture, significantly reducing missed frames, improving app startup time, and radically improving the performance of busy queues in multithreaded scenarios. Note: This can break apps that use reflection on private MessageQueue fields and methods.  The peekWhen and poll APIs have been added to TestLooperManager for instrumentation testing without relying on MessageQueue internals.

Static final fields now truly final

Starting from Android 17, apps targeting SDK 37 or higher won’t be able to modify “static final” fields, allowing the runtime to apply performance optimizations more aggressively. An attempt to do so via reflection (or deep reflection) will lead to an IllegalAccessException being thrown. Modifying them via JNI’s SetStatic<Type>Field methods family will immediately crash the application.

Custom notification view restrictions

To reduce memory usage we are further restricting the size of custom notification views. This update closes a loophole that allows apps to bypass existing limits using URIs. This behavior is gated by the target SDK version and takes effect for apps targeting API 37 and higher.

Privacy & Security

Maintaining user trust is at the heart of the Android ecosystem. Android 17 introduces robust features that protect sensitive data while simplifying user experiences.

Privacy-preserving choices

Historically, apps required broad, permanent permissions to access information like contacts, precise location and media files. Android 17 continues the shift toward privacy-preserving choices that grant temporary, session-based access only to the data the user explicitly selects:

• System-Level Contact Picker: Utilizing ACTION_PICK_CONTACTS, apps can request temporary access only to specific fields (e.g., email or phone number) chosen by the user, eliminating the need for the broad READ_CONTACTS permission. It also fully supports work/personal profile separation.
• Customizable Photo Picker aspect ratio: UsingPhotoPickerUiCustomizationParams, you can customize the system photo picker to show thumbnails in portrait mode. This is perfect for apps that always display photos and videos in portrait such as video based social media apps.
• System-rendered Location Button: A new system-rendered location button that you can embed in your app grants precise location access for the current session only.
• EyeDropper API: A new system-level API, ACTION_OPEN_EYE_DROPPER, allows your app to create a system-powered eyedropper enabling the user to select color from any pixel on the display. This provides a secure, privacy-preserving color-picking experience that eliminates the need for broad, sensitive screen capture or media projection permissions.

val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
   if (result.resultCode == Activity.RESULT_OK) {
       val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK)
       // Use the picked color in your app
   }
}
fun launchColorPicker() {
   val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER)
   eyeDropperLauncher.launch(intent)
}

Picking a color from anywhere on the screen with the system EyeDropper

Local network access

Apps targeting Android 17 now either require the ACCESS_LOCAL_NETWORK runtime permission or the use of system-mediated, privacy-preserving device pickers for local network communication, such as talking to smart home devices or casting receivers. Because ACCESS_LOCAL_NETWORK falls under the existing NEARBY_DEVICES permission group, users who have already granted other NEARBY_DEVICES permissions will not be prompted again.

SMS OTP protection

Android 17 expands SMS one-time-password (OTP) protection by delaying access to SMS messages for three hours:

• WebOTP Format: Delayed for all apps that are not the intended recipient (domain mismatch).
• Standard SMS OTP: Delayed for all apps targeting SDK 37+.
• Exemptions: Default SMS, assistant, and connected companion apps are exempt. Apps are strongly encouraged to migrate to the SMS Retriever or SMS User Consent APIs.

Post-Quantum Cryptography (PQC)

Android 17 is ready for the next generation of cryptographic security:

• Keystore Integration: Supported devices can generate ML-DSA (Module-Lattice-Based Digital Signature Algorithm) keys in secure hardware to produce quantum-safe signatures, exposed via standard JCA APIs.
• Hybrid APK Signing: Introducing the v3.2 APK Signature Scheme, which combines classical signatures with ML-DSA signatures to secure app delivery.

Safer native dynamic code loading 

Smarter password protection for physical inputs

With Android 17, we're making it safer to enter passwords, PINs, and other secrets when using a physical keyboard by no longer showing the last typed character by default.

Users can still easily customize these display settings to match their preferences (availability may vary by device manufacturer).

These enhanced privacy protections are automatically supported byAndroid's built-in SDK components and will be supported in Compose 1.12 for SecureTextFields.

Media and camera features that empower creators and delight users

Android 17 introduces new creator features that give access to pro-quality cameras and media, all while improving the experience for consumers.

• Eclipsa Video: HDR video standard built upon the SMPTE ST 2094-50 specification that introduces new metadata to help devices adapt content for their display headroom and ambient light conditions, as well as improve the simultaneous display of standard and HDR content.
• RAW14 image format: New support for the RAW14 image format provides a way for your professional camera app to capture the highest level of detail and color depth from compatible camera sensors.
• Vendor-defined camera extensions: Vendor-defined extensions enable hardware partners to define and implement custom camera extension modes, providing access to the best and latest camera features.
• Extended HE-AAC software encoder: A new system-provided Extended HE-AAC software encoder, supports both low and high bitrates using unified speech and audio coding, providing significantly better audio quality for voice messages in low-bandwidth conditions, including support for loudness metadata.
• Versatile Video Coding (H.266): Enables OEMs to add codec support by defining the video/vvc MIME type in MediaFormat, adding new VVC profiles in MediaCodecInfo, and integrating support into MediaExtractor.
• Camera device type: New APIs that query the underlying device type to identify if a camera is built-in hardware, an external USB webcam, or a virtual camera.
• Constant Quality for Video Recording: SetVideoEncodingQuality in MediaRecorder configures a constant quality (CQ) mode for video encoders to ensure uniform visual fidelity across the entire video.

Better support for hearing aids

• Bluetooth LE Audio hearing aid support: Android now includes a specific device category for Bluetooth Low Energy (BLE) Audio hearing aids with the new AudioDeviceInfo.TYPE_BLE_HEARING_AID constant, so your app can distinguish hearing aids from regular headsets to provide a tailored experience for users with assistive listening devices.
• Granular audio routing for hearing aids: Android 17 allows users to independently manage where specific system sounds are played. They can choose to route notifications, ringtones, and alarms to connected hearing aids or the device's built-in speaker, helping to avoid unwanted in-ear interruptions while maintaining a Bluetooth connection for hearing aid management apps.

CameraX and Media3

CameraX and Media3 have been updated for Android 17. They are there to do the heavy lifting, smoothing the rough edges of media development and simplifying building reliable camera capture, smooth media playback, and creative and complex editing experiences.

We've released an agent skill that can migrate legacy Android camera implementations (Camera1 or raw Camera2 APIs) to CameraX.

Note: You'll need to update your CameraX version to either 1.5.2 or 1.6.0+ to avoid a crash related to an added dynamic range mode on Android 17 devices.

Get your apps, libraries, tools, and game engines ready!

If you develop an Android SDK, library, tool, or game engine, it's critical to prepare any necessary updates now to prevent your downstream app and game developers from being blocked by compatibility issues and allow them to target the latest SDK features. Please let your downstream developers know if updates are needed to fully support Android 17.

Testing involves installing your production app or a test app making use of your library or engine using Google Play or other means onto a device or emulator running Android 17 Beta 4. Work through all your app's flows and look for functional or UI issues. Each release of Android contains platform changes that improve privacy, security, and overall user experience; review the app impacting behavior changes for apps running on and targeting Android 17 to focus your testing, including the following:

• Resizability on large screens: Once you target Android 17 (SDK 37), you can no longer opt out of maintaining orientation, resizability and aspect ratio constraints on large screens.
• Dynamic code loading: If your app targets SDK 37 or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries. All native files loaded using System.load() must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError.
• Enable CT by default: Certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in.)
• Local network protections: Apps targeting SDK 37 or higher have local network access blocked by default. Switch to using privacy preserving pickers if possible, and use the new ACCESS_LOCAL_NETWORKpermission for broad, persistent access.
• Background audio hardening: Starting in Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs. Based on your feedback, we’ve made some changes since beta 2, including targetSDK gating while-in-use FGS enforcement and exempting alarm audio. Full details available in the updated guidance.
• NPU access declaration: Apps targeting Android 17 that need to directly access the NPU must declare FEATURE_NEURAL_PROCESSING_UNIT in their manifest to avoid being blocked from accessing the NPU. This includes apps that use the LiteRT NPU delegate, vendor-specific SDKs, as well as the deprecated NNAPI.

Get started with Android 17

Your Pixel device should get Android 17 shortly if you haven't already been on the Android Beta. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio. If you are currently on Android 17 Beta 4.1 and have not yet taken an Android 17 QPR1 beta, you can opt out of the program and you will then be offered the release version of Android 17 over the air.

Getting the Android 17 beta on partner devices

Android 17 is available in beta on handset, tablet, and foldable form factors from partners including Honor, iQOO, Lenovo, OnePlus, OPPO, Realme, Sharp, vivo, and Xiaomi.

For the best development experience with Android 17, we recommend that you use the latest Canary build of Android Studio Quail. Once you’re set up, here are some of the things you should do:

Test your current app for compatibility, learn whether your app is affected by changes in Android 17, and install your app onto a device or Android Emulator running Android 17 and extensively test it.

Thank you again to everyone who participated in our Android developer preview and beta program. We're looking forward to seeing how your apps take advantage of the updates in Android 17, and have plans to bring you updates in a fast-paced release cadence going forward.

For complete information on Android 17 please visit the Android 17 developer site.

A few years ago we deployed Matrix with docker-compose. Now, let's give it a go on Kubernetes!

00:00 Introduction
01:40 Kubernetes Makes Things Simple
04:59 Getting Started
06:21 Installing Kubernetes
14:41 Deploying and Removing a Wordpress
20:53 Deploying A Matrix Stack
31:02 More Services Almost For Free

This Week in Matrix: https://matrix.org/twim

Find Matrix.org on the internet:
🐘 https://mastodon.matrix.org/@matrix
🤝 https://www.linkedin.com/company/matrix-org
🦋 https://bsky.app/profile/matrix.org
[m] Office of the Matrix Foundation https://matrix.to/#/%23foundation-office:matrix.org

Voice conversations now run on the more powerful Opus and Sonnet models with access to Gmail, Google Calendar, and Slack. Claude is currently the only AI assistant that can compose and send emails directly by voice, giving it an edge over OpenAI and Google, whose voice output still sounds more natural.

The article Claude's voice mode now runs on Anthropic's most capable models across all platforms appeared first on The Decoder.

Zimbra Phishing Campaign Uses CVE-2025-66376

LAUNDRY BEAR Targets Email and Sensitive Data

Ulej and Flowerbed Support Email Data Exfiltration

Organizations Urged to Patch Vulnerable Zimbra Systems

The post Andrew Ng Just Released OpenWorker: An Open-Source, Local-First Desktop AI Coworker That Returns Finished Deliverables Instead of Chat appeared first on MarkTechPost.

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.

Der Artikel WorldMonitor holt die Weltlage ins eigene Heimnetz erschien zuerst auf TARNKAPPE.INFO

Translate older Ollama GGUF attention-gate and SWA metadata names so existing models continue to load.

• Type GitHub release metadata by @JamieMagee in #15597
• Make GitCommitChecker strongly typed by @JamieMagee in #15598
• Retry corepack prepare and install on signature metadata errors from private registries by @kbukum1 in #15606
• Fix UV DependencyGrapher to detect nested uv.lock in monorepos by @thavaahariharangit with @Copilot in #15520
• Bump library/rust from 1.95.0-bookworm to 1.97.0-bookworm in /cargo by @dependabot[bot] in #15560
• Bump @sigstore/core from 3.1.0 to 3.2.1 in /npm_and_yarn/helpers by @dependabot[bot] in #15455
• Bump maven from 3.9.14 to 3.9.16 in /maven by @dependabot[bot] in #15127
• Support Bundler source cooldown in Dependabot cooldown flow by @robaiken in #15517
• Type shared release metadata by @JamieMagee in #15607
• Make Job strongly typed by @JamieMagee in #15608
• Type Job wire models by @JamieMagee in #15610
• Type Service and ApiClient by @JamieMagee in #15614
• Add support for calendar-based versions for Maven and Gradle by @yeikel in #14114
• Type error reporting by @JamieMagee in #15615
• Type updater dependency helpers by @JamieMagee in #15617
• ensure proper formatting when patching element attributes by @brettfo in #15629
• Bump ws from 8.18.3 to 8.21.1 in /npm_and_yarn/helpers/test/npm/fixtures/vulnerability-auditor/update-needed-across-two-versions by @dependabot[bot] in #15329
• Bump lodash from 4.17.23 to 4.18.1 in /bun/helpers/test/yarn/fixtures/conflicting-dependency-parser/deeply-nested by @dependabot[bot] in #14608
• Bump lodash from 4.17.23 to 4.18.1 in /npm_and_yarn/helpers/test/yarn/fixtures/conflicting-dependency-parser/deeply-nested by @dependabot[bot] in #14609
• Bump lodash from 4.17.23 to 4.18.1 in /npm_and_yarn/helpers/test/npm6/fixtures/conflicting-dependency-parser/deeply-nested by @dependabot[bot] in #14610
• Bump the dev-dependencies group across 1 directory with 2 updates by @dependabot[bot] in #14694
• Bump pip from 26.1.1 to 26.1.2 in /python/helpers in the pip group across 1 directory by @dependabot[bot] in #11830
• Bump yaml from 2.3.1 to 2.9.0 in /bun/helpers by @dependabot[bot] in #14535
• npm_and_yarn: group vulnerability auditor blocking-dependency messages by top-level ancestor by @thavaahariharangit in #15627
• Bump ip-address and socks in /bun/helpers by @dependabot[bot] in #14924
• Bump brace-expansion from 1.1.13 to 1.1.16 in /bun/helpers/test/yarn/fixtures/conflicting-dependency-parser/deeply-nested by @dependabot[bot] in #15634
• Bump brace-expansion from 1.1.13 to 1.1.16 in /npm_and_yarn/helpers/test/yarn/fixtures/conflicting-dependency-parser/deeply-nested by @dependabot[bot] in #15633
• Bump sigstore/cosign/cosign from v3.1.1 to v3.1.2 in /docker in the regclient group across 1 directory by @dependabot[bot] in #15621
• Bump lodash from 4.17.23 to 4.18.1 in /bun/helpers/test/npm6/fixtures/conflicting-dependency-parser/deeply-nested by @dependabot[bot] in #14606
• Bump @tootallnate/once from 2.0.0 to 2.0.1 in /bun/helpers by @dependabot[bot] in #15107
• Bump the "uv-ecosystem" group with 1 update across multiple ecosystems by @dependabot[bot] in #14969
• Bump ip-address and socks in /npm_and_yarn/helpers by @dependabot[bot] in #14923
• Bump yaml from 2.3.1 to 2.9.0 in /npm_and_yarn/helpers by @dependabot[bot] in #14533
• Bump golang.org/x/mod from 0.37.0 to 0.38.0 in /go_modules/helpers by @dependabot[bot] in #15559
• Bump @sigstore/verify from 3.1.0 to 3.1.1 in /npm_and_yarn/helpers by @dependabot[bot] in #15477
• julia: don't propose compat updates for workspace packages or synthesize member compat entries by @IanButterworth in #15643
• fix: guard against unparseable versions in cooldown fallback by @currantw in #15632
• Type dependency requirement readers by @JamieMagee in #15646
• v0.388.0 by @dependabot-core-action-automation[bot] in #15623

New Contributors

• @currantw made their first contribution in #15632

Full Changelog: v0.387.0...v0.388.0

The post Build an LLM Agent That Can Write and Run Code appeared first on Towards Data Science.