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.

Because yes, the phones are still listening.

Imagine you build a massive corporate campus with every security control money can buy. Blast resistant doors. Biometric scanners. Guards at every entrance. Maybe something similar to the infamous Death Star. On paper, it looks fantastic. Then, somewhere along the way, somebody decides the maintenance team needs a universal key that opens every door in the building without setting off any alarms.

That certainly makes operations easier, but it also means one mistake, one compromise (like a well placed photon torpedo), or one very bad decision can unravel the whole thing.

That is basically the problem we keep running into in modern enterprise networking.

Why SD-WAN controllers create concentrated risk

This week, Rapid7 researchers Stephen Fewer and Jonah Burgess disclosed CVE-2026-20182, a maximum severity (CVSS 10.0) vulnerability in the Cisco Catalyst SD-WAN Controller. The technical details matter, and quite a bit, at that, but the bigger lesson here is even more important. This bug is a reminder that we keep designing infrastructure for efficiency first and then acting surprised when attackers go after the one component that controls everything.

To put it simply, the flaw behaves like a master key. 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. That is the cybersecurity version of a Jedi mind trick. The controller is effectively told to trust something it has no business trusting, as if an attacker waves a hand and says, “these are not the droids you are looking for”. And with CVE-2026-20182, the controller just nods and lets them pass.

And that becomes extremely important when you look at how these environments are built.

A decade ago, managing a global enterprise network meant touching thousands of individual routers across branch locations. It was slow, error-prone, and frankly a little miserable for the people responsible for keeping it all running. So the industry did what the industry usually does. We centralized control. We pulled the decision-making out of all those edge devices and moved it into a central controller.

From an operations standpoint, that was a huge win. I will gladly give credit where it is due. SD-WAN solved real problems.

It also created a very attractive target.

Why central management platforms are attractive targets

Once you move the brains of the operation into a single place, that place becomes the thing an attacker wants most. 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.

That is the real paradox here. The same architecture that gives defenders scale and simplicity can also give attackers a single point of catastrophic leverage.

A few years ago, finding and exploiting a quiet authentication bypass in a core networking appliance was mostly the work of highly capable nation-state teams. That is not the world we live in anymore, especially as AI makes exploitation faster to analyze, adapt, and operationalize. The reality of it is that offensive tradecraft does not stay exclusive for very long. It gets copied, adapted, automated, and eventually handed down to groups with very different goals.

For nation-state operators, a bug like this (as seen with the actively exploited CVE-2026-20127) is ideal for pre positioning. They are usually not looking for a smash and grab. They want persistence. They want access that blends in. They want to sit in the right place long enough to observe, influence, and pivot when the time is right. An SD-WAN controller is a great place to do that, because it lives in the middle of trust relationships most organizations rarely question.

For ransomware groups, the value proposition is even more obvious. If you can compromise central infrastructure, you do not have to fight for access to one system at a time. You are standing on the control plane of the enterprise, facing a dramatically lower barrier to initial access and large-scale disruption.

Now, to be fair, not every bug turns into internet wide exploitation overnight and not every vulnerability becomes a one click offensive toolkit. We should avoid sensationalizing that part. But we should also be honest about where the pressure is today. Attackers have become very good at turning central infrastructure weaknesses into high impact operations.

What defenders should do now

First, bugs like this are going to happen again. As long as we keep building extremely complex systems to manage global infrastructure, there will be flaws. That is not cynicism. That is just reality.

Second, organizations need to stop assuming that trusted administrative systems are inherently safe just because they sit in the middle of the network and have important sounding names. If your controller is compromised, what happens next? What can it reach? What can it change? How much of the enterprise can it influence without another human ever noticing?

That blast radius question is the one that matters.

Defending against this kind of problem requires more than patching, even though patching absolutely needs to happen. It means building environments that can survive the compromise of a critical management system. Network segmentation matters. Monitoring administrative traffic matters, whether that is handled internally or through an MDR provider that can help catch suspicious behavior before it turns into a much larger problem. Tight control over outbound communications from infrastructure devices matters. So does limiting which systems are allowed to talk to the controller in the first place.

In other words, we need to design with the assumption that even high trust infrastructure can fail in ugly ways.

