SonicWall customers are attempting to dodge another security challenge as attackers are exploiting a pair of zero-day vulnerabilities that have been confirmed by the vendor.
The company publicly disclosed the vulnerabilities — CVE-2026-15409 and CVE-2026-15410 — in a security advisory Tuesday. SonicWall credited an employee with discovering the defects, but it hasn’t said when the discovery occurred or the earliest known instance of exploitation.
Rapid7 researchers told CyberScoop both vulnerabilities were first exploited June 22. “From the cases that our team has observed, the goal is likely ransomware, though we have prevented the actors from achieving exfiltration and encryption,” said Seth Lazarus, senior manager of detection and response services at Rapid7.
Overlapping tactics, techniques and procedures from the attacks observed by Rapid7 indicate the same threat group or attacker discovered and exploited the zero-days, Lazarus added.
SonicWall did not answer questions about the impacts of these attacks thus far, and the company hasn’t attributed the attacks to a known group or described the attacker’s origins and motivations.
The vendor did, however, confirm to CyberScoop that both vulnerabilities have been chained together for exploitation. The vulnerabilities affecting SonicWall SMA1000 appliances, including a max-severity defect that allows attackers to make authenticated requests and a 7.2-rated vulnerability that allows authenticated command injection.
“When these two are chained, an attacker can go from zero access to a complete system compromise for the affected appliance,” said Landon Rice, senior exploit developer at VulnCheck.
Ben Harris, founder and CEO at watchTowr, said two characteristics of the vulnerabilities fuel a sense of dread. “Both were exploited as zero-days before fixes were available, and together they offer a plausible path to remote-code execution from the internet,” he said.
SonicWall encouraged customers to patch the vulnerabilities by upgrading to the latest software version, which it released upon disclosure, and shared some indicators of compromise to help customers hunt for potential malicious activity on their systems.
“Speed of response was a priority for us,” said Bret Fitzgerald, senior director of global communications at SonicWall. “Within days of becoming aware of the issue, our team had developed a script that we can run on behalf of affected customers to assist with resolution, and mitigation efforts are already underway.”
SonicWall and third-party researchers haven’t said how many SonicWall customers are impacted by the exploited vulnerabilities, but the vendor did say it already investigated multiple cases of active exploitation.
Fitzgerald said the company monitors about one million sensors globally and “SMA1000 appliances represent a very small subset of that footprint, less than 5,000 units.”
SonicWall said support staff are also helping customers work through instances of suspicious activity, warning that patching alone is not sufficient.
The vendor and its customers have been hit by a barrage of actively exploited zero-days and previously disclosed defects in SonicWall devices for years. In 2025, an undisclosed state-sponsored threat actor intruded the company’s cloud environment and stole firewall configurations of every SonicWall customer.
Seventeen defects affecting the vendor’s products have been added to CISA’s known exploited vulnerabilities catalog since late 2021. Ten of those defects are known to be used in ransomware campaigns, according to CISA, including a wave of about 40 Akira ransomware attacks between mid-July and early August.
“As always,” Harris said, “when something is confirmed as already exploited in the wild, patching is the bare minimum, and breach should be assumed.”
Microsoft’s monthly Patch Tuesday security program reached an unrivaled pinnacle this month, as the vendor addressed 622 vulnerabilities across its suite of business products and systems.
“The bug apocalypse has finally descended upon us,” Dustin Childs, head of threat awareness at Trend Micro’s Zero Day Initiative, wrote in a blog post Tuesday.
“The mother of all releases. To call this record-breaking is an understatement,” he added. “The CVE count year-to-date exceeds all other years’ totals.”
The startling increase in vulnerabilities reflects a compounding effect taking root across software as artificial intelligence plays a growing role in discovering and developing patches for defects lurking in error-riddled applications.
The company last week warned forewarned customers and defenders that a flood of defects would be uncovered as it applies its multi-model agentic scanning harness (MDASH) to discover and address vulnerabilities at greater speed and scale.
The monthly exponential rise in Microsoft vulnerabilities already puts the vendor on pace to break a full-year record, ending 2026 with the largest annual collection of defects, beating the previous record of 1,245 CVEs in 2020, Satnam Narang, senior staff research engineer at Tenable, said in an email.
“It’s probable that we will not only exceed 2,000 CVEs in a calendar year, but potentially over 3,000 CVEs this year or more,” he added.
“The volume is striking, but it reflects how good these tools have become at finding bugs, not how many of those bugs actually pose a risk to organizations,” Narang said.
Microsoft disclosed two actively exploited zero-day vulnerabilities — CVE-2026-56155 and CVE-2026-56164, privilege escalation defects in Active Directory Federation Services and Microsoft SharePoint Server, respectively.
The monthly batch of patches included 416 defects in Windows, 82 in Office and 46 in Microsoft Edge. More than 1 in 10 vulnerabilities the vendor disclosed — 63 total — were rated as critical.
“The products covered this month are also astonishing,” Childs said. “Just about everything you’ve ever heard of is getting patched.”
Rapid7 Labs conducted a zero-day research project against Microsoft SharePoint, resulting in the discovery of two new vulnerabilities that, when chained together, achieve unauthenticated remote code execution (RCE) against a vulnerable SharePoint server. Today, both Rapid7 and Microsoft are disclosing the first vulnerability in this chain, the authentication bypass vulnerability CVE-2026-55040. The RCE component of the exploit chain is expected to be patched by Microsoft in the next update cycle for August 2026. The exploit chain was developed as an entry for the recent Pwn2Own Berlin hacking competition – part of Rapid7 Labs' continued effort to raise the bar in Vulnerability Intelligence and our commitment to the preemptive protection of our customers through original vulnerability research.
A remote unauthenticated attacker can leverage CVE-2026-55040 to bypass authentication on a vulnerable SharePoint server and perform operations as a SharePoint site user or administrator. The vulnerability is due to several issues in the JWT token validation pipeline.
Microsoft SharePoint is a ubiquitous, web-based collaboration and document management platform deeply integrated into the Microsoft 365 ecosystem. Serving as the central hub for corporate intranets, internal file sharing, and workflow automation, it is trusted by enterprises worldwide to store and manage vast repositories of sensitive business data. Because SharePoint acts as a critical bridge between internal users, active directories, and cloud infrastructure, vulnerabilities within its architecture present a high-risk attack surface.
Impact
By leveraging CVE-2026-55040, a remote unauthenticated attacker can assume the identity of any SharePoint site user; the prerequisite is the attacker must know in advance the user they wish to identify as. This can be achieved in a number of ways, including via a user’s Active Directory (AD) Security ID (SID), or via a user’s AD User Principal Name (UPN). A UPN is the primary logon name for a user in either Windows AD or Microsoft Entra ID, and is formatted similar to that of an email address, e.g. administrator@domain.local.
In the example screenshot below, with identifying information redacted, a Rapid7 Labs proof-of-concept script discovers potential SharePoint users via SID enumeration and then leverages CVE-2026-55040 to bypass authentication on the target SharePoint site to assume the identity of that user — ultimately identifying the SharePoint site administrator user account.
Figure 1: The Rapid7 Labs PoC for CVE-2026-55040.
⠀
An attacker who successfully exploits CVE-2026-55040 can perform operations against the target SharePoint site as the user they identify as. Furthermore, this authentication bypass can be chained to additional vulnerabilities within the authenticated attack surface of the target site.
Rapid7 Labs has chained the authentication bypass CVE-2026-55040 with a separate RCE vulnerability for unauthenticated RCE. Patching CVE-2026-55040 will successfully break this exploit chain; this underscores the importance of patching vulnerabilities such as authentication bypasses, which can break complex and high-impact exploit chains. The RCE component has been disclosed to Microsoft and is expected to be patched in the scheduled August patch cycle.
Leveraging AI
To develop our SharePoint exploit chain, Rapid7 Labs undertook a research project divided into two main sprints, the first in January and the second in March, 2026. While both sprints did encompass more traditional vulnerability research such as manual code review and reverse engineering, a significant amount of the work was undertaken through an agent. Over 24 active days of agentic work, we leveraged 96 sessions, issued 256 prompts, and generated approximately 80,000 agentic tool calls.
The initial January sprint was unsuccessful, resulting in no findings that could be leveraged for an exploit chain. We used this sprint to experiment with several different publicly available models, along with different workflows to navigate and reason across a massive and complex codebase. However, our second sprint in March was successful and yielded, through a heavily prompted agent, a two-vulnerability exploit chain that achieved unauthenticated RCE.
The improvement in quality between January and March in terms of agentic work, along with our improved workflows, was noticeable. This highlights the speed at which this field is evolving, how publicly available models are improving, and how as research teams develop their workflows, the results begin to compound.
Credit
This vulnerability was discovered by Stephen Fewer, Senior Principal Security Researcher at Rapid7 and is being disclosed in accordance with Rapid7's vulnerability disclosure policy.
Vendor statement
The following statement has been provided by Microsoft:
“We would like to thank Rapid7 for responsibly reporting this issue through coordinated vulnerability disclosure.”
Technical analysis
Rapid7 will be publishing full technical details for CVE-2026-55040 within 30 days of this disclosure.
Remediation
Customers are advised to apply the latest available updates for the impacted product to ensure they are protected.
Rapid7 customers
Exposure Command, InsightVM and Nexpose customers will be able to assess their exposure to CVE-2026-55040 with Authenticated vulnerability checks available in the July 15 content release
Disclosure timeline
May 18, 2026: Rapid7 discloses an unauthenticated RCE exploit chain to Microsoft. Microsoft acknowledges receipt of the disclosure the same day.
May 20, 2026: Microsoft confirms the findings and indicates that the exploit chain will be patched across two scheduled update cycles - the authentication bypass component in July, and the RCE component in August.
May 21, 2026: Rapid7 acknowledges the disclosure schedule and requests supporting information. Microsoft requests a 30 day stay on disclosure of technical details and publication of PoC.
May 29, 2026: Rapid7 agrees to a 30 day stay on technical details with a proviso to publish earlier should either exploitation in-the-wild or third-party publication of details occur within the 30 days. Microsoft confirms the disclosure plan the same day.
June 30, 2026: Rapid7 requests supporting information for the upcoming disclosure.
June 30, 2026: Microsoft provides supporting information to Rapid7.
July 14, 2026: This disclosure for CVE-2026-55040.
July 14, 2026: The blog is updated to reflect that Microsoft’s published advisory now scores CVE-2026-55040 as critical severity, rather than medium severity.
July 15, 2026: Updated to reflect the availability of vulnerability checks in the July 15 content release.
A major credential leak spurred the Cybersecurity and Infrastructure Security Agency to strengthen protections for its sensitive materials, improve how researchers can report agency vulnerabilities and develop plans for similar incidents, the agency said in a forensic report released Thursday.
The blog post outlines CISA’s response to the leak that the researcher who discovered it in May called one of the worst he had ever seen, which also drew congressional scrutiny.
“Sharing experiences from incident response activities help other organizations learn from such experiences and enables them to take necessary precautions to prevent similar incidents from happening in their environments,” wrote Preston Werntz, acting chief information officer and Brad Libbey, acting chief information security officer. “For years, CISA has said this type of information exchange is critical to identifying trends and contributing to broader national awareness. Now, it is our turn.”
On May 15, after learning about a contractor’s leak of privileged Amazon AWS GovCloud Keys on a public GitHub repository, CISA said it took steps to halt further harm. That meant taking the repository and its developer environment offline, and revoking the access of the person responsible for the leak.
CISA then analyzed the repository to get a sense of the scope of the leak. It also analyzed log files to learn that none of the leaked credentials were used outside of CISA, and that no customer or mission data was exposed.
The response benefited from taking the reported incident seriously, having good logging capabilities and using zero-trust principles, the blog post states.
But it also showed some things that needed to be fixed.
CISA resolved to use its endpoint detection and response capabilities to monitor and manage uploads to public repositories. It rotated all of its secrets after the incident, and came up with a plan to improve management of its secrets.
It determined that it would make it easy to report vulnerabilities related to CISA itself. It’s better at receiving information about vulnerabilities that are less agency-specific, given its role as a hub of communication about cyber risks for the United States and world generally, the post noted.
CISA also said it had to build a playbook for GitHub-related incidents mid-incident, and recognized the need to build playbooks for all kinds of incidents in advance.
The person who uncovered the leak, GitGuardian security researcher Guillaume Valadon, applauded CISA’s evaluation of the incident.
“I think that it is really good. CISA managed to explain what happened, what worked well and what needs to be improved,” he told CyberScoop via email. “This last part is, to me, the first time that a national cybersecurity agency is advocating for secrets scanning, and simplifying relations with researchers.”
That’s something Valadon and his team have talked about for a while, and he said he was “proud to read that it is recognized by CISA.”
Microsoft addressed a whopping 206 vulnerabilities lurking in its vast portfolio of business products and foundational systems in this month’s Patch Tuesday update, marking the vendor’s largest monthly batch of security patches on record, according to researchers.
The massive assortment of vulnerabilities in Microsoft’s latest defect dump accentuates an alarming trend across technology — fears and warnings about a roaring flood of error-riddled software have materialized. And the disease is spreading.
“It is extraordinary that Microsoft can produce so many patches in a single month, but it does raise concerns,” Dustin Childs, head of threat awareness at Trend Micro’s Zero Day Initiative, wrote in a blog post Tuesday.
Researchers consistently highlight the role artificial intelligence is playing in discovering more vulnerabilities and aiding in the development of patches and testing. Childs isn’t alone in wondering if this is the new normal and how that will impact defenders’ strategies for patch prioritization and deployment.
“Pandora’s proverbial box has been opened, and as more advanced AI models become available, we expect the norm to continue upward across the board, not just for Patch Tuesday,” Satnam Narang, senior staff research engineer at Tenable, said in an email.
This vulnerability flood isn’t a one-off or rare event. Half of Microsoft’s Patch Tuesday updates through the first half of this year contained a volume of defects well into the triple digits.
“The current number of CVEs shipped by Microsoft this year exceeds the total number of CVEs shipped in all of 2018,” Childs wrote.
Microsoft disclosed three vulnerabilities — CVE-2026-45586, CVE-2026-50507 and CVE-2026-49160 — that were publicly known at the time of release, but not yet exploited in the wild, according to the company.
Yet, in an out-of-band update May 19, the vendor did disclose and release a patch for CVE-2026-41091, an actively exploited zero-day vulnerability affecting Microsoft Defender.
Microsoft disclosed one max-severity vulnerability — CVE-2026-48567, affecting Azure HorizonDB — and nine defects with critical CVSS ratings. The company designated 15 of the vulnerabilities it addressed this month as more likely to be exploited.
Microsoft reopened some wounds and has reignited debate over the past couple weeks about vulnerability disclosure and the sometimes adversarial dynamic it creates between security researchers and vendors.
The latest controversy ensued when Microsoft threatened criminal legal action against a security researcher who publicly disclosed a series of zero-day vulnerabilities with proof-of-concept exploits. Microsoft insisted it received no details about the vulnerabilities prior to release, adding that the defects were not responsibly disclosed and put its customers at unnecessary risk.
The public dispute between Microsoft and the researcher known as “Nightmare Eclipse,” who couldn’t be identified or reached for comment, sparked dismay among some security professionals. Microsoft’s forceful response and the resulting backlash revived a friction point between vendors and researchers who find and report flaws in the software they sell.
“The fight is being argued as coordinated disclosure, but the grievance underneath is personal and specific in a way disclosure shouldn’t be, especially with a vendor that has been at it for so long,” Katie Moussouris, founder and CEO at Luta Security, told CyberScoop.
“Microsoft seemed to get emotional and shouldn’t have publicly said anything, but somehow felt justified in calling out a researcher and involved law enforcement in the same breath,” she said. “That puts them right back in the first stages of vulnerability disclosure grief: denial and anger.”
The former longtime Microsoft employee who ran outreach with the security community, created the company’s first bounty program and has given conference talks on the subject as far back as 2013, said the company doubled down on its lack of responsibility in the whole saga.
Microsoft declined to answer questions in the wake of the fallout.
Nightmare Eclipse hinted at a breakdown and impending battle with the vendor in a series of blog posts leading up to Microsoft’s missive about the vulnerabilities RedSun, UnDefend, BlueHammer, YellowKey, GreenPlasma, and MiniPlasma.
Attackers exploited three of the six vulnerabilities Nightmare Eclipse released before they were patched by Microsoft.
The researcher claimed Microsoft refused to communicate, didn’t pay or credit them for discovering and reporting some of the vulnerabilities, deleted the Microsoft Security Response Center account they used to disclose vulnerabilities and flagged their GitHub account for removal.
“You are proving to everyone that you are actively escalating this conflict,” they wrote, before threatening Microsoft with a release in mid-July that “will make sure your bones are shattered that day.”
Vulnerability disclosure is a two-way street
The characteristics of proper vulnerability disclosure processes are nuanced and often framed in the eyes of the beholder.
Any successful dance between bug hunters and vendors comes down to meeting each other halfway, said Andrew Morris, founder and chief architect of GreyNoise.
While vendors must fix software defects and prioritize security, Morris noted that irresponsible vulnerability disclosure harms both incident responders and potential victims.
“Personally, I feel like this researcher is being extremely petty. It seems like they have an ax to grind,” he said.
“You’re not allowed to give somebody something and say it’s out of the kindness of your heart, and then be pissed when they don’t pay you for it.”
But Morris also made clear that vendors bear responsibility for building trust with researchers.
“If you actually care about being the first one to know about bugs in your software, not learning about it once harm has happened, or once somebody’s gotten popped, then you want to cultivate that trust with the security community,” Morris said.
Microsoft said it recognizes that the relationship between security researchers and vendors is critical and, at times, fragile.
“We deeply value the security community, and will continue to take your feedback seriously,” the company said in its post on X.
Yet, the company remains steadfast in opposing the circumstances of Nightmare Eclipse’s disclosures, describing their actions as illegal, unjustifiable and irresponsible.
“When an individual breaks the law and engages in malicious activity causing real harm to our customers, we will work with law enforcement as appropriate,” Microsoft said without naming the researcher by their moniker. “We continue to believe strongly in coordinated vulnerability disclosure as the foundation for protecting customers and improving our products. We know that, given the nature of this work, there will at times be misunderstandings. We remain committed to engaging in good faith and to providing a respectful and professional experience for all researchers, regardless of past interactions.”
The cost of pushback
Security researchers seek out defects for various reasons: bounty payouts, recognition, industry credibility, or simply the thrill of the hunt that comes with finding vulnerabilities and getting them fixed.
At its best, this process happens behind the scenes, with patches released and customers warned before exploitation occurs.
This collaborative approach has taken root and improved considerably, but there are still cases where researchers feel slighted.
“The public has no idea what went on behind the scenes to judge why a researcher that previously coordinated finally had enough and decided to drop a zero-day [vulnerability],” Moussouris said. As such, she’s less inclined to criticize Nightmare Eclipse’s actions, adding that “they come off as someone who needs help.”
Yet, trust breaks down between vulnerability researchers and vendors often. Earlier this week, security researcher Ammar Askar claimed his last interaction with Microsoft’s security team was so poor that he decided to publicly disclose any bugs he finds in VS Code going forward. He made good on that threat by dropping a vulnerability and exploit code for a defect that allows attackers to steal GitHub tokens.
While actions like this can sabotage trust and drive a wedge between vendors and vulnerability researchers, recourse to a large extent is limited. Moussouris said most of the time, the legal and ethical boundaries are clear to those involved. Researchers can report bugs, withhold them, sell them, or publish them. “The one red line is crime: using a flaw to extort or attack people,” Moussouris said.
“Threatening to publish on a set date is a threat to disclose, and disclosure is lawful. You can find the tone ugly. [Nightmare Eclipse] still broke no rule and violated no duty.”
The timing couldn’t be worse
Both sides are partly responsible for what happened, but Microsoft made things worse, Morris said. Threatening legal action and taking an aggressive approach have never worked. Building a good relationship between researchers and vendors requires open communication and trust.
“I thought we were past this. It turns out that we are not,” he said.
The Nightmare Eclipse incident comes at a fraught time in this space. Vendors and their customers are confronting a deluge of more vulnerabilities, and the rise of artificial intelligence models that discover them is exacerbating this challenge, leaving security experts alarmed about what’s coming.
The prospects for where vulnerabilities will be discovered and exploited next, and to what impact, are unknown and wildly unsettling.
These signals imply that the classic, CVE-based system with responsibly disclosed processes is probably broken, Morris said. “There’s just so many CVEs. It’s like, is this even working anymore?”
For now and despite all its faults, coordinated vulnerability disclosure programs are widely viewed as the most sensible and scalable approach to this dilemma.
“Coordinated disclosure is what happens when a vendor gets lucky. Someone they did not hire hands them a real bug instead of using it or selling it. That puts the whole burden of keeping coordination alive on the vendor,” Moussouris said. “Silent patching with no CVE and calling out researchers who don’t follow your timeline for disclosure squanders the vendor’s luck.”
She stressed the stakes: “I hope Microsoft and all vendors learn that coordinated vulnerability disclosure is a gift and a grace from the security researcher community to them, and public disclosure is still better than non-disclosure or crime.”
The alternatives to a deteriorating relationship could wreak havoc and leave every vendor and customer more susceptible to attack.
“If vendors unlearn how to receive free intellectual property and labor from the security community in the form of vulnerability reports with gratitude, we’re headed for a world where nobody bothers to give vendors any heads up, or they move to a timed disclosure model that gives no grace,” Moussouris said.
She concluded with a direct message: “Product vendors wrote the vulnerable code, own the risk, and they owe it to their users to do everything in their power to reduce that risk.” That includes “keeping their grievances to themselves and learning from introspection on coordinated vulnerability disclosure gone wrong.”
One of the more persistent myths in security is that old bug classes become old problems. They don’t. They just show up in different places, under different conditions, and usually at the exact moment we’ve convinced ourselves not to pay attention to them.
That’s part of what makes enterprise voice infrastructure so interesting.
Earlier this year, we wrote about a critical vulnerability in Grandstream VoIP phones that showed how easily a trusted communications device could become something very different. It wasn't especially flashy, but it reinforced the broader issue that phones are still part of the attack surface, even if many organizations don’t model them that way.
Today, we'll again discuss the same uncomfortable reality. VoIP technology may sit quietly on a desk and look like a utility, but the security implications are anything but quiet. And when familiar vulnerability classes continue to surface in devices designed to sit at the center of sensitive conversations, it’s worth asking whether we’ve been underestimating this part of the environment for far too long.
Rapid7 Senior Principal Security Researcher Stephen Fewer discovered CVE-2026-0826, a critical unauthenticated stack-based buffer overflow vulnerability affecting multiple HP Poly VoIP devices. If you’ve been around vulnerability research long enough, the bug class here is going to feel very familiar. And interestingly enough, that’s exactly why it deserves attention. These older exploitation primitives never really went away; they just found new places to cause problems.
CVE-2026-0826
CVE-2026-0826 is a critical unauthenticated vulnerability affecting multiple HP Poly VoIP devices, including models in the VVX and Trio product lines. At a high level, this is a classic memory corruption bug. If the right conditions are present, a remote attacker can exploit the vulnerability to gain control of an affected device without authentication.
For most organizations, the technical root cause will matter to the teams responsible for remediation, validation, and long-term hardening. But from a risk perspective, the takeaway is much simpler in that a trusted business phone can potentially be turned into an attacker-controlled asset.
That matters because these devices often live in places we inherently trust such as executive offices, conference rooms, help desks, trading floors, hospital stations, and other environments where sensitive conversations happen every day. A compromise in that context is not just about device access. It’s about what that access enables.
Why this is still exploitable in 2026
One of the questions I get all the time when I teach SANS SEC660 is whether basic buffer overflows are still relevant. Students will usually ask some version of, “Are we really still dealing with this?” and right behind that, the follow-up of “Don’t modern mitigations make these bugs much harder to exploit?”
They're fair questions. The reality is that modern mitigations absolutely matter, and in many cases they do make exploitation more difficult. But they don’t make memory corruption go away. What they really do is change the path from bug to impact. So when we looked at this issue, the obvious question wasn’t just whether a stack overflow existed, but whether the protections in place actually prevented it from becoming meaningful code execution.
In this case, they didn’t.
This is one of those cases where the presence of modern mitigations looks better on paper than it does in practice. The protections that should have made exploitation significantly harder ultimately didn’t stop an attacker from turning the bug into full code execution on the device.
So yes, the bug class is old-school. But the exploitation path is still very real.
Why attackers care about desk phones now
Now, on its own, “root shell on a phone” sounds bad, but maybe not headline-worthy to some people. The real story is what that access gives an attacker in practice.
Over the past several years, advanced threat actors have increasingly shifted toward edge devices, embedded systems, and network appliances as a place to operate. And let’s face it, that makes sense. If you’re trying to persist quietly in an enterprise environment, you don’t necessarily want to live on the Windows system with every security product on earth installed on it.
You want the thing nobody is watching.
You generally can’t run modern EDR on a VoIP desk phone. You’re not going to see the same telemetry. You’re not going to get the same host-based detection coverage. And in many environments, those devices sit on the network for years with very little scrutiny beyond whether they can still make and receive calls.
That makes them useful not only as footholds, but also as infrastructure for internal pivoting, call manipulation, traffic interception, or quiet persistence.
And that’s before we even get to the part that I think is especially relevant right now in the age of AI. I'm referring to audio collection.
A listening post for the AI era
One of the more interesting shifts in today’s threat landscape is how valuable high-quality voice data has become.
Attackers no longer need massive datasets to make use of synthetic speech tooling. In many cases, they just need clean source audio of the right person saying enough words in enough contexts. That has made executive voice data, call recordings, and live conversation capture far more valuable than many organizations seem prepared to admit.
A compromised desk phone sitting in an executive office or conference room is not just a way to eavesdrop on sensitive discussions. It can also become a collection point for exactly the kind of audio that can be reused in vishing, deep fakes, social engineering, or even fraudulent financial authorization attempts.
The concern is not just “someone might hear something confidential.” That would be bad enough. The broader concern is that voice infrastructure can now support both traditional espionage objectives and modern AI-enabled fraud operations at the same time.
The bigger lesson
I think the real takeaway from this research is not merely that another VoIP phone had a memory corruption bug. As security researchers, we know those bugs are always out there somewhere. The more important lesson is that many organizations still don’t threat model voice systems with the same seriousness they apply to other enterprise assets.
It’s also part of a broader pattern I’ve been talking about in The Monday Brief that attackers don’t need especially novel tradecraft when defenders continue to overlook familiar weaknesses in trusted systems.
We’ve gotten pretty good at thinking critically about identity systems, servers, cloud infrastructure, and endpoints. But desk phones often fall into this weird blind spot where they’re treated as appliances rather than computers with microphones, network connectivity, and administrative logic.
That mindset needs to change.
Because when a classic stack-based overflow can be leveraged into root access on a trusted office device sitting a few feet away from your leadership team, it’s no longer reasonable to think of that phone as “just a phone.”
It’s part of your attack surface. It’s part of your exposure. And depending on where it sits, it may also be one of the more efficient listening posts in your environment.
Rapid7 Labs conducted a zero-day research project against an HP Poly VVX 450 Voice over Internet Protocol (VoIP) phone. This research resulted in the discovery of a critical unauthenticated stack-based buffer overflow vulnerability, CVE-2026-0826. A remote attacker can leverage CVE-2026-0826 to achieve unauthenticated remote code execution (RCE) with root privileges on a target device.
The vulnerability is present in the device's parsing of Session Description Protocol (SDP) attributes for Interactive Connectivity Establishment (ICE). The ICE feature, which is not enabled by default, must be enabled for the device to be exploitable by a remote attacker.
While we discovered and validated the vulnerability on a VVX 450 device, the vulnerability has been confirmed to affect all models in the VVX series (VVX 150, VVX 250, VVX 350, and VVX 450), as well as three models from the Trio IP Conference series (Trio 8800, Trio 8500, and Trio 8300).
A Metasploit exploit module has been developed to demonstrate how an unauthenticated attacker could leverage this vulnerability to gain root privileges on a vulnerable device.
Shown below is the exploit being run against a target Poly VVX 450 device running a vulnerable firmware version 6.4.7.4477.
As we can see above, the attacker achieves unauthenticated RCE with root privileges on the device. This is demonstrated by the attacker executing a reverse shell payload and running several arbitrary OS shell commands.
Technical analysis
Our analysis is based upon a VVX 450 device running firmware version 6.4.7.4477. During testing, the test device had an IPv4 address of 192.168.86.80. The non-default ICE feature was enabled by specifying the following in the device configuration:
device.feature.nat.ice.enabled="1"
The main binary that provides the majority of functionality to the device is /user/local/root/polyapp (32 bit ARM, Little Endian). This binary parses SDP data provided in an Session Initiation Protocol (SIP) request over UDP on port 5060.
When SDP data is processed, if ICE is enabled, an SDP attribute named candidate can be parsed. The candidate attribute is intended to contain a transport address for a candidate that can be used for connectivity checks. An example of a valid candidate attribute can be seen in the RFC8839 5.1:
The following is an example SDP line for a UDP server-reflexive "candidate" attribute for the RTP component:
The /user/local/root/polyapp binary has two functions that will parse incoming SDP data, named ParseRemoteSDP and IceSession::ParseRemoteSdpForAddresses. In both cases, when a string line starting with “a=candidate:” is found, a helper function ParseICECandidate (at address 0xB12780) is called to parse the expected candidate attribute held in the remainder of that string line. The intent is to parse out the individual components of a candidate attribute which are separated by white space characters.
This helper function ParseICECandidate contains a stack based buffer overflow. Shown below we can see that the start of the function contains a call to memcpy, which will copy the incoming string line being processed into a 256 byte stack buffer. No length check is performed to ensure the incoming string length is less than 256 bytes. Therefore by providing a candidate attribute whose length is greater than 256 bytes, a stack-based buffer overflow will occur.
To demonstrate the vulnerability, we can construct an example SIP INVITE request that contains the required SDP data to trigger the buffer overflow. The malicious candidate attribute will be comprised of:
An attribute name of “a=candidate:”, which is 12 bytes long.
244 A characters, to fill out variable buffer256 (shown in the code snippet above), as 244 + 12 is 256.
19 B characters, to provide padding between the variable buffer256 and the saved registers on the current stack frame.
The characters 1111 (0x31313131 in hex) to overwrite the saved r4 register.
The characters 2222 (0x32323232 in hex) to overwrite the saved r5 register.
The characters 3333 (0x33333333 in hex) to overwrite the saved r11 register.
The characters 4444 (0x34343434 in hex) to overwrite the saved pc register.
A large number of C characters (0x43 in hex) to show the remaining attacker controlled data on the stack.
The entire example SIP INVITE request sent to the device is shown below:
Upon receiving this SIP INVITE request, the helper function ParseICECandidate will parse the malicious candidate attribute, and a stack-based buffer overflow will occur. Observing the resulting crash in GDB, we can see that we have full control over the program counter (pc) register, several general purpose registers, and the data located at the stack pointer (sp).
Figure 2: Inspecting a core dump showing the effects of the overflow.
# uname -a
Linux (none) 2.6.27.18 #1 PREEMPT Mon Jan 13 09:50:58 PST 2020 armv6l unknown
# cat /proc/sys/kernel/randomize_va_space
1
⠀
Inspecting the polyapp binary with the checksec tool we can see that No Execute (NX) is enabled, so the stack data will not be executable. As we will not be able to execute a payload directly on the stack, we can overcome this by using a Return Oriented Programming (ROP) chain to bypass the NX mitigation. Additionally, the binary has not been compiled as a Position Independent Executable (PIE).
As the polyapp binary is always loaded at a low address (0x00008000), using Virtual Address (VA) values from this range will require the attacker to be able to place multiple null (0x00) bytes in the overflow buffer. This will not be possible due to how the SDP data is processed.
We must discover a suitable workaround to exploit the vulnerability while not writing any null bytes in the overflow buffer. We could try to discover an information leak vulnerability, that leaks an address of a Shared Object (SO) location within the processes address space. If the SO is loaded at a location such that its addresses will not contain null bytes, we can use these addresses for ROP gadgets. In lieu of a suitable information leak vulnerability, we will require an alternative technique.
Conveniently to our purpose, ASLR is not operating as expected on the device, and does not impact the load address of Shared Object (SO) libraries. For example, libc will always be loaded at a Virtual Address (VA) of 0x40a5c000 on firmware version 6.4.7.4477. This does not change between process restarts or device cold reboots. Shown below is the same load address for libc in the polyapp process, across a cold reboot of the device.
Further inspection of the process maps file shows all shared libraries are loaded starting from a fixed address of 0x40000000 and do not appear to honor ASLR. Knowing this, we can build a simple ROP chain using gadgets located at fixed VA’s within the libc library. The gadgets we choose will not contain null bytes in their addresses.
We create a ROP chain that will execute an arbitrary OS command via the system standard C library function. The accompanying Metasploit exploit modules source code details the entire ROP chain.
Remediation
The following remediation guidance has been provided by the vendor.
“HP Poly recommends that administrators disable ICE connectivity in environments where it is not required. All affected Poly Voice devices should be updated to the latest available UCS release using the Poly Lens Device Management application.”
The following table indicates the appropriate fixed software releases.
Product Name
Updated version
VVX
UCS 6.4.8
Trio 8300
UCS 8.1.7
Trio 8500
UCS 7.2.8
Trio 8800
UCS 7.2.8
Credit
This vulnerability was discovered by Stephen Fewer, Senior Principal Security Researcher at Rapid7 and is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.
Rapid7 Customers
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-0826 with a vulnerability check available in the June 2 content release.
Disclosure timeline
January 6, 2026: Rapid7 makes initial outreach to HP who confirm contact the same day.
January 7, 2026: Rapid7 discloses the technical writeup and exploit code to HP.
January 9, 2026: HP confirms the finding, and provides Rapid7 with affected models, a reserved CVE identifier and an expected fix date for May, 2026.
January 12, 2026: Rapid7 agrees to the fix date and asks for clarity on the end of support for the VVX series. HP replies the same day with requested information.
April; 21, 2026: HP states a new release date by end of July and confirms CVSS, CWE and remediation guidance. Rapid7 gives June 1 as the disclosure date.
May 5, 2026: HP provides affected models and confirms coordinate disclosure for June 1.
May 18, 2026: HP provides remediation version numbers for patched firmware.
June 1, 2026: This disclosure.
June 2, 2026: Added Rapid7 Customers section to indicate availability of a vulnerability check, added link to vendor advisory.
Researchers and threat hunters are scrambling to respond to an actively exploited authentication-bypass vulnerability affecting Palo Alto Networks customers’ firewalls.
The company initially tagged CVE-2026-0257 with a medium-severity rating when it disclosed the defect May 13, but quickly reassessed it as critical after Rapid7 observed and confirmed active exploitation in the wild. The Cybersecurity and Infrastructure Security Agency followed suit, and added the vulnerability to its known exploited vulnerabilities catalog Friday.
The escalated threat posed by the defect, which allows remote attackers to bypass security restrictions and establish a VPN connection to an affected firewall, showcases how quickly a seemingly mild vulnerability can turn into an urgent warning.
“Palo Alto Networks is actively monitoring limited exploitation attempts targeting CVE-2026-0257 on unpatched PAN-OS devices where mitigations have not been applied,” a company spokesperson said in a statement. The company on Friday urged all customers to immediately apply the patch or follow its recommended steps for mitigation.
The vendor and Rapid7, which first observed exploitation May 17 in a customer environment, declined to say how many organizations are impacted thus far. Yet, Douglas McKee, director of vulnerability intelligence at Rapid7, warned: “We’ve continued to see new victims roll in, including a couple of customers hit within just an hour of each other during a second wave of activity” on May 21.
Jake Knott, security researcher at watchTowr, told CyberScoop the vulnerability and resulting exploits follows a recurring trend wherein attackers target exposed network edge devices and rapidly identify, develop and weaponize exploits for initial access.
“This is yet another authentication bypass on a device whose sole job is to guard the front door to an organization’s network,” he said. “What stands out is how simple it is — an attacker can forge a valid authentication cookie using nothing more than the appliance’s publicly available TLS certificate. The entire exploit is a single HTTP request.”
The vulnerability has a few requisites that limit exposure, specifically posing risk to some Palo Alto Networks customers running GlobalProtect portal or gateway configured to enable authentication override cookies.
“The cookie encryption and decryption certificate must be reused with another feature, which potentially exposes the public key for that certificate,” said Caitlin Condon, vice president of security research at VulnCheck.
“It’s difficult to say how many deployments meet those criteria for exploitability, but Palo Alto Networks firewalls have a very large footprint, which means even uncommon configurations can present significant attack surface area,” she added.
Rapid7 said the same attacker or group is likely responsible for both waves of exploitation last month, but in many cases attackers are not establishing a full VPN connection or moving to other parts of the impacted network.
The attackers are “highly opportunistic and clearly monitor the security research community,” McKee said. “Attackers are purposefully weaponizing medium-severity vulnerabilities, which are typically lower priority or blind spots for organizations.”
Multiple threat clusters are swarming to the opportunity and quickly adapting to published research. Researchers have not attributed the malicious activity to any specific threat groups.
“Their exact origins and long-term objectives remain unclear, as they currently seem focused purely on opportunistic initial access rather than targeted, long-term espionage,” McKee said.
Palo Alto Networks said it discovered the vulnerability internally through its use of frontier AI tools. Yet, within days of its public disclosure, initial assessments were proven inadequate.
“This is a pattern we continue to see — the urgency only arrives after exploitation is underway,” Knott said. “Organizations that wait for confirmation of active exploitation before patching will consistently find themselves reacting too late.”
Security researchers chained together five separate weaknesses in the popular workflow automation service Zapier that, if first discovered by a malicious actor, could have granted access to millions of user accounts and the systems those accounts connect to.
The flaws, disclosed by security firm Token Security, did not require malware or insider access. The only prerequisite, according to the company’s report, was a free Zapier account. From there, researchers chained together weaknesses that, if taken individually, would have looked routine, but together opened a path to one of the most widely used services of the modern internet.
Zapier’s software can be configured to move data between email, customer-relationship tools, payment processors, calendars, code repositories and thousands of other applications. The company says it supports more than 8,000 third-party integrations and has millions of users, which means breaking into Zapier could escalate into a wide-ranging supply-chain attack.
The researchers said an attempted attack would start by exploiting a weakness in how users write small pieces of code as part of their automations. Once that feature was isolated, researchers recovered login credentials the service had tried to discard. Those credentials, in turn, exposed an internal storage system holding more than 1,100 of Zapier’s private software images, one of which contained a publishing key for a piece of code that runs inside every logged-in Zapier user’s browser.
According to the report, if an attacker updated that code, they could have acted as a legitimate user inside the platform, creating new automations, altering existing ones, and tapping into connections the user had already approved to outside services. From there, they could instruct the platform to send emails, move files, pull records from customer databases, or post messages, all from accounts that appeared entirely legitimate.
The researchers stressed that a possible attacker could not have obtained passwords or login keys for those connected services, as those remain on Zapier’s servers. But because the actions would have been carried out through Zapier itself, they would have looked, to any outside system, like the user’s own.
A separate finding, uncovered during the same research, illustrated how immediate that risk can be. The researchers said they discovered a working key tied to the personal account of the chief technology officer of an outside artificial-intelligence company whose software Zapier used internally. Using that key, they were able to send an email from the executive’s own Gmail account to a mailbox they controlled.
Token Security told Zapier the capability existed but did not exploit it. The researchers confirmed they had the access needed to push a malicious update into code running inside every signed-in Zapier user’s browser, and instead reported the findings in February under the company’s bug-bounty program.
Researchers said that Zapier triaged the issues within four days, remediated within three weeks, and worked with the company to allow disclosure. The company paid the program’s maximum bounty of $3,000 and says it has no evidence the weaknesses were exploited before they were patched.
“Worth saying out loud in a culture that often punishes disclosure programs for slowness,” Token’s blog post reads.
Zapier did not respond to CyberScoop’s request for comment.
The episode lands at a moment when automation platforms and artificial-intelligence tools are increasingly being granted the standing authority to act on behalf of users across dozens of services at once. Token Security’s researchers argued that the weaknesses they found were not unique to Zapier. Each link in the chain, they said, was a well-documented kind of mistake. The vulnerability was the chain itself, and the same pattern, they warned, almost certainly exists at other companies that have not yet looked.
Zapier says the issues have been fixed and no further action is required. But the researchers suggested organizations with heightened sensitivity review their automation logs for anything they did not create, and consider reauthorizing Zapier connections to particularly sensitive systems.
Rapid7 Labs discovered a critical argument injection (CWE-88) vulnerability in Gogs, a popular open-source self-hosted Git service, tracked as CVE-2026-52806. Rapid7 Labs scores this vulnerability as CVSSv4 9.4 (Critical). The vulnerability allows any authenticated user to achieve remote code execution (RCE) on the server by creating a pull request with a malicious branch name that injects the --exec flag into git rebase during the "Rebase before merging" merge operation. A fix is available in Gogs 0.14.3, released June 7, 2026.
The exploit requires no admin privileges and no interaction with other users; an attacker operates entirely within their own account. Since Gogs ships with open registration enabled by default (DISABLE_REGISTRATION = false) and no limit on repository creation (MAX_CREATION_LIMIT = -1), an unauthenticated attacker can simply create an account and repository on any default-configured instance. Any registered user who creates a repo is automatically its owner. From there, enabling rebase merging is a single toggle in settings, and the entire exploit chain can be operated without interaction from any other user.
Alternatively, any user with write access to a repository where rebase is already enabled can exploit it directly. On instances where repository creation is restricted, an attacker still only needs write access to any repository that has (or can have) rebase merging enabled.
The result is arbitrary command execution as the Gogs server process user, giving the attacker the ability to compromise the server, read every repository on the instance (including other users' private repos), dump credentials (password hashes, API tokens, SSH keys, 2FA secrets), pivot to other network-accessible systems, and modify any hosted repository's code.
The latest release versions at the time of research, Gogs 0.14.2 and 0.15.0+dev (commit b53d3162), were confirmed to be affected. All prior versions supporting the "Rebase before merging" style are likely vulnerable as well.
Update #1: On June 7, 2026, the Gogs maintainer accepted Rapid7's patch and released version 0.14.3, which fixes this vulnerability. The vulnerability has been assigned CVE-2026-52806.
Product description
Gogs is a lightweight, self-hosted Git service written in Go. With ~50,000 GitHub stars and over 5,000 forks, it's one of the more popular self-hosted alternatives to GitHub, commonly deployed by companies, universities, and open-source projects.
A Shodan search for http.title:"Gogs" http.title:"Sign In" returns 1,141 internet-facing instances at the time of publication. The real install base is much larger since most deployments sit behind VPNs or internal networks.
Credit
This vulnerability was discovered by Jonah Burgess (CryptoCat), Senior Security Researcher at Rapid7, and is being disclosed in accordance with Rapid7's vulnerability disclosure policy.
Impact
Any Gogs instance with more than one user account is effectively "multi-tenant", meaning each user has their own repositories, credentials, and data on a shared server. This is the default for organizations, universities, and teams that use Gogs as a shared Git hosting platform. On any such instance, this vulnerability gives a single authenticated user full control of the underlying server. The attacker operates entirely within their own repository; no access to other users' repos is needed.
The vulnerability affects all supported platforms (Linux, macOS, Windows) and installation methods (pre-built binary, Docker, source). On Docker installations, the Gogs process runs as the git user (UID 1000 by default). On binary installations, the process user depends on how the administrator deployed the service (commonly git or a dedicated service account).
The practical impact:
Server compromise: Arbitrary command execution as the Gogs process user (typically git)
Cross-tenant data breach: Read every repository on the instance, including other users' private repos
Credential theft: Dump the database containing password hashes, API tokens, SSH keys, and 2FA secrets for all users
Lateral movement: Pivot to other systems reachable from the server's network
Supply chain attacks: Modify any hosted repository's code. The Gogs process user (typically git) has direct filesystem-level read/write access to every repository on the instance under a single REPOSITORY_ROOT directory, with no OS-level isolation between repositories. Direct filesystem manipulation bypasses Gogs' audit logging, and without commit signing (uncommon on self-hosted instances), forged commits are difficult to detect.
The exploit is fully automatable (a Metasploit module is provided) and runs in seconds. When the attacker creates and deletes their own repository, the only trace is an HTTP 500 in the server logs. When exploiting an existing repository, additional artifacts remain (see heading Indicators of compromise).
Technical analysis
The testing target was a Gogs 0.14.2 installation running via Docker on Linux (Ubuntu 24.04). The vulnerability was also confirmed on Gogs 0.15.0+dev (commit b53d3162). As noted above, the vulnerability affects all supported platforms (Linux, macOS, Windows) and installation methods.
Background: Merge vs. rebase in Gogs
A standard merge creates a merge commit joining two branch histories. A rebase before merge replays the head branch's commits on top of the base branch to produce a linear history. Under the hood, Gogs runs git rebase <base_branch> <head_branch> in a temp directory before pushing the result.
Critically, git rebase accepts an --exec flag that tells Git to run a shell command (via sh -c) after replaying each commit. Argument injection into --exec has been a recurringsource of RCE vulnerabilities in Git-based applications. This is the exploitation primitive.
Gogs exposes 'Rebase before merging' as a per-repo setting (PullsAllowRebase). It is not enabled by default, but any repo owner or admin can enable it under Settings > Advanced. By default, any user who creates a repo is automatically its owner, so the barrier to exploitation is low. Administrators can restrict repo creation globally (MAX_CREATION_LIMIT = 0 in app.ini) or per-user (via Max Repo Creation in the admin panel), but this does not prevent exploitation by users with write access to existing repositories.
Root cause
The Merge() function in internal/database/pull.go passes the PR's base branch name directly to git rebase without a -- separator (a POSIX convention that signals the end of options, preventing subsequent arguments from being interpreted as flags):
pr.BaseBranch comes from the URL parameter in internal/route/repo/pull.go:
baseRef := infos[0] // from strings.Split(c.Params("*"), "...")
⠀
Both baseRef and headRef are validated via RevParse before the PR is created. RevParse is defined in the external git-module library and works by calling git rev-parse --verify <ref>, which only checks whether the ref resolves to a valid Git object. It does not sanitize against argument injection, and it does not need to since git rev-parse --verify treats --exec=... as a ref name and fails if it doesn't resolve. However, the attacker pushes the malicious branch name (e.g. --exec=<payload>) to the repo first, so RevParse succeeds because the ref genuinely exists. The value is stored in the database and later passed as-is to the rebase command.
Crafting the payload
Git branch names can legally contain $, {, }, =, and -. An attacker creates a branch named:
--exec=touch${IFS}/tmp/rce_proof
⠀
When this is used as pr.BaseBranch, the rebase command becomes:
git rebase --quiet '--exec=touch${IFS}/tmp/rce_proof' 'head_repo/feature'
⠀
Git's argument parser treats --exec=touch${IFS}/tmp/rce_proof as the --exec flag, not a branch name. --exec runs the value via sh -c after each replayed commit, and ${IFS} expands to a space in the shell, bypassing Git's prohibition on spaces in branch names.
For commands containing characters forbidden in Git refs (:, ~, ^, ?, *, [, \, //), such as URLs, the payload is base64-encoded:
The vulnerability affects Windows installations as well, but the payload delivery method differs. On Linux, the payload can be base64-encoded inline in the branch name (e.g. --exec=echo${IFS}<b64>|base64${IFS}-d|sh). On Windows, this fails because NTFS forbids the | (pipe) character in filenames, and Git stores branch refs as files at refs/heads/<branch_name>.
The solution is file-based payload delivery where the exploit commits a script file (e.g. .abcdef) to the repository and uses a short, filesystem-safe branch name: --exec=sh${IFS}.abcdef. An additional complication is that MSYS2's sh (bundled with Git for Windows) mangles shell metacharacters like $, &, and backticks in the payload before PowerShell can process them. To avoid this, the script file invokes cmd.exe //c .abcdef.bat (where //c is the MSYS2 escaping for /c), which natively executes the .bat file containing the PowerShell payload without shell interpretation issues. The Metasploit module implements this cross-platform approach automatically.
Fails - Git interprets --exec=... as an invalid option for checkout
⠀
Step 5 fails and Merge() returns HTTP 500, but the RCE already fired at Step 3. The 500 gets logged but doesn't undo anything.
Because the merge aborts partway through, the repository's git state is left corrupted (stuck in a partial rebase). This means the exploit can only be fired once per repository. In cases where the attacker created the repo themselves, this doesn't matter since the repo is deleted afterward, but when targeting an existing repository, the repo is effectively burned after a single use.
Why the PR becomes mergeable
For the exploit to work, the PR needs to reach "Mergeable" status so the merge button is available. This depends on an interesting race condition in how Gogs validates PRs:
During PR creation, testPatch() calls UpdateLocalCopyBranch(pr.BaseBranch). For a fresh repo with no local copy, it takes the Clone path, which includes --end-of-options. The malicious branch name is treated as data, clone succeeds, testPatch completes normally.
Since testPatch didn't flag a conflict, the status gets promoted to PullRequestStatusMergeable.
The background TestPullRequests goroutine periodically re-checks PRs. On the next call, the local copy does exist, so UpdateLocalCopyBranch takes the Checkout path instead. This one is missing --end-of-options, so the checkout fails.
That error causes TestPullRequests to skip checkAndUpdateStatus(), meaning the PR stays Mergeable forever.
The default exploit path creates a fresh repository, so the first testPatch always hits the Clone path and succeeds. The same applies when targeting an existing repository that has never had a PR created against it. If the target repo has had prior PRs, the local copy already exists, Checkout fails, and the PR cannot be created.
Relationship to prior argument injection fixes
Gogs has addressed argument injection vulnerabilities across multiple prior advisories. This vulnerability is in the same class but affects a different code path (Merge()) that was never patched:
The git-module library (v1.8.7) was hardened with --end-of-options across Clone(), Push(), Fetch(), and 28 other call sites. However, the Merge() function in internal/database/pull.gobypasses all of these protections because it uses raw process.ExecDir (wrapping exec.Command directly) instead of the safe git-module API. The git rebase call was never migrated.
Exploitation
The Metasploit module automates the full exploit chain against both Linux and Windows targets and supports two modes of operation:
own_repo (default): The module creates a temporary repository under the attacker's account, runs the exploit, and deletes the repo on cleanup. This works on any default-configured instance and supports all payload types.
existing_repo: The module targets a repository the attacker already has write and merge access to. This is useful on instances where repo creation is restricted. Only command payloads are supported in this mode (staged payloads would require multiple merge cycles, which is not possible due to the repo corruption described above). Cleanup deletes the malicious branches and closes the PR, but the repository's git state remains corrupted.
Figure 1: Metasploit module obtaining a meterpreter shell session on a Gogs 0.14.2 instance running on Ubuntu.
On Windows, the module uses the file-based delivery method described above to work around NTFS filename restrictions.
⠀
Figure 2: Metasploit module obtaining a Meterpreter session on a Gogs 0.14.2 instance running on Windows 11.
Indicators of compromise (IoCs)
Defenders should watch the Gogs server logs for error entries matching this pattern:
This is logged via c.Error(err, "merge"), which writes the full error (including the malicious branch name) to the server log at ERROR level. Note that a more cleverly written exploit may not be this obvious in log files.
If the attack targeted an existing repository (rather than one the attacker created and deleted), additional artifacts will be present: the malicious branch name (e.g. --exec=...) in the repository's branch listing, a failed pull request in the PR history, and the repository itself will be in a corrupted git state (returning HTTP 500 on certain operations). On Windows, the committed payload files (e.g. .abcdef, .abcdef.bat) will also remain in the git history. Administrators should audit repositories for branch names beginning with --.
The Metasploit module also creates a Gogs API token (named msf_<hex>) during exploitation. Gogs does not expose a token deletion API endpoint, so this token persists after the attack and remains valid until manually revoked via the web UI or database. Defenders should check user token lists at /-/user/settings/applications for unexpected entries.
The payload file used during exploitation is written to the repository's bare git directory on the server filesystem and will persist after the attack.
Remediation
Gogs 0.14.3, released June 7, 2026, fixes this vulnerability. Rapid7 recommends that all Gogs users upgrade immediately. The fix was implemented via pull request #8301, submitted by Rapid7.
For users who cannot upgrade immediately, the following mitigations reduce exposure:
Restricting user registration (DISABLE_REGISTRATION = true in app.ini) to prevent untrusted users from creating accounts. This is the most impactful mitigation since the exploit is self-contained within a single user's repository.
Restricting repository creation (MAX_CREATION_LIMIT = 0 in app.ini) to prevent users from creating their own repos. This can also be set per-user via Max Repo Creation in the admin panel. This blocks the easiest attack path (creating a new repo with rebase enabled), but does not prevent exploitation by users with write access to existing repositories.
Auditing rebase merge settings: While "Rebase before merging" can be disabled per-repo under Settings > Advanced, note that this is not an effective defense against a malicious user who owns or has admin access to a repo, since they can re-enable rebase at will. There is no global or organization-level setting to restrict this. Disabling rebase is only useful for reducing the attack surface on shared repositories where the attacker has write access but not admin privileges.
Rapid7 Customers
Exposure Command, InsightVM, and Nexpose customers can assess exposure to the Authenticated RCE via Argument Injection in Gogs with a vulnerability check available in the May 29 content release.
Disclosure timeline
March 16, 2026: Vulnerability discovered and validated against Gogs 0.14.2 and 0.15.0+dev (commit b53d3162).
March 17, 2026: Reported to Gogs maintainers via GitHub Security Advisory (GHSA-qf6p-p7ww-cwr9).
March 28, 2026: Maintainer acknowledges receipt.
April 21, 2026: Contacted maintainer for a status update (no response).
May 6, 2026: Reminded maintainer of previously planned disclosure date, and offered extension if required (no response).
May 20, 2026: Advised maintainer the blog release date is finalized for May 28, 2026 (no response).
June 1, 2026: Added Rapid7 Customers section to indicate availability of a vulnerability check.
June 8, 2026: Updated contents to reflect that the Gogs maintainer accepted Rapid7's patch and released version 0.14.3 on June 7, 2026, which fixes this vulnerability.
June 9, 2026: Updated to include assigned CVE-2026-52806.
Attackers returned once again to a common target with a massive user base by exploiting a max-severity zero-day vulnerability affecting Cisco Catalyst SD-WAN Controller and Manager.
The threat group behind the “limited” number of attacks Cisco is aware of thus far are also linked to a series of previously disclosed vulnerabilities in the vendor’s firewalls and SD-WAN systems, the company said in a threat advisory Thursday.
The authentication bypass vulnerability — CVE-2026-20182 — has a CVSS rating of 10 and “behaves like a master key,” Douglas McKee, director of vulnerability intelligence at Rapid7, wrote in a blog post.
“An attacker can present themselves to the controller as a trusted network router and, if the system accepts that claim without properly validating it, they can obtain the highest level of administrative access,” he added. “That is the cybersecurity version of a Jedi mind trick.”
Rapid7 discovered and reported the vulnerability to Cisco on March 9, and Cisco said it became aware of limited exploitation of the vulnerability earlier this month. The vendor disclosed and released a patch for the vulnerability Thursday, and the Cybersecurity and Infrastructure Security Agency quickly added the defect to its known exploited vulnerabilities catalog.
Cisco did not explain what occurred during that two-month window. Yet, the disclosure and warning from researchers marks another challenge for Cisco customers that have confronted a flood of actively exploited vulnerabilities affecting the vendor’s network edge software since late February.
Cisco isn’t the only security vendor facing an onslaught of attacks on its customers, but it is among the most heavily targeted. CISA has added seven vulnerabilities affecting Cisco SD-WANs and firewalls to its known exploited vulnerabilities catalog in less than three months.
Cisco Talos researchers attributed the latest round of zero-day attacks to UAT-8616, the same attackers that exploited a pair of separate zero-days in Cisco’s network edge software for at least three years before the activity was discovered and reported in February.
The company, which described the exploitation of the new zero-day as ongoing, once again declined to answer questions about the origins or motivations of UAT-8616.
“We strongly recommend customers apply the available fixed software releases and follow the guidance provided in the advisories and Cisco Talos blog,” a spokesperson for the company said in a statement.
Cisco Talos researchers also warned that UAT-8616 and at least 10 other threat groups have chained together and achieved “widespread in-the-wild active exploitation of three vulnerabilities in unpatched Cisco Catalyst SD-WAN Infrastructure.” The company previously disclosed and released patches for the vulnerabilities — including CVE-2026-20122, CVE-2026-20128 and CVE-2026-20133 — in February.
Rapid7 said it discovered the latest critical authentication bypass vulnerability when it was researching CVE-2026-20127, a previous zero-day the Five Eyes identified and confirmed as actively exploited by UAT-8616 in late 2025. Authorities and Cisco waited at least two months to disclose and patch the vulnerability, and share emergency mitigation guidance.
That campaign, which got underway at least three years prior, marked the second series of actively exploited zero-days in Cisco edge technology in less than a year. Both campaigns prompted CISA to issue emergency directives months after the attacks were first detected, and both attack sprees were underway for at least a year before they were discovered.
The latest zero-day, which bypasses authentication in the same control-plane service as CVE-2026-20127, requires no credentials or prior knowledge of the target environment for exploitation, Jonah Burgess, senior security researcher at Rapid7, told CyberScoop.
“Cisco confirmed it affects all deployment types, including on-premises, cloud, and FedRAMP environments. The SD-WAN Controller manages routing and policy for the entire overlay network, so a single compromised controller can potentially give an attacker influence over every branch, data center, and cloud edge connected to that fabric,” Burgess added.
His colleague at Rapid7, McKee, said attackers have become very good at turning weaknesses in central network infrastructure into high-impact operations.
“Compromising one branch router is useful. Compromising the controller that manages the entire estate is a very different conversation. Now you are talking about the ability to reroute traffic, intercept communications, push malicious configuration, or simply break connectivity across the whole organization,” he wrote.
“That is the real paradox here,” McKee added. “The same architecture that gives defenders scale and simplicity can also give attackers a single point of catastrophic leverage.”
While researching a critical authentication bypass vulnerability, CVE-2026-20127, which was exploited in-the-wild, Rapid7 Labs discovered a new authentication bypass vulnerability affecting Cisco Catalyst SD-WAN Controller (formerly known as vSmart), CVE-2026-20182.
This new authentication bypass vulnerability affects the “vdaemon” service over DTLS (UDP port 12346), which is the same service that was vulnerable to CVE-2026-20127. The new vulnerability is not a patch bypass of CVE-2026-20127. It is a different issue located in a similar part of the “vdaemon” networking stack.
This impact however is the same, a remote unauthenticated attacker can leverage CVE-2026-20182 to become an authenticated peer of the target appliance, and perform privileged operations, such as injecting an attacker controlled public key into the vmanage-admin user account’s authorized SSH keys file. Once this has been performed, a remote unauthenticated attacker can login to the NETCONF service (SSH over TCP port 830) as the vmanage-admin user, and begin to issue arbitrary NETCONF commands.
CVE-2026-20182 has a CVSSv3.1 score of 10.0 (Critical), and a Common Weakness Enumeration (CWE) of CWE-287: Improper Authentication.
Technical analysis
The Cisco Catalyst SD-WAN Controller serves as the central control plane. Unlike Cisco Catalyst SD-WAN Manager, it has no web UI. Its network-reachable attack surface is narrow and depending on the configuration may expose the following ports:
Port
Protocol
Service
22
TCP
SSH (OpenSSH)
830
TCP
NETCONF over SSH
12346
UDP
vdaemon DTLS control plane
⠀
UDP port 12346 is the DTLS-over-UDP control-plane peering port used by vdaemon for inter-controller and controller-to-edge communication. It carries Overlay Management Protocol (OMP) messages including route advertisements, Transport Locations (TLOC) tables, and peer state - the entirety of the SD-WAN overlay routing fabric. Compromising this service means compromising the network.
To understand the vulnerability, we first need to understand how vdaemon authenticates control-plane peers. The protocol is a multi-phase handshake over DTLS:
After a DTLS handshake completes (which accepts any client certificate), the server sends a CHALLENGE containing 256 random bytes and a set of TLVs including Certificate Authority (CA) RSA public key components. The client must respond with a CHALLENGE_ACK, and it is during the processing of this response, in vbond_proc_challenge_ack(), that device-type-specific certificate verification occurs. Or, in the case of a “vHub” device, does not occur.
The 12-byte message header format for the vdaemon protocol is as follows:
Byte Offset
Byte Size
Field
Notes
0
1
msg_type
Low nibble = type, high nibble = version
1
1
device_info
High nibble = device_type, low nibble = flags
2
1
flags
Standard value of 0xA0
3
1
padding
Always 0x00
4 - 7
4
domain_id
Big-endian uint32
8 - 11
4
site_id
Big-endian uint32
⠀
The vdaemon protocol defines the following device types, encoded in the upper nibble of header byte 1, aka device_info:
Value
Device Type
Role
1
vEdge
Data-plane router
2
vHub
Hub router
3
vSmart
Control-plane controller
4
vBond
Orchestrator (trust anchor)
5
vManage
Management plane
6
ZTP
Zero-touch provisioning
⠀
This is the core of the vulnerability. Below is a walk through of the decompiled code from vbond_proc_challenge_ack(), which processes the CHALLENGE_ACK message sent by a connecting peer. After the DTLS handshake, the function extracts the peer's certificate serial number and then enters device-type-specific verification (Note: edited for brevity):
We can see from the above that the function implements device-type-specific verification through a series of conditional blocks:
At [1] above, the function checks whether the connecting peer claims to be a vSmart (type 3) or vManage (type 5). If so, it enters a certificate serial number lookup via is_serial_duplicate(), which searches the local certificate database for a matching serial. At [2], if the serial is found, a duplicate-serial check via vbond_peer_dup_check() rejects the peer if a peer with that serial is already connected - preventing impersonation of existing authorized controllers.
At [3], a second verification block performs full certificate chain verification via vdaemon_dtls_verify_peer_cert(). This block executes only for specific (peer_type, local_type) pairs: vSmart-to-vSmart, vManage-to-vSmart, vManage-to-vManage, vManage-to-vBond, and vSmart-to-vBond. No pair in this block involves device type 2 (vHub). If the verification function returns a non-zero error, v18 is set to 0, and the function jumps to LABEL_179, which rejects the peer.
At [4], vEdge peers (type 1) enter hardware certificate verification via vdaemon_verify_peer_bidcert(). This path validates either a hardware TPM-based certificate (for physical vEdge routers) or a virtual edge certificate, including challenge-response signature verification and board ID validation. Failure sends the function to LABEL_179, which rejects the peer.
At [5], this is the bug, there is no “if” block matching a device type of 2 (vHub); the vHub device type simply has no verification code. The function falls through every conditional without entering any of them.
At [6], the function unconditionally sets “*(_BYTE *)(a2 + 70) = 1”, which is equivalent to ”peer->authenticated = true”, and returns success. The authenticated flag at peer struct offset 70 is the single bit that gates all subsequent message processing.
The following table summarizes the verification applied to each device type:
Device Type
Value
Verification
Result
vEdge
1
HW cert, challenge signature, board ID, OTP
Verified
vHub
2
None
Falls through to “peer->authenticated = 1”
vSmart
3
Cert chain, serial lookup, duplicate check
Verified
vBond
4
N/A (trust anchor - handled elsewhere)
-
vManage
5
Cert chain, serial lookup, duplicate check
Verified
⠀
Therefore, a remote unauthenticated attacker can bypass authentication by connecting to the vSmart DTLS port with any self-signed client certificate and claiming to be a vHub (type 2) in the CHALLENGE_ACK message. No valid credentials, no CA-signed certificate, and no knowledge of the SD-WAN deployment are required.
Looking further at the message dispatcher, we need to confirm that the CHALLENGE_ACK message can actually reach vbond_proc_challenge_ack() without prior authentication. The answer is in the pre-dispatch authentication gate in vbond_proc_msg():
We can see at [1] above, that the condition is a conjunction of negations: the incoming message is rejected only if the peer is NOT authenticated AND the message type is not one of the pre-authentication allowed types (CHALLENGE, CHALLENGE_ACK, NEW_CHALLENGE_ACK, CHALLENGE_ACK_ACK, Data, and TEAR_DOWN).
CHALLENGE_ACK (Message type 9) is explicitly in the allow list, meaning it passes this gate without authentication and reaches the vulnerable vbond_proc_challenge_ack(). This is by design; the authentication handshake must be able to proceed before the peer is authenticated.
Once the vulnerable vbond_proc_challenge_ack() sets “peer->authenticated = true” via the vHub bypass, the attacker must send a Hello message (Message type 5) to transition the peer to the UP state. The Hello handler has its own secondary authentication check:
// Case 5 (Hello) in vbond_proc_msg - line 20362
case 5:
// ...snip...
if ( *(_BYTE *)(v100 + 70) != 1 ) // <--- [2]
{
// "Received an unexpected HELLO from un-authenticated device"
// ... cleanup and reject ...
return 0LL;
}
// Process Hello normally - peer transitions to UP
⠀
At [2] above, the Hello handler verifies ”peer->authenticated == true” before processing. After our exploit sets this flag via the vHub bypass, Hello passes this secondary check and the peer transitions to the UP state, a fully trusted control-plane peer.
Putting all the pieces together: the attack chain is DTLS handshake (any cert) → receive CHALLENGE → send CHALLENGE_ACK with device type 2 (vHub) → authentication flag set unconditionally → send Hello → peer transitions to UP.
After establishing as an authenticated peer, the attacker has access to the full range of control-plane message types. We identified a particularly impactful post-authentication primitive: persistent SSH key injection via MSG_VMANAGE_TO_PEER (Message type 14).
The handler for message type 14 is vbond_proc_vmanage_to_peer(). Examining the decompiled code:
At [1] above, the file is opened in append mode - the attacker's key is added alongside any existing authorized keys, avoiding disruption of legitimate access. At [2], the attacker-controlled key buffer from the message body is written directly via fputs() with no sanitization.
The key injection message body is a fixed 769-byte structure:
The leading “\n” ensures correct appending regardless of whether the existing authorized_keys file ends with a newline. The null byte terminates the string for fputs(), and the remainder is zero-padded to fill the 768-byte buffer.
Any authenticated peer, regardless of device type, can inject SSH keys into the vmanage-admin user's authorized_keys file on vSmart. The vmanage-admin user is a specific internal, high-privileged service account used for automated communication between the management plane (vManage) and the control plane (vSmart/vBond). This converts a transient control-plane peering session into persistent, credential-independent high-privileged access.
Exploitation
In this example we will use the exploit developed by Rapid7 Labs and target a Cisco Catalyst SD-WAN Controller which has an IP address of 192.168.80.11. In our example, both the vdaemon service and the NETCONF service are bound to the same interface. The attacker will have an IP address of 192.168.80.130. In our example, the target Cisco Catalyst SD-WAN Controller appliance is running version 20.12.6.1, which was the latest available version of the 20.12.* branch at the time of writing.
To begin, the attacker loads the module in Metasploit and configures the required options.
Figure 1: Metasploit module options for cisco_sdwan_vhub_auth_bypass
⠀
The module will perform the authentication bypass and then inject an attacker controlled SSH public key into the authorized keys file for the vmanage-admin user. The module will generate a new RSA key-pair prior to exploitation, so that the attacker will inject a public key for which they have the corresponding private key.
The attacker then sets the target and runs the module.
msf6 auxiliary(admin/networking/cisco_sdwan_vhub_auth_bypass) > set RHOSTS 192.168.80.11
msf6 auxiliary(admin/networking/cisco_sdwan_vhub_auth_bypass) > run
⠀
Figure 2: Module output showing the vHub authentication bypass and SSH key injection
⠀
The attacker can now SSH into the NETCONF service over TCP port 830 by running the following command (as instructed by the exploit above).
SSH public key authentication will succeed, and the attacker will have successfully established a connection to the NETCONF service.
Figure 3: Successful SSH connection to the NETCONF service as vmanage-admin
⠀
At this point the attacker can begin to execute arbitrary NETCONF commands, for example the following “get-config” command can be run by the attacker in the NETCONF session.
The output of the get-config command is shown below.
Figure 4: NETCONF get-config output from the compromised controller
Remediation
Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.
Customers are advised to upgrade to an appropriate fixed software release as indicated in the Fixed Software section of the Cisco Security Advisory. The following tables indicate the appropriate fixed software releases.
For additional details, please see the vendor advisory.
Vendor statement
"Cisco values the role of the security research community in helping maintain a secure ecosystem and we appreciate the collaboration with Rapid7. We have released a software update to remediate the identified vulnerability. We remain committed to transparent communication and to providing our customers with the robust security and resilience they expect."
Rapid7 customers
Exposure Command, InsightVM and Nexpose customers will be able to assess their exposure to CVE-2026-20182 with an authenticated vulnerability check expected to be available in the May 14th, 2026 content release.
Credit
This vulnerability was discovered by Stephen Fewer, Senior Principal Security Researcher, and Jonah Burgess, Senior Security Researcher, both at Rapid7 and is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.
Disclosure timeline
March 9, 2026: Rapid7 makes initial outreach to Cisco who confirms contact the same day. Rapid7 discloses the technical writeup and exploit code to Cisco.
March 11, 2026: Cisco confirms receipt of the technical writeup and exploit code and suggests a disclosure date of May 7, 2026.
March 20, 2026: Cisco confirms the vulnerability findings, and that a CVE will be reserved.
April 21, 2026: Cisco provides reserved CVE identifier and remediation guidance.
April 24, 2026: Cisco provides remediation version numbers, alignment on CWE and CVSS scoring, and requests moving disclosure date to May 14.
May 14, 2026: This disclosure.
Updates
May 15, 2026: Added link to the Metasploit module.
Microsoft addressed another triple-digit batch of vulnerabilities cutting across its various enterprise products, components and underlying systems. Yet despite the high number of defects, the vendor reported no actively exploited zero-days in this month’s Patch Tuesday update.
Thirteen of the 137 vulnerabilities Microsoft disclosed were assigned critical CVSS ratings, including a pair of vulnerabilities affecting Azure — CVE-2026-33109 and CVE-2026-42823 — and CVE-2026-42898 in Microsoft Dynamics 365 with 9.9 CVSS scores.
The company designated 13 vulnerabilities as more likely to be exploited, and 113 defects as less likely or unlikely to be exploited.
The high volume of vulnerabilities reflects a growing trend researchers have been anticipating as artificial intelligence models are deployed to find previously uncovered defects in code.
While not all of these bugs were found by AI, it’s likely they had an AI-related component — even if it was just AI writing the submission,” Dustin Childs, head of threat awareness at Trend Micro’s Zero Day Initiative, wrote in a blog post Tuesday.
Childs was especially intrigued by CVE-2026-41096, which he described as a “nasty-looking bug” in Microsoft Windows DNS that allows unauthorized attackers to run code remotely.
“No authentication or user interaction needed, and since the DNS Client runs on virtually every Windows machine, the attack surface is enormous. An attacker with a position to influence DNS responses could achieve unauthenticated remote-code execution across your enterprise,” he added.
Childs also described CVE-2026-41089, a Windows Netlogon defect that allows unauthenticated remote attackers to run code, as the “highest-impact bug that requires immediate patching,” adding that a “compromised domain controller is a compromised domain.”
Jack Bicer, director of vulnerability research at Action1, called out CVE-2026-42898, the critical vulnerability affecting Microsoft Dynamics 365.
“With no user interaction required, and the potential to impact systems beyond the vulnerable component’s original security scope, this vulnerability poses serious enterprise risk: an attacker with only basic access could turn a business application server into a remote execution platform,” he said in a blog post.
“Compromise of Dynamics 365 infrastructure can expose customer records, operational workflows, financial information, and integrated business systems. Since CRM environments often connect with identity services, databases, and enterprise applications, successful exploitation could lead to broader organizational compromise and operational disruption,” Bicer added.
Google researchers found a zero-day exploit developed by artificial intelligence and alerted the susceptible vendor to the imminent threat before a well-known cybercrime group initiated a mass-exploitation campaign, the company said in a report released Monday.
The averted disaster probably isn’t the first time attackers used AI to build a zero-day, but it is the first time Google Threat Intelligence Group found compelling evidence that this long-predicted and worrying escalation in vulnerability-exploit development is underway.
“We finally uncovered some evidence this is happening,” John Hultquist, chief analyst at GTIG, told CyberScoop. “This is probably the tip of the iceberg and it’s certainly not going to be the last.”
Google declined to identify the specific vulnerability, which has been patched, or name the “popular open-source, web-based administration tool” it affected. It did, however, note that the defect impacted a Python script that allows attackers to bypass two-factor authentication for the service.
Researchers also withheld details about how they discovered the zero-day exploit or the cybercrime group that was preparing to use it for a large-scale attack spree.
The threat group has a “strong record of high-profile incidents and mass exploitation,” Hultquist said, suggesting the attackers are prominent and well-known among cybersecurity practitioners.
GTIG is fairly confident the threat group was using AI in a meaningful way throughout the entire process, but it has yet to determine if the technology also discovered the vulnerability it ultimately developed into an exploit.
Whichever AI model the attackers used — Google is confident it wasn’t Gemini or Anthropic’s Mythos — left artifacts throughout the exploit code that are inconsistent with human developers. This evidence, which included documentation strings in Python, highly annotated code and a hallucinated but non-existent CVSS score, tipped Google off to the fact AI was heavily involved, Hultquist said.
GTIG has been warning about and expecting AI-developed exploits to hit systems in the wild, especially after its Big Sleep AI agent found a zero-day vulnerability in late 2024.
“I think the watershed moment was two years ago when we proved this was possible,” Hultquist said, adding that there are probably several other AI developed zero-days in play now.
Yet, to him, the discovery of a zero-day exploit developed by AI is less concerning than what this single instance forebodes even further.
“The game’s already begun and we expect the capability trajectory is pretty sharp,” Hultquist said. “We do expect that this will be a much bigger problem, that there will be more devastating zero-day attacks done over this, especially as capabilities grow.”
A defense technology company with Department of Defense contracts exposed user records and military training materials through API endpoints that lacked meaningful authorization checks, according to an account published by Strix, an open-source autonomous security testing project.
The issue affected Schemata, an AI-powered virtual training platform used in military and defense settings. According to Strix, an ordinary low-privilege account was able to access data across multiple tenants, including user listings, organization records, course information, training metadata and direct links to documents hosted on the Schemata’s Amazon Web Services instances.
Strix said the exposed materials included a 3D virtual training course for naval maintenance personnel with documentation marked confidential and proprietary, a course containing Army field manuals on explosive ordnance handling and tactical deployment, and hundreds of user records linked to bases and training enrollments. Additionally, the exposed information included names, email addresses, enrollment details and the military bases where U.S. service members were stationed.
Schemata acknowledged the affected endpoints were exposed May 1, after what Strix described as a 150-day disclosure process. Strix said it verified remediation before publication and published its account earlier this week, 152 days after its initial disclosure attempt.
The reported vulnerability did not require a complex exploit. Strix said it used a low-privilege account to watch normal browser traffic, identify API endpoints exposed through the application, and request high-value data using the same session. According to Strix, those requests returned records from outside the account’s own organization, suggesting the API was not properly enforcing tenant boundaries or user permissions.
In multi-tenant software, authorization controls are intended to ensure users can access only the data and functions assigned to their account or organization. The failure described by Strix would represent a basic breakdown in that model. The firm said some routes also appeared “write-enabled,” meaning a malicious actor could potentially modify or delete courses through update or delete requests, though the account does not say Strix performed destructive testing.
Strix did not respond to CyberScoop’s request for comment.
Schemata’s platform serves military and defense training environments, where user identities, assignments and course enrollments can reveal sensitive operational context. Even when information is not classified, records showing where service members are based, what training they are enrolled in and which materials they can access may create risks if exposed outside intended channels.
In a statement posted on the company’s website, Schemata said it did not have “evidence that any third party exploited the vulnerability to access customer data.”
The disclosure timeline also raises questions about how companies handling sensitive government-related data receive and respond to vulnerability reports. Strix said it first contacted Schemata on Dec. 2, 2025. According to the account, Schemata’s CEO initially responded, “I would love to hear what the vulnerability is, but I assume you want to get paid for it. Is that the play?”
Strix said it clarified the same day that compensation was not required and that its priority was user safety. It said it sent multiple follow-ups from Dec. 8-29, warning that the vulnerability was critical and asking where to send details. Five months later, after telling Schemata that researchers were publishing the information publicly, Schemata responded, acknowledged the exposed endpoints and said it would patch the issue immediately.
“After we received actionable details about the vulnerability and confirmed the security researcher appeared to be legitimate, our team remediated the vulnerability the same day, and the researcher independently verified the fix before publishing their findings,” Schemata’s statement reads. “We appreciate the security researcher bringing this to our attention and their contribution to the security of our platform.”
Schemata said it’s working with cybersecurity consultants to assist with its response and improve its security posture. The company also said it is in contact with government authorities about the vulnerability.
Defense contractors that handle Controlled Unclassified Information, or CUI, must report cyber incidents to the Department of Defense Cyber Crime Center (DC3). The center did not respond to CyberScoop’s request for comment.
Attackers are actively exploiting a Linux vulnerability in the wild, and researchers warn that the fallout could be broad — anyone with authenticated local access can leverage it to gain total control of a system.
But the story behind CVE-2026-31431 is almost as interesting as the bug itself. Theori, the company that discovered the bug, leaned heavily on AI to find and initially disclose it. The result is a case study that underscores the challenges that occur when the relentless hunt for defects collides with marketing impulses and inflated AI-generated language that was long on bluster but lacked technical details.
Theori dubbed the high-severity vulnerability “Copy Fail” with a vanity domain containing AI-generated content, and warned that every mainstream Linux kernel built since 2017 is in scope of potential exploitation resulting in root access.
Theori’s AI-powered penetration testing platform, Xint, discovered the local privilege-escalation flaw in a Linux kernel module and reported it to the Linux kernel security team March 23. Major Linux distributions affected by the vulnerability had issued patches prior to Theori’s disclosure, which it published alongside a proof-of-concept exploit.
The Cybersecurity and Infrastructure Security Agency added CVE-2026-31431 to its known exploited vulnerabilities catalog Friday.
Researchers have yet to determine how many organizations have been impacted by the flaw, but they noted that critical requirements for exploitation, specifically local access achieved through a separate exploit or pathway to unauthorized access, should limit potential exposure.
“The attacker would need to have already established a foothold on the target system either through some means of legitimate access or another exploit,” Spencer McIntyre, secure researcher at Rapid7, told CyberScoop. “That’s a large limiting factor since this vulnerability would therefore need to be paired with another.”
Theori’s disclosure turned heads among other vulnerability researchers who noted the defect’s broad potential impact, but also for lacking details about the proof-of-concept exploit.
“The exploit is real, there is something to worry about, but understandably, teams now have to do additional validation to know how to parse the extreme AI FUD (fear, uncertainty and doubt) from [Theori’s] blog post,” Caitlin Condon, vice president of security research at VulnCheck, told CyberScoop.
“It’s not helpful that the blog is AI slop, because it detracts from technical reality,” she added.
Theori acknowledges it used AI to discover and describe the vulnerability, explaining that it’s focusing on finding and fixing a large amount of defects.
“We used AI to help craft the disclosure site and the blog post to help speed things up, but all material was thoroughly reviewed by our internal teams for accuracy,” said Tim Becker, senior security researcher at Theori.
Theori is intentionally withholding additional details until the patch is broadly applied, he added.
“We stand by our technical description of the vulnerability. Helping downstream users to understand the impact of a security bug has always been a challenge for security researchers,” Becker said. “Copy Fail allows for trivial privilege escalation on most desktop and server Linux distributions. It also has implications for containerization including Kubernetes.”
Other researchers have drawn similar conclusions, noting that exploitation can be automated and doesn’t require specialization.
Meanwhile, hundreds of additional proof-of-concept exploits have surfaced since the vulnerability was disclosed five days ago. “As expected, the majority of these appear to be copycat AI PoCs that do nothing but add banners or different colors to the command-line interface. Many new PoCs are simply ports of the original AI PoC to a different programming language,” Condon said.
“Organizations should exercise caution when running untested research artifacts, including AI-generated exploit code that isn’t fully explained,” she added.
Becker said Theori is aware of the burden defenders confront, and insists the company’s reports contain enough information for organizations to quickly triage and validate its findings.
Rapid7 Labs recently identified a chain of security vulnerabilities in the Gainsight Assist plugin and its interactions with the associated domain app.gainsight.com. These vulnerabilities include an Information Disclosure flaw (CVE-2026-31381) and a Reflected Cross-Site Scripting (XSS) vulnerability (CVE-2026-31382). By chaining these vulnerabilities, an attacker can move from passive information gathering to active client-side exploitation.
The XSS vulnerability was remediated by Gainsight via a server side code-level fix on March 6, 2026. A patched update to the Chrome and Outlook plugins to remediate the Information Disclosure were released on March 9, 2026.
Product description
Gainsight Assist is a plugin that allows users to access Gainsight email templates and easily sync inbound and outbound emails to the Timeline within the Gainsight Customer Success (CS) product directly from their email platform.
Credit
These vulnerabilities were discovered and reported to the Gainsight team by Christopher O’Boyle, Cybersecurity Advisor at Rapid7. The vulnerabilities are being disclosed in accordance with Rapid7's vulnerability disclosure policy. Rapid7 is grateful to the Gainsight team for their assistance and collaboration.
Information Disclosure: An attacker can extract user email addresses (PII) exposed in base64 encoding via the state parameter in the OAuth callback URL.
Reflected XSS / HTML Injection: The error_description parameter is vulnerable to Reflected XSS. An attacker can bypass the domain's WAF using a Safari-specific onpagereveal payload.
The testing target was the Gainsight Assist plugin and its interactions with the app.gainsight.com domain, used as a callback mechanism that processes authentication data and error descriptions following user login attempts.
CVE-2026-31381: Information disclosure
During testing involving Salesforce and Okta authentication channels, an OAuth callback flow failure was observed. The resulting error message exposed the user's email address (PII) within a Base64 encoded state parameter in the URL. Because Base64 is merely obfuscation and not encryption, these email addresses can be easily harvested from server logs, proxies, or browser history by third parties.
CVE-2026-31382: Reflected XSS and HTML injection
The Gainsight callback URL contained an error_description parameter that was found to be vulnerable to content spoofing and HTML Injection. While Gainsight employs a Web Application Firewall (WAF) that successfully blocks most standard JavaScript execution, Rapid7 researchers bypassed this protection using a browser-specific payload targeting Safari’s onpagereveal event.
When the victim opens the malicious URL in Safari, the onpagereveal payload executes automatically without further user interaction. By injecting HTML content and spoofing the error page, an attacker can create a legitimate-looking prompt instructing the user to switch to a Safari browser to ensure the payload fires.
<body onpagereveal=open("https://www.rapid7.com")>
We have detected a browser compatibility issue for
this step, this can only be completed on Safari <br><br>
Please copy the URL from the address bar above and
paste it in a Safari browser...
Figure 1: Example of the injected HTML payload instructing the user to utilize Safari.
Chaining for Impact
When combined, these vulnerabilities create a high-impact attack path:
Target identification:The login error page includes the user’s attempted login email address in a Base64-encoded state parameter in the URL. Anyone with visibility into that URL (e.g., via the browser address bar, existing access to internal logs, or XSS on that page) can decode the state value to recover the email address. The vulnerability pertains to the data included in the URL rather than granting access to logs or history.
Luring the victim: Using HTML injection on the trusted app.gainsight.com domain, the attacker crafts a highly convincing phishing link to send to the targeted user.
XSS execution: Once the victim opens the link in Safari, the onpagereveal payload executes. Because the payload can recursively call the exact same URL, it can cause an infinite loop leading to client-side resource exhaustion, log flooding, or the delivery of malware.
Vendor statement
"Gainsight values the work of the security research community and appreciates Rapid7's collaboration. We have fully remediated the identified vulnerabilities through a platform-wide update that strengthens our input validation and WAF configurations. Our forensic investigation found no evidence of exploitation or impact to customer data. We continue to prioritize transparency and supporting our customers to build a more resilient and secure community together. "
Mitigation guidance
As of March 6, 2026, Gainsight has implemented a code-level fix to remediate these findings. Customers should ensure they are utilizing the latest version of the Gainsight Assist plugin.
Disclosure timeline
January 30, 2026: Rapid7 makes initial outreach to Gainsight.
February 1, 2026: Gainsight confirms outreach and requests details. Rapid7 provides vulnerability details.
February 11, 2026: Gainsight confirms receipt, states that the vulnerability has been reproduced, and acknowledges that triage has begun.
March 5, 2026: Gainsight and Rapid7 meet to discuss agreed impact, remediation, and next steps.
March 6, 2026: Gainsight implements a server-side, code-level fix to remediate the XSS issue.
March 9, 2026: Gainsight implements an update to the Chrome and Outlook plugins for the information disclosure vulnerability.
March 12, 2026: Gainsight requests disclosure date of March 20, 2026.
March 13, 2026: Rapid7 accepts the disclosure date of March 20, 2026.
Login
