Read more of this story at Slashdot.

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.

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

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

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

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

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

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

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

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

Android MCP powered by AppFunctions

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

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

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

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

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

How we accelerated development with Android skills

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

Providing app features to the intelligence system

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

Configuration and dependency setup

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

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

Modeling custom data types

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

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

Providing features using the @AppFunction annotation

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

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

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

The service entry point and Hilt integration

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

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

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

Testing and verifying your AppFunctions

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

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

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

Wrapping it up

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

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

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

Learn more

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

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

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

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

Read more of this story at Slashdot.

Read more of this story at Slashdot.

Read more of this story at Slashdot.

Read more of this story at Slashdot.

Read more of this story at Slashdot.

Every weekday, Matt, a software engineer, looks forward to his four-hour train commute to Pawling, New York. It’s time he uses to work on his own project: a browser-based video game for which he writes every line of code himself.

“I am actively trying to keep my axe sharp,” said Matt, who did not want to use his actual name, to protect his employment. In the last six months, Matt’s job has increasingly shifted away from coding, problem solving and software architecture towards reviewing code generated by artificial intelligence. Convinced that the shift will weaken his skills, he’s doing what he can to keep them intact. “I am trying not to leverage AI where I can.”

Read more of this story at Slashdot.

Read more →

The post Google gives developers an AI bug hunter that also writes patches appeared first on IT Security News.

The post Google gives developers an AI bug hunter that also writes patches appeared first on Help Net Security.

Read more of this story at Slashdot.

“Our founder and CTO has actually been really pushing to enable our agents in YOLO mode,” Rishi told the audience. That admission comes from a publicly traded data security firm whose business is backing up what he called the most important data in the world.

YOLO mode strips the permission prompt out of agent workflows and lets the agent act on its own. In Rubrik's version, a second AI judges every action in real time against policy in place of a human clicking approve. Rubrik is running the experiment on itself first. Rishi treats autonomy as a settled capability question and an open judgment question. "If you ask the agent to act autonomously, it will," he said. "It's a question that you have internally. Should it?"

Rubrik earned that question the hard way. When Claude Code and Cowork pilots rolled out, the company required every command to run in ask mode so the employee issuing it carried the liability, and the developer pushback filled a single Slack thread 120 messages deep.

"The developers basically are pushing back, and they're like, this is like the iTunes service agreement. I'm just hitting check, check, check, check, check, check, check," Rishi said. "There's no way that I can actually read through this. And it becomes security theater." Roughly 80% of respondents are in the same bind, Rishi said, citing Rubrik Zero Labs research that found monitoring and approving agent actions takes more time than the agents save. The State of the Agent, the April report behind that figure, surveyed more than 1,600 IT and security leaders.

SAGE is the reason Rubrik trusts the bet. Short for Semantic AI Governance Engine, SAGE is the arbitration layer inside Rubrik Agent Cloud that watches every action an agent takes and reads the semantic intent behind it, then rules the action in or out against policies written in natural language. "We took what people said was human in the loop, a good idea, and we replaced it with AI in the loop," Rishi said, describing the pitch to security chiefs he characterized as skittish about non-deterministic systems.

Security approval, not cost, blocks AI ROI

Rishi’s path to Rubrik ran through Predibase, the generative AI infrastructure startup he co-founded and ran as CEO until Rubrik agreed to acquire it in June 2025. Before that, he led ML product at Google on the team that became Vertex AI, served as Kaggle's first product manager as it grew from about one million to ten million users, and holds bachelor's and master's degrees in computer science from Harvard.

Over roughly his first three and a half months at Rubrik, Rishi set up 200 customer conversations with IT and security leaders across a customer base that looks like the Global 2000, asking open-ended questions about cost, latency, performance, and orchestration. "Pretty consistently, what I heard through all of those conversations was that all of those are pretty secondary," he said. "The main challenge is actually, how do I get this approved from a security and risk standpoint? I'm concerned about all the different things that could go wrong. Actually, I felt like that was one of the biggest things constraining ROI."

VentureBeat Pulse research presented on the Transform stage earlier in the day confirms the gap Rishi kept hearing. Two-thirds of enterprises, 66%, already allow or are actively building toward production deployment with zero human review, yet only 5% fully trust the automated evaluations that would make that decision.

One AI reading what the rulebook can't

Rubrik's own policies exposed why written rules fail as enforcement. One internal rule states that agents should respect Rubrik's customer data use policy, which sounds enforceable until someone tries. "Rubrik's customer data use policy is like a three-page document of legal text," Rishi said. "I have no idea how to write that in there as a rule." Asked on stage how a team of AI infrastructure people took on a problem that security engineers own, Rishi answered, "with a lot of naivety and innocence, honestly." His team bet that models good at understanding language could police other models, and SAGE became the answer.

The case for putting a model in the judgment seat comes down to precision. A rule like "agents should not be able to edit revenue fields in Salesforce" fails in conventional tooling because Salesforce does not delineate which fields count as revenue, Rishi explained, so administrators fall back on approving every Salesforce action by hand. SAGE reads the intent instead and acts as a judge, carrying organizational context, which can tell a benign lookup from the edit the policy prohibits.

Keeping the judge small is what makes the economics work. SAGE runs on a small language model that Rishi said operates at an order of magnitude lower cost and latency than a frontier LLM. "If I told you, don't worry, you're gonna be secure and governed, but I'm gonna double your cost and latency, you would tell me to get out of the room," Rishi said.

When Rishi asked who in the audience had worried about token consumption over the past year, half the hands went up. "And I guess the other half is probably just too lazy to raise their hand," he said.

SAGE is an aggregation of judges based on parameter-efficient fine-tuning that Rubrik uses to take on task-specific variants of a base model with shared organizational context. One judge watches for tool-use hallucinations while another suppresses PII before it can leave, each running as its own enforceable policy. Security and GRC teams have started writing financial rules into the same layer, including one internal policy barring AI spend on personal projects.

The lethal trifecta

Asked which attacks worry him most, Rishi pointed at the lethal trifecta, the term security researcher Simon Willison coined in June 2025 for an agent that holds private data while taking in content nobody vetted, with a channel to send what it finds to the outside world. The danger, according to Rishi, is what happens when individually legitimate permissions stack. An agent granted Salesforce access and email access on an employee's credentials has done nothing wrong yet, with yet being the operative word. "A very simple example is that an agent can start pulling data from Salesforce and then decide to accidentally leak and exfiltrate that out via an email," he told the audience. A financial services company he met the morning of the session made the point for him, telling Rishi that none of the individual permissions are bad on their own and the agent needs every one of them to do its job. "It should have permission to each of those systems, but it's the combination that ends up becoming really destructive," Rishi said.

Traditional identity and access management never priced in that combination because it relied on the judgment of the employee holding the credentials, Rishi argued, and agents supply none. "I can tell you the number of times Claude Code has tried to leak some of our sensitive source code to a public GitHub repository is incredibly high," he said. Cutting agents off from public resources entirely would defeat their purpose, which returns the problem to adjudicating intent in context rather than revoking access.

A separate VentureBeat June Pulse survey of 107 qualified enterprise respondents maps the blast radius of exactly this pattern. On the Transform stage that morning, VentureBeat research reported that 69% of companies run credential sharing somewhere in their agent fleet. Companies with shared credentials anywhere got hit more often, reporting a security incident or near-miss at a 63.5% rate (47 of 74), against 40.9% (9 of 22) where every agent carries its own scoped identity.

The attacks no single turn reveals

Rubrik Agent Cloud reached general availability in February, though not everything Rishi described ships in it yet. Backtesting is just starting to roll out. The feature replays an organization's historical agent actions and tool calls against a new policy, showing where the policy would have stepped in and where an action would have sailed through uncaught, with policy edits applied in real time. Rishi called that archive one of the most valuable data troves an enterprise holds.

Real-time detection and blocking turn out to be the entry point rather than the whole product. Some attacks never trip a single-action rule. "No individual turn of the conversation was problematic, but if you took the session as a full trace, that ended up being problematic," Rishi said. Agent Cloud runs batch analysis across entire session traces every hour or every day and surfaces what Rubrik calls insights, the problems no individual guardrail caught. The same Zero Labs report found that 88% say they lack the ability to roll back agent actions without system disruption, a recovery gap that sits squarely in Rubrik's original line of business.