The immediate guidance for defenders is straightforward: apply the vendor supplied patches for Cisco Catalyst SD-WAN Controllers as quickly as possible. That is the first move, not the last one.

The longer term lesson for leadership is bigger than this one vulnerability. Efficiency is great right up until it creates unquestioned authority in a single device or platform. When that happens, you have not removed complexity. You have concentrated risk.

And attackers have noticed.

Register for Rapid7’s upcoming webinar on CVE-2026-20182 here.

Anthropic’s Project Glasswing matters because it offers an early look at how quickly software flaws may soon be found, validated, and potentially turned into viable attack paths, even if that capability is currently limited to a closed partner program. Anthropic says its restricted Claude Mythos Preview model has already identified thousands of high-severity vulnerabilities, including flaws in major operating systems and browsers, and in some cases developed related exploits autonomously.

Some early coverage has emphasized the risks and need for restraint in deploying capabilities like this, and for most organizations, it won’t immediately change day-to-day security operations. What it does offer is a signal of where the industry may be heading: a future where discovery moves faster, and where the pressure shifts to everything that follows, including prioritization, remediation, validation, and response. Glasswing feels less like the storm itself and more like the first sign that the radar is getting better faster than the emergency plan. How well can we handle what comes next?

What is Project Glasswing?

Project Glasswing is Anthropic’s new defensive security initiative built around Claude Mythos Preview, a model the company is not releasing publicly because of its cyber capabilities. Anthropic says the preview is being provided to a limited set of organizations, including AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, Nvidia, and Palo Alto Networks, with access also extended to more than 40 additional organizations. Anthropic has also committed up to $100 million in usage credits and additional support for open-source security work. 

That makes this more than another AI feature release. Anthropic is effectively signaling two things at once. First, there is a meaningful backlog of serious, undisclosed vulnerabilities still out there. Second, capabilities like this are sensitive enough that broad public release would be irresponsible right now. For security leaders, the message is not that AI replaces human researchers. It is that AI is becoming materially more useful in vulnerability research, and defenders should be thinking now about how they will handle what comes next.

Why this matters to vulnerability management

It would be easy to read this as a story about faster vulnerability discovery alone. That misses the more important point. If Anthropic’s claims are directionally right, the immediate pressure does not land on discovery alone. It lands on everything downstream of discovery: asset context, exploitability analysis, ownership, compensating controls, patching, exception handling, validation, and detection coverage. In other words, the harder part of security becomes more obvious.

That matters because most enterprise programs do not struggle to generate findings. They struggle to decide which findings matter first, who should act, what can wait, and whether remediation actually reduced exposure. If AI pushes vulnerability discovery into a new gear, weak operating models will feel that pressure first. Backlogs get bigger. Teams drown in queues. Fix rates do not keep pace. Risk stays put. That is not a model problem. It is an execution problem. 

This is why security leaders should be careful with the framing. The headline is not “AI found bugs, therefore security improves.” The headline is that the bottleneck may be moving downstream even faster than expected. That raises the value of programs that connect exposure management, remediation, and runtime defense instead of treating them as separate activities. 

What Anthropic’s examples really tell us

Some of the reported examples are striking. Anthropic and media reports say Mythos Preview found a 27-year-old OpenBSD vulnerability, a 16-year-old FFmpeg flaw that reportedly evaded millions of automated test executions, and multiple Linux kernel vulnerabilities that could be chained together. Anthropic has also said the model reproduced vulnerabilities and built proof-of-concept exploits at a high success rate in testing. Even if individual examples get debated over time, the pattern is the important part. The model appears to compress several human steps into one workflow, from discovery to validation to exploit construction. 

Security has seen faster discovery before. Fuzzing changed the game. Better automation changed the game. Large-scale bug bounty operations changed the game. What is different here is the combination of reasoning, coding, persistence, and iteration inside a single model loop. If that loop becomes reliable, then defender workflows built for human-speed intake and triage will come under more strain. That does not make coordinated disclosure obsolete. It makes today’s processes look slow.

What CISOs should ask right now

CISOs do not need to decide this week whether Anthropic’s model changes the entire market. They do need to ask a more practical question: if my environment starts surfacing materially more vulnerabilities tomorrow, what happens next?

