Amid a stream of new vulnerabilities in Cisco’s Catalyst SD-WAN Manager, some researchers are arguing that organizations have misplaced their focus, hyperfixating on one critical vulnerability with a lot of noise around it, but overlooking another, quieter bug that’s just as serious.
On Feb. 25, Cisco publicly disclosed half a dozen newfound bugs in its Software-Defined Wide Area Network (SD-WAN) management product. At least three have been exploited in the wild. One, CVE-2026-20127, in addition to earning the highest possible 10 out of 10 score in the Common Vulnerability Scoring System (CVSS), appears to have been exploited as a zero-day by one threat actor for at least three years.
In that light, it’s no wonder that CVE-2026-20127 attracted as much attention as it has. And yet, some other reasons for concern have been less well-founded. Researchers at VulnCheck found that public proof-of-concept (PoC) exploits for this issue have been a mixed bag: some are outright fake, some are misleading, and all are rather confusing for organizations trying to keep up. And with all the oxygen being taken up by CVE-2026-20127, they argued in a blog post, there’s another vulnerability in the mix that’s not getting as much attention as it should: CVE-2026-20133.
CVE-2026-20127 vs. CVE-2026-20133
Though CVE-2026-20127 is certainly worth time and attention, VulnCheck’s researchers found that CVE-2026-20133 can also be used to interesting effect. This less heralded issue is an information-disclosure bug that earned a high-severity 7.5 out of 10 CVSS score. It isn’t known to have been exploited in the wild yet.
When the researchers played around with CVE-2026-20133, they found that the file system access it affords allowed them to grab the private key associated with the default “vmanage-admin” user. That key allowed them to compromise the Network Configuration Protocol (NETCONF) used to configure and manage SD-WAN devices. They also leaked a shared secret for internal communication — “confd_ipc_secret” — which could allow any local user to escalate to root. Besides just enjoying access, attackers could use these kinds of secrets to push configuration changes to an organization’s network, manipulate traffic ingress and egress, and theoretically much more.
VulnCheck couldn’t get a precise gauge on how many Cisco SD-WAN Managers are publicly accessible from the Internet, as different search engines returned anywhere from 275 to thousands of results. In addition to patching, organizations can consider reducing their exposure to CVE-2026-20127, CVE-2026-20133, and other vulnerabilities like them by removing their systems from the browsable Web.
Don’t Be Fooled by Fake PoCs
Not long after Cisco’s security advisory went public, a number of PoCs popped up on the Web, claiming to work against CVE-2026-20127. VulnCheck found that several were non-functional or clearly fraudulent.
“Typically for these types of emerging threats, we’ll see two, three, five, or more than that,” says Caitlin Condon, vice president of security research at VulnCheck. “Sometimes PoCs are completely fake, or nonfunctional, or malicious. It’s certainly not unusual these days to see a wave of AI-slop PoCs targeting emerging bugs. We don’t see as many valid, public PoCs popping up in the first couple of days after one of these incidents is disclosed.”
The most interesting CVE-2026-20127 PoC was developed by GitHub user “zerozenxlabs.” It wasn’t fake — it did work — but it had nothing to do with the vulnerability it purported to exploit. It was, in fact, an exploit chain that stringed together three of the other new vulnerabilities in the SD-WAN Manager. According to the researchers, it combined CVE‑2026‑20128 and CVE‑2026‑20133 to access and read a credential file, then used CVE-2026-20122 in its application programming interface (API) to upload a webshell.
For Condon, “part of the lesson here is that we are seeing very quickly, I think, the devaluation of public PoC code as a first-class risk signal. For many organizations, there are too many critical bugs to patch — too many products and vulnerabilities to pay attention to, and be able to prioritize. Organizations are overwhelmed. And usually that emergency take-action moment is when people are saying: ‘Hey, there’s public PoC for this, now you really need to pay attention.’ ‘PoC or GTFO’ has been one of the common industry adages for many years.”
But instead of “PoC or GTFO,” she argues, organizations should focus on signs of verified exploitation in the wild. “It’s very difficult to figure out, sometimes, whether fake PoCs are actually fake, because they’re convincingly fake,” she says. “Real-world exploitation signals have become much more important as the value of public PoCs is being diluted.”
Real PoCs Have Value
The first verifiable, solid PoC for CVE-2026-20127 finally arrived on March 11, courtesy of a Rapid7 security researcher. As a result, VulnCheck expects real exploitation attempts in the wild to ramp up.
It raises an age-old question: By publishing working PoCs, are security researchers helping cyberattackers more than they’re helping defenders?
“Researchers have a super important place in this ecosystem,” Condon argues. “Their ability to demonstrate exploitability and validate that a vulnerability really does have real world impact is still critical. I, personally, think that is very useful in the public.”
To support her point, she notes that a third of vulnerabilities from 2025 still have no public exploit code. “But, many of them are being used by multiple ransomware groups,” she says. “So the only people who have those exploits in full are adversaries, and they’re continuing to be used to [great] effect. Many organizations are very nervous about exploit code being public. I understand where that comes from. However, in that type of situation, is it better for only adversaries — and often several of them — to have that exploit? I’ll leave that question for readers to answer, but my position would be: no.”