A skeptical CISO will ask the question the fireside did not answer. SAGE is a non-deterministic model policing other non-deterministic models, and Rishi offered no false positive or false negative rate for the judge itself. The closest thing the architecture gives to an answer is auditability, since backtesting and the batch insights both leave a human-reviewable trail of each call SAGE made and whatever got past it. Who watches the watcher, for now, is a trail of receipts rather than a benchmark. Until that benchmark exists, AI in the loop stays an operational wager rather than a quantified control.

Three questions fall out of the session for security teams. How many of the guardrails now in production depend on a human clicking approve, and what happens to that workload as agent count grows? Does anything in the stack enforce semantic intent, or is it all allow and deny lists? And can the team backtest agent behavior against a new policy, then unwind a multi-turn session without taking systems down?

Rishi's timing has a market behind it. In the same VentureBeat research, 82% of enterprises still name their primary AI provider's built-in guardrails and cloud controls as their main agent security layer, and 59% plan to adopt, add, or replace agent security tooling within the next 12 months. Only 12% include an agent-identity product in what they are considering, even with credential sharing still the norm. Every CISO at that Anthropic roundtable had a policy document and no enforcement mechanism, and Rubrik built a product for the space between the two. YOLO mode is the bet that an AI watching other AIs can finally make the policies real.

Read more →

The post Is Patching Dead? Vulnerability Management in the Post-Mythos Era appeared first on IT Security News.

The post Is Patching Dead? Vulnerability Management in the Post-Mythos Era appeared first on SecurityWeek.

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.

Artikel & Newsletter: https://digitaleprofis.de/die-ki-news-der-woche-vom-23-07-2026/

Quellen
OpenAI-Modelle hacken Hugging Face 
Artikel: https://openai.com/index/hugging-face-model-evaluation-security-incident/ 
Hintergrund: https://huggingface.co/blog/security-incident-july-2026 

Digitaleprofis.de hat ein Update bekommen 
Website: https://digitaleprofis.de/ 

Kimi K3 ist da 
Artikel: https://www.kimi.com/de/blog/kimi-k3 
Artikel: https://apnews.com/article/kimi-k3-china-ai-0d8a5e268deb11a673f4d444fc597cc5 
Ausprobieren: https://www.kimi.com/ 

Neue Gemini Modelle 
Artikel: https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-6-flash-3-5-flash-lite-3-5-flash-cyber/ 
Modellkarte: https://deepmind.google/models/model-cards/gemini-3-6-flash/ 
Cyber-Modell: https://deepmind.google/blog/introducing-gemini-3-5-flash-cyber/ 

Neue Kennzeichnungspflichten des EU AI Acts 
Artikel: https://digital-strategy.ec.europa.eu/en/news/commission-publishes-guidelines-transparency-obligations-providers-and-deployers-certain-ai-systems 
Doku: https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act 

Anthropic zahlt 1,5 Milliarden Dollar 
Artikel: https://m.investing.com/news/stock-market-news/us-judge-approves-anthropics-15-billion-settlement-of-copyright-lawsuit-4801706?ampMode=1 
Artikel: https://apnews.com/article/74b140444023898aeba8579b6e9f0d63 

NotebookLM wird zu Gemini Notebook 
Artikel: https://blog.google/innovation-and-ai/products/gemini-notebook/notebooklm-gemini-notebook/ 

Microsoft und Mistral Partnerschaft 
Artikel: https://news.microsoft.com/source/2026/07/21/microsoft-and-mistral-expand-strategic-partnership-to-give-enterprises-and-regulated-industries-frontier-ai-they-can-control/ 
Artikel: https://www.tagesschau.de/wirtschaft/unternehmen/microsoft-mistral-ai-ki-deal-100.html 

Qwen-Audio-3.0-TTS 
Artikel: https://www.alibabacloud.com/blog/qwen-audio-3-0-tts-more-multilingual-easier-to-direct_603379 
Doku: https://docs.qwencloud.com/developer-guides/speech/tts-models 

OpenAI-Modelle überwinden bei einem internen Sicherheitstest ihre isolierte Testumgebung und gelangen bis in die Produktionsinfrastruktur von Hugging Face.
Wir ordnen den Vorfall ein und fassen die weiteren wichtigen KI-News der Woche kompakt für euch zusammen.

Außerdem geht es um Kimi K3, drei neue Gemini-Modelle, die kommenden Kennzeichnungspflichten des EU AI Acts und den milliardenschweren Urheberrechtsvergleich zwischen Anthropic und Autoren.

Im Video:
- OpenAIs ungewöhnlicher Sicherheitsvorfall bei Hugging Face
- Kimi K3 und drei neue Gemini-Modelle
- Kennzeichnungspflichten des EU AI Acts ab August 2026
- Anthropics Vergleich über mindestens 1,5 Milliarden US-Dollar
- Gemini Notebook, Microsofts Mistral-Partnerschaft und Qwen-Audio-3.0-TTS

Unsere Website wurde ebenfalls vollständig überarbeitet. Auf digitaleprofis.de findet ihr unsere KI-News mit allen Quellen, ausführliche Artikel und praktische Anleitungen – kostenlos, ohne Paywall und ohne Werbung.

Werde Kanalmitglied und unterstütze damit unsere Arbeit:
https://www.youtube.com/channel/UCv90NdTyTp7ZPPRvvSZaS5w/join

Videoinhalt:
00:00 Die KI-News der Woche vom 23.07.2026
00:24 OpenAI Modelle greifen HuggingFace an
02:06 Unsere neue Website für euch
02:59 Kimi K3 ist da und die USA werfen Diebstahl vor
04:28 Drei neue Gemini Modelle, aber kein Pro
05:53 Die neuen Kennzeichnungspflichten des AI Acts
07:21 Anthropic muss 1,5 Milliarden Dollar Vergleich zahlen
08:48 NotebookLM verschwindet - und wird zu Gemini Notebook
09:30 Partnerschaft von Microsoft und Mistral
10:50 Neuen Text to Speech Modell von Alibabas Qwen

Videovorschläge, Feedback und Kritik kannst Du uns jederzeit in den Kommentaren mitteilen!

Read more of this story at Slashdot.

• Changed /code-review to run as a background subagent, so review work no longer fills your conversation and keeps stacked slash commands as its review target
• Added screen-reader announcements of deleted text for word and line deletions (Option+Delete, Ctrl+W, Cmd+Backspace, Ctrl+U, Ctrl+K) in --ax-screen-reader mode
• Fixed Windows paths with \u-prefixed segments (like C:\Users\unicorn) being corrupted into CJK characters in tool inputs, which made those files inaccessible
• Fixed the left arrow key discarding the conversation with no undo: presses right after editing now ask to confirm, and Esc in the agent view returns to the conversation it backgrounded
• Added HTTP status and error text to claude mcp list and /mcp when a server fails to connect, and a warning for MCP config values with hidden leading or trailing whitespace
• Fixed multi-line paste collapsing into one line with j in place of newlines in terminals that encode pasted newlines as Ctrl+J
• Fixed /context reporting stale pre-compact token usage after compacting from the message picker
• Fixed /ultrareview failing on descriptive arguments like "review my auth changes" — they now run a review of your current branch with the text applied as a note to the findings
• Fixed /code-review ultra silently running a local review in non-interactive sessions — it now launches the cloud review
• Fixed gateway spend metering to price Bedrock application-inference-profile ARNs and other config-mapped upstream model IDs at the configured model's rates
• Fixed mojibake when a long IDE selection was truncated mid-emoji, and a case where a tool executor error could be silently dropped
• Fixed an engine teardown race that could start and abandon a phantom turn, and made input pushed after close consistently rejected
• Fixed spurious "[Request interrupted by user]" messages after interrupted tool calls, and an unpaired tool_use block left in the transcript when a tool aborted mid-response
• Fixed VoiceOver reading "new line" instead of echoing the typed space at the end of the input in --ax-screen-reader mode
• Fixed plugin and settings panels not moving the terminal cursor to the focused row, so screen readers and magnifiers can follow arrow-key navigation
• Fixed crashes (maximum call stack exceeded) when a deeply nested watched directory tree was deleted or moved, and when rendering deeply nested UI trees
• Fixed pull request events occasionally being lost when a session exited immediately after creating or linking a PR
• Fixed the Bedrock setup wizard failing profile verification for assume-role profiles in partitioned AWS regions and on proxy-only networks
• Fixed rare negative or incorrect turn duration measurements after a system clock adjustment by timing turns with a monotonic clock
• Fixed the "N MCP servers need authentication" startup notice over-counting claude.ai connectors that aren't connected in claude.ai
• Fixed prompt history entries being dropped or duplicated when history writes raced or failed
• Fixed a retry loop that re-sent identical doomed requests after a context-overflow error with a large thinking budget; Ctrl+B backgrounding now applies the same background-shell caps as other paths
• Fixed agent frontmatter hooks running from untrusted folders: hooks now require the agent file's own folder to have accepted workspace trust
• Fixed fork-session lineage being lost after compaction in headless and SDK sessions
• Fixed a resumed session failing every turn, or crashing on resume, when its history held a malformed delta attachment
• Improved /ultrareview error feedback so Claude can correct an invalid argument instead of retrying it unchanged
• Improved auto mode: the dangerous-rm, background-&, and suspicious-Windows-path checks no longer open permission dialogs; the auto-mode classifier adjudicates them instead
• Improved sandbox command restrictions for IDE interactions
• Improved trust dialogs to name the repository root the grant covers
• Changed /deep-research to start only when invoked manually; Claude no longer launches it on its own
• Changed plan mode with auto to no longer prompt for Bash commands the static analyzer can't prove read-only; the auto-mode classifier judges them instead
• Added an announcement when fast mode changes as a result of switching models via /config model=<x> or Remote Control
• Changed server-managed settings so benign feature and cost toggles no longer trigger the settings-approval prompt
• Changed agent markdown files to reject agent names containing :, which is reserved for plugin namespacing
• Changed skills with context: fork to run in the background by default; opt out per skill with background: false
• Added yes/no/on/off/1/0 (case-insensitive) as accepted values for skill and plugin frontmatter booleans, alongside true/false
• Fixed remote sessions continuing to send heartbeats after their worker was replaced, which left long-lived desktop and IDE processes retrying a rejected request every few seconds forever

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Can a diminished Inflection compete with AI giants spending billions?

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