For many organizations, that answer is uncomfortable. Findings land in multiple tools. Asset inventory is incomplete. Internet exposure is only partly understood. Ownership is fragmented. Patch cycles are slow. Exceptions pile up. Security teams cannot easily prove that a fix changed reachable risk in the real environment.

That is where this news becomes relevant. AI-driven discovery does not reduce the need for an exposure-led security model. It increases it. The organizations that benefit most will not be the ones with the biggest pile of findings. They will be the ones that can connect those findings to business-critical assets, internet exposure, identity paths, existing detections, remediation workflows, and validation. 

A good board-level translation is that faster discovery only has value if the organization can prioritize effectively, remediate quickly, and prove that the fix reduced real exposure. Otherwise, the result is more volume and more noise.

What engineers should take away from Project Glasswing

For engineers, this announcement is less a reason to either celebrate or dismiss the technology than it is a sign that defensive research workflows may change quickly if capabilities like this spread more broadly. Today, Glasswing is still limited to a small group of trusted partners, so this is not yet a shift most engineering teams will feel directly in their daily work. What it does offer is an early look at where software security may be heading.

AI-assisted discovery is likely to become more common across secure development, code review, infrastructure testing, and open-source maintenance. That creates real opportunities. Models can help explore deep code paths faster, challenge assumptions earlier, improve reproduction, and generate more detailed reports than many conventional workflows produce today.

The harder question is what comes next. If AI can generate more findings and more exploit hypotheses, engineering teams will need stronger intake, validation, and prioritization discipline, not less. Triage quality, deduplication, severity context, reproducibility, and ownership all become more important as discovery speeds up. Many maintainers and internal product security teams already struggle with volume, and machine-generated reporting could make that problem worse if workflows do not mature alongside the tooling.

At the same time, that is only one side of the equation. If models can help find bugs faster, they may also help defenders confirm impact, suggest code changes, support patch development, and reduce some of the manual effort that slows remediation today. In the longer run, the same AI shift that increases pressure on defenders may also help them absorb some of that pressure. The real issue is not whether AI adds more findings. It is whether teams can use it to shorten the full path from discovery to decision to verified fix.

The best engineering response, then, is not to argue about whether these models are impressive. It is to improve the operating path around them. Can the team confirm impact quickly, tie a flaw to reachable attack surface, deploy a patch or control change, and verify that exposure is actually reduced in production? If that chain does not improve, faster discovery alone will not deliver much value.

What this means for the next phase of security

Anthropic’s decision to restrict access is understandable, but it also underscores a harder truth - capabilities like this rarely stay contained for long. Whether through competitors, open customization, or less restrained releases, the broader industry should assume similar models will become more widely available in the near term. For most organizations, this is not a market-wide operational shift today. It is a warning of what may be closer than it appears.

That signal arrives at a time when many security operations teams are already under strain. Most can investigate only a fraction of the alerts and exposures their environments generate, which keeps them in reactive mode, manually triaging high-priority signals across fragmented telemetry while scale and consistency remain difficult to achieve. Many promises of AI super-productivity have not yet translated into day-to-day operational relief. That is part of what makes Glasswing worth paying attention to. It points to a future where discovery may improve faster than most response models do.

It also points to an opportunity. If AI can compress parts of vulnerability research, the same broader class of capabilities may eventually help defenders improve prioritization, investigation, remediation, and validation as well. That is where the next phase of security is likely to be decided. Not in whether organizations can generate more findings, but in whether they can use AI to make response workflows faster, more consistent, and more precise.

From our perspective, that raises the operational bar for defenders. If discovery gets faster, organizations will need to shorten time to detect, accelerate time to patch, and manage vulnerability backlogs with far more urgency than they do today. That starts with a threat-led view of the environment. Teams need to understand which weaknesses are most exposed, most exploitable, and most likely to matter in real attack paths so they can prioritize action based on actual risk, not just queue depth.

That is the practical lesson from Glasswing. It feels less like the storm itself and more like the first sign that the radar is getting better faster than the emergency plan. For most organizations, the announcement does not change the queue tomorrow morning. What it does change is the urgency of preparing for a future in which discovery, triage, and response may all begin moving at a very different pace.