The skeptic's case is easy to make. Inflection is a fraction of its former size, competing for consumer attention against products from companies spending tens of billions of dollars a year. Pi's model was state of the art in 2023; it is not in 2026. And "relational intelligence" is, for now, a brand claim awaiting proof.

But the bull case is not crazy either. Inflection's own research shows consumers already juggle multiple AI tools and choose them for qualities — tone, emotional understanding, personalization — that frontier labs treat as afterthoughts. The company kept its technology, its Microsoft licensing windfall, and a defensible enterprise niche in on-premise, emotionally intelligent deployments. And it is targeting the one consumer segment — everyday, mobile-first, voice-first life management — that the coding-obsessed giants have largely ignored.

Asked what success looks like twelve months from now, White declined to talk numbers. "It's less about scale for scale's sake and more about scaling for impact by empowering people and improving their lives," he said. "Over the next year, success means leading the market towards relational intelligence and transforming AI interactions from transactional to relational."

Two years ago, Microsoft walked away with Inflection's founders, its staff, and its shot at the frontier — but it left behind the one idea the giants still haven't figured out how to build: an AI that knows the people in your life matter more than the tasks on your list. Inflection is betting the company, again, that the idea was the valuable part all along.

Added

• SNI scanner (Scanner → SNI Scanner). Finds SNI/front hosts that work on your network via real TLS handshakes. Domain mode tests a list of candidate domains as SNI on :443; Range mode tests one SNI across an IPv4 CIDR range (bounded). Working hosts can be applied as your custom SNI hosts (used by fronted webtunnel/meek/snowflake bridges) or saved to the library. Green = handshake completed (usable), red = blocked/reset.
• Saved-bridges library (Scanner → Saved). Bridges from the bridge scanner and hosts from the SNI scanner can be saved to a persistent library, then labelled, re-applied or removed later - scan results are no longer lost when the scan finishes. Both scanners gained a Save to Library action.
• Current Bridge tab: per-row copy + sortable columns (#69). Each bridge row has a one-tap copy button, and the Type / Address / Status headers sort on click (click again to reverse); the bridge currently in use stays pinned to the top.
• Bridge copy/export refinement (#56). Copy on the Current Bridge tab now returns only the bridge Tor is actually using (not the whole supplemented list), and Export writes a CSV with Type, Address, Status, Fingerprint and the raw line.
• CLI scan <type> --use. After probing, the reachable bridges are saved as your custom list and selected as the source, so the next connect uses exactly those - the command-line equivalent of the GUI scanner's Apply button.

Fixed

• Custom bridge source ignored under Smart Connect (#70). Smart Connect (on by default) reset the source to Auto and dropped your custom bridge list while racing its own transports, so a pasted obfs4 bridge could end up connecting via a webtunnel bridge you never added. Smart Connect now honors an explicit Custom source and uses exactly those bridges.

Thanks to @Airuop for the scanner and bridge-tab suggestions.

Downloads

Not sure which Mac you have? Apple menu > About This Mac. "Apple M1/M2/M3/M4" means Apple Silicon (arm64); anything listing an Intel processor needs the x64 build.

Read more of this story at Slashdot.

The post Google Chrome Update Fixes 12 High-Severity Vulnerabilities That Enable Browser Attacks appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

• Added emoji shortcode autocomplete in the prompt input: type :heart: to insert ❤️, or :hea for suggestions — disable with the emojiCompletionEnabled setting
• Added warnings when transcript writes are failing (e.g. disk full) or when session saving is off due to an inherited environment variable, instead of losing transcripts silently
• Fixed a memory leak where truncated MCP tool outputs kept the full untruncated result in memory for the rest of the session
• Fixed Windows auto-update failures that could leave claude.exe missing; failed updates now restore the preserved executable automatically
• Fixed background session isolation not canonicalizing symlinked working directories, which could let sessions escape their workspace folder
• Fixed auto-compact never triggering for Claude Opus 4.8 on Bedrock and /compact failing once over the limit
• Fixed corporate mTLS, TLS-verify, OAuth scope, and proxy settings being ignored in Claude Desktop sessions
• Fixed screen reader mode's startup announcement being cut off by the first prompt render, and the thinking status row re-rendering every few seconds to update elapsed time and token counts
• Fixed managed settings that set OTEL_EXPORTER_OTLP_ENDPOINT not governing all signals — lower-scope signal-specific overrides no longer redirect telemetry away from the managed endpoint
• Fixed --resume/--continue and /resume failing with a TypeError when a transcript has a malformed attachment entry
• Fixed Remote Control sessions not showing a pending permission prompt or dialog to viewers that connected after it appeared
• Fixed background shells sometimes becoming impossible to stop after a session is sent to the background (/background or ←) or when the session exits on a heavily loaded machine, most visible on Windows
• Fixed a CLAUDE.md or SKILL.md paths frontmatter value with many brace groups OOM-killing or stalling the CLI at startup — brace expansion is now budget-bounded
• Fixed the transcript preview sitting flush against the input area when attaching to a starting background session; it now leaves the same one-line gap as the live layout, so the transcript no longer shifts when the session takes over
• Improved footer PR badge links to be clickable hyperlinks even when terminal support can't be detected (e.g. over ssh/tmux); set FORCE_HYPERLINK=0 to opt out
• Changed the login-expiry warning to appear 3 days before expiry instead of 5
• Capped the frontend-design plugin suggestion tip at 3 lifetime impressions instead of repeating indefinitely
• Added a cap on concurrently-running subagents (default 20, override with CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS) so one message can't fan out unbounded background agents
• Changed subagents to no longer spawn nested subagents by default; set CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH to allow deeper nesting
• Fixed --max-budget-usd not stopping background subagents: once the cap is reached, new spawns are denied and running background agents are halted

Read more of this story at Slashdot.

Read more of this story at Slashdot.

Read more →

The post Critical Gitea Vulnerability Enables Private Repository Writes and Actions Workflow Triggers appeared first on IT Security News.

The post Critical Gitea Vulnerability Enables Private Repository Writes and Actions Workflow Triggers appeared first on Cyber Security News.

In late 2024, in a quiet suburb of Stockholm, a 14-year-old boy approached a man in his 80s who was using a walker. He stabbed the man three times in the back.

The video of the attack in Hässelby was streamed and spread quickly. It fed a global online ecosystem that actively encourages and glorifies acts of violence and degradation – the “gamification of harm”, as the researcher Marc-André Argentino puts it.

ether

This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems.

I frequently find myself reaching for the cut utility when writing scripts to extract one piece of data from a line, or to select specific fields from a log file. While I am familiar with its counterpart, paste , I don't employ it very often because I don't typically need its functionality.

This perhaps has to do with the fact that I rarely work with text files containing lists. For shorter lists, I usually end up using a spreadsheet and for larger ones, a relational database. Both are valuable tools with their own strengths and weaknesses, but it is good to also know about standard utilities for working with lists. After uploading UNIX Curio #8 ( HPR episode 4657 ), I felt like maybe I had been too dismissive of the comm utility in that episode and should talk more about tools that are useful when managing lists.

I don't frequently find myself using paste ¹ , but can explain how it works. Briefly, it is a rough opposite of cut —when given multiple files as arguments, it assembles the first line from each one separated by tabs, then the second line, and so on. Instead of tabs, a different delimiter can be chosen with the -d option. Another option is -s , which swaps rows and columns so that the contents of each named file would appear on one line. While paste itself doesn't qualify as a UNIX Curio in my opinion, there is one feature that does: a hyphen can be given as an argument multiple times. In this special case, the output is taken line by line from standard input, but is spread across as many columns as there are hyphens.

Example of using paste to turn the output of ls into columns. Because these columns are separated by tabs, they don't necessarily line up when a filename is eight or more characters long. The -1 is not required for the second ls command since that behavior is implied when output isn't going to a terminal. The -C option to ls usually gives nicer-looking output on a terminal—also, it lists in ascending order down by column. (Most implementations default to -C when output goes to a terminal.) If you want items ascending along rows like the paste example does, try ls -x instead.

$ ls -1 /proc/net
anycast6
arp
bnep
connector
dev
dev_mcast
dev_snmp6
fib_trie
fib_triestat
hci
icmp
icmp6
if_inet6
igmp
igmp6
ip6_flowlabel
ip6_mr_cache
ip6_mr_vif
ip_mr_cache
ip_mr_vif
ip_tables_matches
ip_tables_names
[...35 more entries not shown...]
$ ls /proc/net | paste - - - -
anycast6        arp     bnep    connector
dev     dev_mcast       dev_snmp6       fib_trie
fib_triestat    hci     icmp    icmp6
if_inet6        igmp    igmp6   ip6_flowlabel
ip6_mr_cache    ip6_mr_vif      ip_mr_cache     ip_mr_vif
ip_tables_matches       ip_tables_names ip_tables_targets       ipv6_route
l2cap   mcfilter        mcfilter6       netfilter
netlink netstat packet  protocols
psched  ptype   raw     raw6
rfcomm  route   rt6_stats       rt_acct
rt_cache        sco     snmp    snmp6
sockstat        sockstat6       softnet_stat    stat
tcp     tcp6    udp     udp6
udplite udplite6        unix    wireless
xfrm_stat
$ ls -C /proc/net
anycast6      if_inet6           l2cap      rfcomm        tcp
arp           igmp               mcfilter   route         tcp6
bnep          igmp6              mcfilter6  rt6_stats     udp
connector     ip6_flowlabel      netfilter  rt_acct       udp6
dev           ip6_mr_cache       netlink    rt_cache      udplite
dev_mcast     ip6_mr_vif         netstat    sco           udplite6
dev_snmp6     ip_mr_cache        packet     snmp          unix
fib_trie      ip_mr_vif          protocols  snmp6         wireless
fib_triestat  ip_tables_matches  psched     sockstat      xfrm_stat
hci           ip_tables_names    ptype      sockstat6
icmp          ip_tables_targets  raw        softnet_stat
icmp6         ipv6_route         raw6       stat
$ ls -x /proc/net
anycast6           arp              bnep               connector     dev
dev_mcast          dev_snmp6        fib_trie           fib_triestat  hci
icmp               icmp6            if_inet6           igmp          igmp6
ip6_flowlabel      ip6_mr_cache     ip6_mr_vif         ip_mr_cache   ip_mr_vif
ip_tables_matches  ip_tables_names  ip_tables_targets  ipv6_route    l2cap
mcfilter           mcfilter6        netfilter          netlink       netstat
packet             protocols        psched             ptype         raw
raw6               rfcomm           route              rt6_stats     rt_acct
rt_cache           sco              snmp               snmp6         sockstat
sockstat6          softnet_stat     stat               tcp           tcp6
udp                udp6             udplite            udplite6      unix
wireless           xfrm_stat

The paste command has limitations—the files you give it must all be already arranged in the same order, and if any file is missing a value, it must have a blank line so that subsequent lines will match up correctly. The files do not necessarily have to be sorted alphabetically, but whatever order they are in has to be the same. Check out HPR episodes 962 and 4201 for some more background on the paste utility.

Example of using paste with files where some values are empty. Bob works from home so doesn't have an office assigned, and the laboratory Carol works in doesn't have a phone. This relies on the fact that the same line number in every file relates to the same person/entry.

$ cat names
Alice
Bob
Carol
Dave
$ cat offices
203

Lab6A
117
$ cat phones
+1 212-555-1234
+1 919-555-2345

+1 212-555-1278
$ paste names offices phones
Alice   203     +1 212-555-1234
Bob             +1 919-555-2345
Carol   Lab6A
Dave    117     +1 212-555-1278

Our second UNIX Curio for today is a utility called join ² , which has a bit more sophistication. It operates on two files, which can have multiple columns, and combines them using the join field. By default, the first column/field in each file is the join field, and only entries that exist in both files are printed. The -1 and -2 options can be used to join on a different field, and -o selects specific fields to be output. To make it so lines with missing entries also appear, you need to use the -a option, but an actual empty string with separator won't be printed unless -o is also present and includes the field.

The default field separator character is one or more "blanks" in the current locale—for the POSIX locale, this means a space or a horizontal tab. The -t option selects a different character and also removes the treatment of multiple occurrences as a single separator, making it possible to have an empty field in one or both of the files. By default, a single space is used to separate fields in the output. If -t is given, the same character is used for separating fields in both input and output. You would need to pipe output through another tool like tr if you wanted to have a different separator in the output.

The join utility might be an improvement over paste in some cases, since the join field makes it a little easier to identify which entries match up across files. It is limited to operating only on two files (one of which can be standard input), so combining more than that requires either creating temporary intermediate files or chaining together join commands in a pipeline. Another requirement is that all files must already be sorted in the current locale.

Example showing how join can be used with two tab-separated lists. The LC_ALL assignment forces join to sort using the C (POSIX) locale instead of whatever might be set in your environment. The "@" on the header line has no special meaning; it is just there to make sure it sorts before any letters or numbers (in the C locale; it might not in other locales). Note that if -t were not specified, plist would be treated as having three fields because of the space separating the country code from the rest of the phone number.

$ export tab="$(printf '\t')" #To more easily use tab characters below
$ cat olist
@Name   Office
Alice   203
Carol   Lab6A
Dave    117
$ cat plist
@Name   Phone
Alice   +1 212-555-1234
Bob     +1 919-555-2345
Dave    +1 212-555-1278
$ LC_ALL=C join -t "$tab" olist plist
@Name   Office  Phone
Alice   203     +1 212-555-1234
Dave    117     +1 212-555-1278
$ LC_ALL=C join -t "$tab" -a 1 -a 2 olist plist
@Name   Office  Phone
Alice   203     +1 212-555-1234
Bob     +1 919-555-2345
Carol   Lab6A
Dave    117     +1 212-555-1278
$ #By default, join acts as if empty fields don't exist; use -o to include
$ LC_ALL=C join -t "$tab" -a 1 -a 2 -o 0,1.2,2.2 olist plist
@Name   Office  Phone
Alice   203     +1 212-555-1234
Bob             +1 919-555-2345
Carol   Lab6A
Dave    117     +1 212-555-1278
$ #The -e option sets a placeholder to use for empty fields
$ LC_ALL=C join -t "$tab" -e "(none)" -a 1 -a 2 -o 0,1.2,2.2 olist plist
@Name   Office  Phone
Alice   203     +1 212-555-1234
Bob     (none)  +1 919-555-2345
Carol   Lab6A   (none)
Dave    117     +1 212-555-1278

The brief description for join is "relational database operator"—I won't dispute that, but in my view it offers far fewer capabilities than people would expect from today's relational databases. I would imagine that when most people think of those they have Structured Query Language (SQL) in mind, which offers a lot more flexibility and functions to operate on data. However, I can see how join could be suitable for simple operations.

Our last UNIX Curio for today relates to the sort utility ³ . While, as you might expect, it is well-known for its ability to sort data, it has another feature that is more obscure. When used with the -m option, instead of sorting the files given as arguments, it merges them together. All of the files are expected to already be sorted—once combined, the list that is output will also be sorted. The order in which the files are named does not matter; it is not required for the contents of the first file to start before the second, just that both are sorted.

$ cat women
Alice
Carol
$ cat men
Bob
Dave
$ sort -m men women
Alice
Bob
Carol
Dave

Imagine that you organize an annual event and have a separate pre-sorted list of attendees' e-mail addresses for each of the past three years. You are planning this year's event and want to send out an announcement to all of these people, as they will probably be interested. The command sort -m -u 2023list 2024list 2025list would spit out a combined list that you can use for your e-mail blast. Because it is likely that some people would have attended in more than one year, I included the -u option—it removes any duplicate entries.

It is probably no surprise that the sort utility appeared early on—it was in 1971's First Edition UNIX, though it didn't gain the merging functionality until Fifth Edition ⁴ in 1973. What did come as a shock to me is that both cut and paste didn't show up until 1980 with System III ⁵ , and were actually preceded by join , which was in Seventh Edition UNIX ⁶ from 1979. I assumed that at least cut would have been around far earlier, given its usefulness and how firmly established it is, but I suppose it just seems to have been with us forever.

As mentioned, I don't typically manage data as text files containing lists, and I probably won't start using the join utility or these features of paste and sort very much. But it is still useful to know that they exist and how they work. Hopefully this episode has taught you a bit about them.

References:

1. Paste specification https://pubs.opengroup.org/onlinepubs/9699919799/utilities/paste.html
2. Join specification https://pubs.opengroup.org/onlinepubs/9699919799/utilities/join.html
3. Sort specification https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html
4. A Research UNIX Reader: Fifth Edition sort manual page https://archive.org/details/a_research_unix_reader/page/n19/mode/1up
5. System III paste manual page https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/man/man1/paste.1
6. Seventh Edition UNIX join manual page https://man.cat-v.org/unix_7th/1/join

Provide feedback on this episode.

Read more of this story at Slashdot.

• Added sandbox.filesystem.disabled setting to skip filesystem isolation while keeping network egress control
• Fixed a slowdown in long sessions where message normalization cost grew quadratically with the number of turns, causing multi-second stalls and slow resumes
• Fixed auto mode denying commands with "HTTP 401" classifier errors after the OAuth token expired or rotated mid-session
• Fixed AskUserQuestion telling Claude to continue even when your answer asked it to wait or explain first — free-text answers now get neutral wording
• Fixed Claude Code on the web re-asking the same question and dropping your answer after the session sat idle for a few minutes
• Fixed @-mentions silently attaching nothing after file-modifying hooks, vim dot-repeat of c-operators and paste, statusline running twice on resume, and resume-picker hangs on failure
• Fixed resumed background agent sessions reverting to the default agent: the agent's prompt and tool restrictions are now restored
• Fixed worktree-isolated subagents redirecting git into the shared checkout via git -C, --git-dir, or GIT_DIR/GIT_WORK_TREE
• Fixed worktree sessions landing in another project's leftover worktree when the working directory did not match the selected project
• Fixed background sessions whose worktree has no git repository being undeletable
• Fixed claude daemon stop --any potentially terminating an unrelated process via a stale legacy daemon lockfile
• Fixed Esc-Esc at an idle prompt not opening the rewind picker in long-running sessions with background tasks
• Fixed Bash command permission checking for compound statements with redirects inside && lists or negations
• Fixed pressing Ctrl+X twice in the agent list failing to delete a session, and deleted sessions reappearing when their background worker had died
• Fixed background subagents getting cancelled when a high-priority message arrives during their startup window
• Fixed mouse and focus garbage in the terminal while a GUI editor from /memory, /plan, /keybindings, or Ctrl+G is open; /memory no longer waits for the editor to close
• Fixed Claude-in-Chrome 403-looping on reconnect when the session's OAuth token lacks a required scope
• Fixed workflow saves and scheduled-task writes following a symlink at .claude, which could redirect writes outside the project
• Fixed MCP re-authenticate revoking working credentials before the new sign-in succeeds, and the reconnect needs-auth message in background sessions pointing at an unusable command
• Fixed read-only commands on Windows accessing network paths without a permission prompt
• Fixed Bash command parsing of non-ASCII characters to match real shell word boundaries
• Fixed PowerShell tool permission validation of commands containing invisible Unicode characters
• Fixed dialogs in fullscreen mode stretching past the right-hand edge of their panel
• Fixed the /config settings list in fullscreen mode clipping its keyboard-hint footer
• Fixed the transcript-mode (Ctrl+O) footer hint wrapping on terminals narrower than 104 columns
• Fixed the Prometheus metrics endpoint (OTEL_METRICS_EXPORTER=prometheus) emitting invalid # UNIT lines
• Fixed skills and commands changed during a session not appearing in the slash menu until restart
• Fixed plugin skills with a name frontmatter field losing their plugin prefix in slash-command autocomplete
• Fixed telemetry misreporting permission denials: failed permission-prompt requests no longer count as user rejections, and user interrupts are now reported as user aborts instead of rejections
• Improved the /fork confirmation to one line with the new session's name, claude attach id, and a note when the copy shares your checkout
• Improved validation of git and gh command arguments in the PowerShell tool
• Improved the /ultrareview diff-too-large error to show configured limits, measured diff size, and largest contributing files
• Improved /code-review ultra empty-diff message to name the exact base ref and suggest passing an explicit base
• Improved the spend limit adjustment prompt to show the server's reason when a spend limit change is rejected
• /context now shows an explicit warning when the conversation exceeds the context window, and a failed /compact displays as an error
• /rewind no longer restores or deletes files through symlinks or hard links at tracked paths and reports how many paths it skipped
• Background sessions: /mcp and /install-github-app now park a "needs input" request in the agent view when no client is attached
• Updated the bundled dataviz skill: reordered the default chart palette and fixed guidance that suggested direct labels for four-series charts
• [VSCode] Fixed right-to-left text (Arabic, Hebrew, Persian) rendering in the wrong order when mixed with English or code
• Fixed cloud sessions dropping the in-flight message when the session's container restarts mid-turn — the interrupted turn now re-runs on resume instead of leaving the session unresponsive

A new paper from researchers at Writer provides a solution that is accessible to engineering teams. The study takes a systematic look at optimizing the different components of the orchestration layer that wraps around the foundation model, aka the AI harness. 

By optimizing the harness, the researchers show dramatic reductions in tokens per task, a drop in cost-per-successful-task by up to 61%, and quality that holds steady, all without changing the underlying foundation model.

Because the harness is fully under the developer's control and requires no model fine-tuning, engineering teams can apply these findings to build highly cost-efficient AI applications.

The ROI crisis of tokenmaxxing

The current state of AI engineering is plagued by "tokenmaxxing," an industry trend where developers rely on massive context windows and brute-force token consumption as a substitute for good system design. 

Rather than engineering elegant workflows, developers have imported a reflex from traditional software development: generate, run, fail, stuff the error and more context back into the window, and retry. 

"Teams tokenmaxx because it's the cheapest fix in the moment, and because it's literally how most engineers work today," Waseem AlShikh, CTO and co-founder of Writer, told VentureBeat. Because this approach succeeds often enough on coding tasks, it has become the default reflex for every other agentic workload. The danger is that per-token price drops mask the underlying inefficiency. 

"Your invoice is tokens-per-task times price-per-token, and most teams only watch the second number," AlShikh said. "In agentic workloads, tokens-per-task compounds — every loop iteration re-transmits the growing context — and it compounds faster than prices fall. The price cut becomes an anesthetic. It masks the fact that the loop itself is bleeding."

Tokenmaxxing leads to several enterprise failure modes. Teams route simple tasks to premium frontier models by default. They use the LLM as a lazy search index, stuffing the context window with raw documents instead of retrieving exact answers. Most destructively, they build unconstrained agentic loops that spiral out of control when the model encounters an error. Because output tokens cost significantly more than input tokens across all major model providers, inefficient task execution acts as a silent budget killer.

The industry has introduced several efficiency techniques to curb these costs, but they largely fall short because they treat the model in isolation: 

• Prompt compression condenses input text to save space, but ignores how the system sequences those inputs across complex workflows. 

• Budgeted reasoning caps the computational steps a model can take, which often degrades output quality if the workflow isn't intelligently routed. 

• Terse coding forces models to output minimal code to save output tokens, but does nothing to solve inefficient tool calling. 

• Speculative decoding uses a smaller draft model to speed up a larger model's text generation, optimizing inference speed while failing to address bloated agent architectures.

These efforts fail because they optimize the engine while ignoring the transmission. They do not look at the orchestration layer, leaving underlying architectural inefficiencies unresolved.

Unpacking the harness: the levers of efficiency

The harness is the orchestration layer that routes, formats, and turns the underlying LLM into a working system.

The core levers of harness optimization include system prompt caching, interaction history compaction, tool management, retrieval strategies, and error management. These are the most accessible intervention points for engineering teams looking to improve AI performance. 

As the Writer researchers note in the study: “If the harness is the layer that composes model calls into work, it is also the layer that sets the price of work.”

Historically, developers have treated the harness as disposable glue code designed simply to connect an API to a user interface. The study signals that the harness must now be treated as a first-class object: a primary software artifact that requires its own testing, versioning, and rigorous design. 

For enterprises, this reframes the "own-versus-rent" decision. 

"Enterprises spend months on model evaluations and then rent their orchestration off the shelf — which means they're optimizing the smaller lever and outsourcing the bigger one," AlShikh said. "Whoever owns the harness owns your unit economics, and an open framework tuned for demos is not tuned for your invoice." 

Inside the experiments

To isolate the impact of the orchestration layer, the researchers ran experiments on six foundation models spanning multiple vendors and weight classes: Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1, and Writer’s own model, Palmyra X6. 

Their experiments compared a frozen, conventional production agent loop against the finished Writer Agent Harness on the same 22 locked enterprise tasks, spanning capabilities like grounding and retrieval, multi-step workflows, tool use, and content generation. By holding the models and tasks constant, they could isolate the effects of the orchestration layer itself.

The optimized harness drove a significant drop in costs, cutting the blended cost per task by 41%, from 21 cents to 12 cents. This was largely achieved by slashing token consumption, with the number of tokens per task falling 38%, from 14.2k to 8.8k.

The harness is designed to delegate tasks like search to specialized sub-agents. A sub-agent receives only the tool and the specific query it needs, retrieves the exact data, and returns a capped, clean summary to the main agent — keeping the primary context window from filling up with raw search results.

Task success rates held steady even as token use fell — moving from 78% to 81%, a gain the researchers describe as directional rather than statistically significant at their sample size, meaning quality didn't suffer even as costs dropped.

End-to-end task latency also dropped significantly, reducing the median wall-clock time by 44%, from 48 seconds to 27 seconds, due to prompt caching and the elimination of dead-end reasoning loops.

However, the researchers also found limits to multi-agent orchestration. Smaller models like Gemini Flash 3.5 and Qwen 3.6 scored well below a usable reliability threshold on sub-agent delegation tasks (0.45 and 0.42, respectively) — the capability simply isn't dependable yet on lighter-weight models.

Sub-agent orchestration only crossed a usable reliability threshold on the two strongest models tested: Writer's own Palmyra X6 (0.86) and Claude Sonnet 4.6 (0.85).

The developer’s playbook: actionable takeaways and tradeoffs

The findings from the study translate into a playbook for enterprise developers building agentic workflows at scale. The first step is to implement what AlShikh calls the "Two-Zone Prompt" and "Context Offloading."

Structure for system prompt caching (The Two-Zone Prompt): Modern LLM APIs offer prompt caching, but developers must structure their payloads correctly to trigger it. Developers must separate the "stable zone" from the "volatile zone." Place static, unchanging elements (e.g., core rules, large tool schemas, and standard operating procedures) at the top of the prompt. Dynamic elements, such as the specific user query or recent conversational task state, must be appended at the bottom. This ordering allows the harness to reuse the cached prefix across hundreds of calls. "That single separation makes prompt caching actually work and stops you from re-paying for the same instructions on every one of an agent's thirty steps," AlShikh said.

Manage context with Context Offloading: Avoid context stuffing, where every turn of a loop is appended into a monolithic prompt until the window maxes out. Instead, move history and intermediate artifacts out of the window into retrievable storage, and pull back only what the current step needs. If possible, delegate tasks to single-purpose sub-agents to avoid context bloat. As AlShikh points out, "the biggest line item in agent spend isn't reasoning — it's re-sending things the model has already seen."

Build resilient loops and redefine KPIs: Unmanaged agent loops drain API budgets rapidly. Teams must begin tracking Completions Per Million tokens (CPM) to understand their true task costs, but the harness itself must contain physical guardrails. "The core principle is that you never ask the model to police its own spending," AlShikh said. "The fence has to live below the model, in code, on your side of the API." This requires three hard checks:

• Hard per-task token budgets: The run terminates when the budget is spent, no exceptions.

• Generation fencing: Caps on steps, tool calls, and recursion depth to stop non-converging agents. 

• Failure-spend governance: Cap what a run can spend after its first failed validation so a failing task doesn't become your most expensive task.

Avoid unnecessary complexity: Optimizing the orchestration layer comes with engineering overhead. If you're in the prototyping and exploration stage, that overhead isn't justified — iterate fast with a strong model and a light harness. Once you're scaling to millions of requests a day, the savings from harness optimization become substantial.

However, teams must be aware of "harness leverage." Adding structural scaffolding requires the model to hold and obey that context. If a model is too small, it will spend its limited capacity parsing the scaffolding instead of doing the task, causing accuracy to drop and tokens to rise. The rule for adding complex orchestration features is strictly mathematical: "If a feature adds more coordination tokens than it removes task tokens for that specific model, cut it," AlShikh said. "Nothing in the harness is free."

The future of the enterprise harness

The era of tokenmaxxing and treating context windows like bottomless buckets is coming to an end. Throwing more compute at poorly designed systems is not a viable strategy for companies that need to demonstrate a return on their AI investments. 

As foundation models evolve to absorb planning, tool selection, and multi-step reasoning natively into their weights, the role of the harness will shift from compensating for model weakness to enforcing enterprise policy.

"What never moves into the model is the 'allowed': budgets, permissions, data boundaries, audit trails, deterministic kill-switches," AlShikh said. "Five years from now, the harness will be thinner but more important. There will be less scaffolding and more governance. However capable the model gets, someone external to it still has to define what it may spend, see, and touch. That layer belongs to the enterprise, and it should never be rented."

Release Date: July 20, 2026
Since v0.18.0: ~2,245 commits · ~1,065 merged PRs · ~2,465 files changed · ~300,000 insertions · ~36,000 deletions · ~3,300 issues closed · 450+ community contributors

The Quicksilver Release. Hermes is the messenger god, and this window we made him move like it. First-turn time-to-first-token dropped ~80% on every platform, reasoning streams live by default, the desktop app got a ~20-PR speed overhaul (14× faster streaming markdown, virtualized diffs, snappy session switching), and the TUI renders markdown incrementally. Around that speed spine: you can now manage your Nous subscription without leaving the terminal, plug Bitwarden and 1Password straight into Hermes, let smart approvals judge flagged commands for you by default, watch your subagents work live, and trust that a finished response survives a gateway crash thanks to a durable delivery ledger. This release also rolls up everything from the v0.18.1 and v0.18.2 infrastructure patch tags — those windows are fully documented here.

✨ Highlights

• Hermes got dramatically faster — first token in a fraction of the time — Cold-start "Initializing agent..." used to eat ~4.3 seconds before your first turn even reached the model; it's now ~0.9s, an ~80% cut that applies to the CLI, gateway, TUI, desktop, and cron alike. Round 2 attacked what you see while waiting: reasoning models now stream their thinking live by default (no more staring at a spinner for 30 seconds), and the response box paints per token instead of per line. If Hermes ever felt like it took a deep breath before answering, that breath is gone. (#59332, #59389 — @teknium1)

• The desktop app speed wave — 20+ targeted perf PRs — Long replies used to cost 14× more CPU in the markdown splitter than they do now; giant diffs froze the review pane until we virtualized it; switching sessions thrashes layout no more. Streaming no longer re-renders the sidebar and every tool row per token, profile backends pre-warm on hover intent, and boot-hidden panes mount at idle instead of on the cold-start critical path. The net effect: the desktop app feels like a native app under load, even with huge transcripts and busy agents. (#67154, #67818, #65898, #66033, #66747, #67742 and more — @OutThisLife)

• Manage your Nous plan from the terminal — /subscription and /topup — Changing your subscription used to mean a trip to the billing website. Now /subscription opens a full flow right in the TUI or classic CLI: see your plan and remaining allowance, preview exactly what an upgrade costs ("Pay $46.30 & upgrade now") or when a downgrade takes effect, and apply it — with scheduled-change banners and undo. The desktop app got a matching billing settings tab. Your wallet never has to leave the keyboard. (#51639, #61054, #61067 — @alt-glitch)

• Smart approvals are now the default — When Hermes wants to run a flagged command, an LLM reviewer now assesses it independently instead of asking you to approve every single one — and each verdict covers only that exact command, so a later command matching the same pattern gets its own review. Combined with the new user-defined deny rules (which block commands even under yolo mode) and /deny <reason> (which tells the agent why you refused so it course-corrects), day-to-day approval fatigue drops sharply without giving up control. (#62661, #59164, #54518 — @teknium1)

• Plug your password manager into Hermes — Bitwarden & 1Password secret sources — API keys no longer have to live in a plaintext .env. A new pluggable SecretSource interface lets Hermes fetch secrets from Bitwarden and 1Password (op:// references) at load time, with multiple vaults enabled simultaneously, deterministic precedence, conflict warnings, and per-variable provenance. This consolidated eleven competing community PRs into one orchestrated interface — future vault providers drop in as plugins. (#59498 — @teknium1, 1Password provider salvaged from @hwrdprkns)

• Watch your subagents work — live transcripts + durable background delegation — delegate_task dispatches now return live transcript files you can tail -f the moment the subagents launch: every tool call, result, and streamed reply, one human-readable log per child. And background delegation completions are now durable — if the process restarts mid-run, results are restored and delivered through an ownership-checked ledger instead of vanishing. Fan out a fleet, watch any worker live, and never lose the results. (#67479, #63494 — @teknium1)

• A finished answer can no longer be lost — the delivery-obligation ledger — If the gateway died between generating your response and confirming the platform actually delivered it, that answer used to be silently gone (and you'd paid for the turn). Final responses are now recorded in a durable ledger in state.db around the platform send and redelivered on the next boot — closing a P1 silent-loss window for Telegram, Discord, Slack, and every other channel. (#67181 — @teknium1)

• One gateway, many profiles — profile-based message routing — A single multiplexed gateway sharing one bot token can now route specific guilds, channels, or threads to different profiles — each with fully isolated config, skills, memory, and secrets. Point your work Discord server at the work profile and your hobby server at personal, from one bot. A second multiplex hardening wave means one misconfigured profile can no longer take down the whole gateway. (#64835 salvaging @Burgunthy, #65700, #60589 — @teknium1, @benbarclay + six salvaged contributors)

• New providers and the newest frontier models — Fireworks AI and DeepInfra land as first-class providers (Fireworks with cost estimation and a #2 slot in the provider picker), Upstage Solar joins via salvage, and the model catalogs picked up GPT-5.6 (Sol/Terra/Luna + Pro variants, wired end-to-end across every route), grok-4.5 (GA), moonshotai/kimi-k3, claude-fable-5 / claude-sonnet-5, and GA tencent/hy3 — plus LM Studio JIT model loading for local setups. (#62593, #63969, #61616 — @kshitijk4poor completing @rob-maron's #61578, #60887, #65913, #64541, #65472)

• Crank the thinking to max — new reasoning effort tiers and per-model control — Reasoning effort gained max and ultra levels (GPT-5.6 and Codex's top tiers), selectable everywhere from the CLI to the desktop, with sane clamping on providers with smaller scales. You can now also pin per-model reasoning-effort overrides in config, set per-slot effort in MoA presets (your advisors think hard, your synthesizer stays fast), and per-task effort for auxiliary models. Thinking depth is now a dial, not a global switch. (#62650, #64458, #64631, #64597 — @teknium1)

• Your sessions, your data — export everything — hermes sessions export now writes Markdown, Quarto, HTML, prompt-only, and even Hugging Face-ready trace formats, with the full filter surface (age, workspace, platform), an opt-in --redact secret-scrubbing pass, and compacted-session lineage stitched into one logical export. Pair with the new prune filters and bulk archive to keep your session store tidy. Your conversation history is a real dataset now, not a black box. (#60186 salvaging @web3blind, #60492, #60507, #59327 — @teknium1)

• Security hardening round — This window closed a long list of credential-surface gaps: Vertex credentials scoped away from subprocess env and through profile secret scopes, media/vision/image-gen local-file reads routed through one shared credential-read guard, a webhook body-size-cap sweep across every aiohttp server, bot-token redaction in Telegram transport errors, Fireworks token prefixes added to the redactor, six P1 browser/MEDIA/.env hardening PRs salvaged in one pass, and CI hardened against untrusted-ref interpolation. (#57660, #58709, #59215, #56582, #57842 — @teknium1, @srojk34, @kshitijk4poor, @jquesnelle)

⚡ Performance — the speed spine

First-turn latency (all platforms)

• ~80% TTFT cut — Discord capability detection off the critical path (token-keyed 24h disk cache + background refresh), Ollama probe skipped for known non-Ollama providers, agent-init blocking work removed; cold submit→dispatch ~4.3s → ~0.9s (#59332 — @teknium1)
• Perceived-latency round 2 — display.show_reasoning default ON (watch the model think instead of a spinner), per-token response-box painting with width-aware force-flush, prompt-build caching, mtime-cached timezone resolution (#59389 — @teknium1)
• Segment mixed tool batches to recover lost concurrency; drop per-call base64 re-serialization from request-size estimates (#64460, #67788 — @teknium1, @OutThisLife)

Desktop speed wave

• 14× less splitter CPU via incremental block lexing for streaming markdown; virtualized review-pane diffs (no more full-Shiki freeze); snappy session switching on large transcripts; killed the layout-thrash cascade on session switch (#67154, #67818, #65898, #66033 — @OutThisLife)
• Cut startup serialization + per-turn REST amplification; pre-warm profile backends and gateway sockets on hover intent; idle-mount boot-hidden panes; fast model picker + dialogs (#66747, #66347, #67857, #66470 — @OutThisLife)
• Stop per-token sidebar + tool-row re-renders during streaming; stop eager JSON.stringify of every tool's args/result; scope tool-diff subscriptions; batch sidebar session slices into one profile-DB pass; targeted file-tree revalidation; rAF-coalesced sash resizes (#67742, #67842, #67195, #67245, #67824, #67838, #67844 — @OutThisLife)
• Systematized perf benchmark harness with trustworthy cold-start + first-token measurement, replacing 12 one-off scripts (#67466, #67697 — @OutThisLife)

Everywhere else

• TUI renders streamed markdown incrementally per block (#67236 — @OutThisLife)
• Skill discovery cached by scan signature; snapshot manifest builds ~5× faster; text prefilter before AST parse in tool discovery (#61414, #61131, #63941 — @kshitijk4poor, @ethernet8023)
• Copy-on-write message prep instead of full deepcopy; model-metadata probe-cache cluster; gateway session.resume model + display history from one SELECT (#61133, #61368, #67247 — @kshitijk4poor, @OutThisLife)
• hermes update skips npm install when Node manifests are unchanged; dashboard session-list payloads trimmed + messages paginated (#61580, #60883 — @kshitijk4poor)
• Byte-stable gateway system prompts — pinned session-context render keeps the prompt cache alive across turns (#67403 — @kshitijk4poor)

🏗️ Core Agent & Architecture

Providers & models

• Fireworks AI provider with cost estimation + cached picker price columns, promoted to #2 in provider pickers (#62593, #65476, #65214 — @teknium1)
• DeepInfra hardened integration; Upstage Solar provider (#42231 salvage) (#63969, #64541 — @kshitijk4poor)
• GPT-5.6 (Sol/Terra/Luna + Pro) end-to-end — context lengths, native/Codex catalogs, pricing, compaction caps across every route (#61616 — @kshitijk4poor, building on @rob-maron)
• grok-4.5 (GA) catalog + reasoning allowlist; kimi-k3 on Nous Portal + OpenRouter (kimi-k2.x retired) + K3 discovery on the Kimi Coding endpoint; claude-fable-5 / claude-sonnet-5 / fugu-ultra curated; GA tencent/hy3 (#60887, #65913, #65922, #56617, #60943 — @teknium1)
• Catalog-labeled silent default (GLM-5.2) + bare-provider /model cost-safe routing; LM Studio JIT load mode; adaptive thinking for Kimi-family Anthropic endpoints (#64771, #65472, #67606 — @teknium1, @kshitijk4poor)
• GLM-5.2 native reasoning_effort controls; Gemini request-context improvements; extra HTTP headers for LLM API calls; per-client model routing on the API server (#58884, #61873 — @vishal-dharm, #57038, #57028 — @teknium1)
• Claude Sonnet 5 fully wired — curated lists, intro pricing, and metadata across every route (#67932 — @teknium1)
• Hide providers you don't use — enabled: false per-provider flag + excluded_providers config scrub unwanted providers from /model pickers and built-in resolution (#67971 — @teknium1)
• Bedrock catalog wave: real context-window probing from the live endpoint, 1M-context rows for current-gen Claude + Fable, geo-prefix parity, versioned profile-ID pricing, Opus 4.8/4.7 rows (#68007, #67977, #68005, #67976 — @teknium1)
• kimi-k3 rollout completed across Kimi-direct catalog surfaces with 1M context on canonical Kimi Coding endpoints (#68108 — @teknium1)
• Provider pickers: Qwen providers folded into one group row; collapsible provider groups in the desktop model picker; friendlier TUI model display grouping same-endpoint providers (#67758, #67904, #67908 — @teknium1)

Reasoning & MoA

• max + ultra effort levels across every surface and route (#62650 — @teknium1)
• Per-model reasoning_effort overrides via a unified resolution chokepoint; per-task auxiliary effort; per-slot MoA preset effort; session-scoped /reasoning in the CLI (#64458, #64597, #64631, #67946 — @teknium1)
• MoA: reference_max_tokens to cap advisor output and cut latency; per-preset fanout cadence (user_turn runs advisors once per user turn); stale presets surfaced without retries; half-filled preset saves rejected at the API boundary; aggregator resolves reasoning like an acting model (#56756, #57591, #64756 — @teknium1)

Delegation, approvals & the agent loop

• Live subagent transcripts + durable background completions (see Highlights) (#67479, #63494 — @teknium1)
• Smart approvals default; user-defined deny rules (block even under yolo); /deny <reason> relays the denial reason; plugin pre_tool_call approve action escalates to a human gate (re-landed with rule keys) (#62661, #59164, #54518, #60504 — @teknium1, @kshitijk4poor)
• Unified delegation concurrency caps (max_async_children deprecated); explain long provider waits on the live status line; deterministic tool-output risk exposure (#56955, #64775, #61793 — @teknium1)
• Codex: live TUI/desktop tool cards for the app-server runtime, commentary streamed as visible interim messages, compaction routed through thread/compact/start, max-output truncation recovery, oversized message ids dropped on replay, banked usage-limit resets via /usage reset (#66514, #66115, #60114, #58155, #62225 — @teknium1, @kshitijk4poor, @JoaoMarcos44, #64280 — @teknium1)
• Hooks: oversized hook-injected context spills to disk (#20468 — @teknium1)
• Vibe reactions — floating hearts on affection across CLI/TUI/desktop, token-free core detection (#62016 — @OutThisLife)

Secrets & config

• Pluggable SecretSource interface + Bitwarden & 1Password providers (see Highlights) (#59498 — @teknium1, @hwrdprkns)
• hermes config get / unset; warn on unknown root config keys + doctor deprecated-key reporting; display.timestamp_format (#65540, #67370, #40622 — @teknium1)
• Auxiliary model usage recorded per task in session accounting; conversation-scoped Nous Portal usage tags across aux/MoA/delegate calls; --usage-file JSON report for hermes -z (#65537, #65468, #59615 — @teknium1)

Sessions & compression

• Sessions export: Markdown/QMD/HTML/prompt-only/trace formats, HF upload, --redact, unified filters; full prune filter surface + bulk archive; CLI workspace filter + restore-cwd-on-resume (#60186, #60492, #60507, #59327, #63091 — @teknium1, @web3blind)
• Compression: preserve human intent and durable handoffs; retain prompt cache when memory is unchanged; flatten multimodal content for the summarizer keeping image handles; gateway compression routing integrity (#67275, #67916, #65046, #56868 — @kshitijk4poor, @teknium1)
• Gateway session metadata consolidated into state.db; routing index moved to state.db (sessions.json now an optional legacy mirror); exact API bytes persisted in an api_content sidecar (#58899, #59203, #67274 — @teknium1, @kshitijk4poor)

🌐 Gateway, Fleet & Relay

• Durable delivery-obligation ledger for final responses (see Highlights) (#67181 — @teknium1)
• Profile-based routing for inbound messages + multiplex hardening wave 2 + GATEWAY_MULTIPLEX_PROFILES override (see Highlights) (#64835, #65700, #60589 — @teknium1, @benbarclay + salvaged contributors)
• Per-session turn lease + conversation-scope funnel; unified session reset boundaries (reset sessions stay reset); truthful runtime readiness checks; per-channel model and system prompt overrides; per-session /model overrides persist across restarts (#67401, #65783, #62645, #56967, #57030 — @teknium1)
• Session auto-reset default off; /sessions search <query>; webhook payload filters + route scripts; platform HTTP event callback routing; configurable long-running status phrases (#60194, #57685, #60944, #65702, #58872 — @teknium1)
• Relay: generic OIDC client-credentials provisioning (NAS-free), routed profile carried from the connector wire source, channel context consumed from the connector; Nous auth forensics + nous_session_valid on /api/status for hosted self-heal; Docker re-seeds a terminally-dead Nous bootstrap session on boot (#60730, #60586, #64649, #59976, #59969, #59983 — @benbarclay)

📱 Messaging Platforms

• Inline choice pickers for /reasoning and /fast on Telegram, Discord, and Matrix — one-tap native buttons instead of typing (#65799 — @teknium1)
• WhatsApp: native Baileys polls (clarify renders as a poll), locations, rich inbound metadata; dashboard pairing flow (#58865, #60571 — @teknium1)
• Discord: recover messages missed during reconnect; auto-created threads renamed to generated session titles; configurable interactive view timeout; opt-in owner mentions on exec-approval prompts; optional admin-only gate for approval buttons (#66149, #60187, #60230, #60493, #51751 — @teknium1)
• Slack: live per-tool status line (#67080 — @teknium1, salvaging #62007)
• Telegram: per-topic free-response allowlist; Google Chat clarify prompts rendered as cards (#65543, #65546 — @teknium1)
• Voice: stt.echo_transcripts toggle; MEDIA: captions attached to the media bubble on standalone sends; display.tool_progress: log option (#58859, #61415, #57014 — @teknium1, @kshitijk4poor)

🖥️ Hermes Desktop App

• Contribution-driven shell on a layout-tree model — panes, zones, and layouts as data; plugin-scoped i18n locale bundles followed (#60638, #67303 — @OutThisLife)
• Capabilities page — Skills/Tools/MCP + Hub in one place, with responsive overlay nav; CLI/dashboard parity for skills hub, MCP test/toggle/catalog, maintenance ops, log filters; five UX fixes from live testing (#57590, #57441, #67482 — @OutThisLife, @teknium1)
• Hermes Cloud connection mode (salvage of #55402); soft gateway switch + gateway-settings polish; terminal execution backend picker with health probes (#61912, #61916, #67203 — @OutThisLife, @teknium1)
• Keybind hint tooltips + keybinds settings tab + unified worktree dialog; base-branch picker for new worktrees; green unread dot for background-finished sessions; background-task sidebar indicators; grouped tool calls across text-less messages; auto-scrolling window for long tool-call runs (#65204, #62243, #65109, #65174, #61147, #57913 — @ethernet8023, @OutThisLife)
• Session + project color system (inherit from project, per-session override, shared across sidebar/tabs); unified active-project identity in chat status; workspace path status action (#67469, #67681, #67282, #63086 — @OutThisLife)
• Declarative memory-provider panel + full-config modal; config-defined TTS/STT providers + xAI TTS params; custom endpoint settings; per-job cron model picker; profile-aware approval mode control; UI scale setting; Ctrl/Cmd+wheel zoom; chat backdrop toggle; /journey opens the memory graph overlay (#67206 salvaging @erosika, #67209, #67759 — @austinpickett, #67472, #63520, #60457, #67029, #64598, #57267 — @teknium1, @OutThisLife)
• Full TypeScript conversion of the desktop tree (#57855 — @ethernet8023)