Network security devices endanger orgs with ’90s era flaws – CSO Online

Enterprises have long relied on firewalls, routers, VPN servers, and email gateways to protect their networks from attacks. Increasingly, however, these network edge devices are becoming security liabilities themselves.

Every few weeks, another crisis plays out: Security teams scramble to patch and scan their network appliances for malware implants after another zero-day attack is newly reported. Vendors emphasize that sophisticated nation-state actors carry out these attacks, but critics question why the basic flaws being exploited — buffer overflows, command injections, SQL injections — remain prevalent in mission-critical codebases maintained by companies whose core business is cybersecurity.

Attackers constantly evolve their techniques. Security engineering, inherently challenging, can’t fix everything. All software products have vulnerabilities, even security tools. These would be valid responses if we were dealing with complex flaws, says Benjamin Harris, CEO of cybersecurity and penetration testing firm watchTowr. “But these are vulnerability classes from the 1990s, and security controls to prevent or identify them have existed for a long time. There is really no excuse.”

Network edge devices: The new battleground

Google’s Threat Intelligence Group tracked 75 exploited zero-day vulnerabilities in 2024. Nearly one in three targeted network and security appliances, a strikingly high rate given the range of IT systems attackers could choose to exploit. That trend has continued this year, with similar numbers in the first 10 months of 2025, targeting vendors such as Citrix NetScaler, Ivanti, Fortinet, Palo Alto Networks, Cisco, SonicWall, and Juniper.

Network edge devices are attractive targets because they are remotely accessible, fall outside endpoint protection monitoring, contain privileged credentials for lateral movement, and are not integrated into centralized logging solutions. Yet researchers have reported vulnerabilities in these systems for over a decade with little attacker interest beyond isolated incidents.

That shifted over the past few years with a rapid surge in attacks, making compromised network edge devices one of the top initial access vectors into enterprise networks for state-affiliated cyberespionage groups and ransomware gangs.

The COVID-19 pandemic contributed to this shift, as organizations rapidly expanded remote access capabilities by deploying more VPN gateways, firewalls, and secure web and email gateways to accommodate work-from-home mandates.

The declining success rate of phishing is another factor. Once the top initial access vector, phishing has become less effective thanks to defense efforts over the past 10 years. For 2024, Mandiant reported that 33% of intrusions resulted from exploits, 16% from stolen or weak credentials, and only 14% from phishing.

“Attackers are not trying to do the newest and greatest thing every single day,” watchTowr’s Harris explains. “They will do what works at scale. And we’ve now just seen that phishing has become objectively too expensive or too unsuccessful at scale to justify the time investment in deploying mailing infrastructure, getting domains and sender protocols in place, finding ways to bypass EDR, AV, sandboxes, mail filters, etc. It is now easier to find a 1990s-tier vulnerability in a border device where EDR typically isn’t deployed, exploit that, and then pivot from there.”

It’s also possible that attack campaigns against network-edge devices are becoming more visible to security teams because they are looking into what’s happening on these appliances more than they did in the past.

“Ten years ago, I was professionally doing exploit development for these types of routers,” Jacob Baines, CTO and head of research at vulnerability intelligence company VulnCheck, tells CSO. “I know there were many groups that were interested in it, but the security industry itself was more interested in desktop endpoints. And I think the industry has gotten better at protecting those types of endpoints. They’ve gotten better at protecting against phishing, so this is the next area that we’re trying to improve upon. So, there are a lot more eyes on it from the security field, but not necessarily attackers. I think they’ve always been there.”

2024 networking and security device zero-day flaws

Basic flaws persist in network device codebases

Harris of watchTowr doesn’t want to minimize the engineering effort it takes to build a secure system. But he feels many of the vulnerabilities discovered in the past two years should have been caught with automatic code analysis tools or code reviews, given how basic they have been.

Some VPN flaws were “trivial to the point of embarrassing for the vendor,” he says, while even the complex ones should have been caught by any organization seriously investing in product security.

Still, despite the basic nature of some of these vulnerabilities, most do not directly allow an attacker to execute arbitrary code or commands on the underlying OS with root privileges. Instead, attackers often must find and chain together vulnerabilities across multiple components, requiring them to understand how those components interact and identify a path to remote code execution.

“I wouldn’t necessarily call them complex exploit chains, but I think it’s a little unfair to call them simple as well,” VulnCheck’s Baines says. “Something like a Cisco ASA router or a PAN-OS system are very complicated systems. It takes a lot of knowledge of those systems to be able to write code in them and identify bugs.”

Caleb Gross, director of capability development at offensive security firm Bishop Fox, also notes the reverse-engineering skill required to find these bugs, as firmware images for these devices aren’t readily available, like open-source applications, and their file systems are often encrypted. Even after decryption, researchers or attackers must then learn how various components communicate.

“Identifying a command injection that is looking for a command string being passed to a system in some C or C++ code is not a terribly difficult thing to find,” Gross says. “But I think the trouble is understanding a really complicated appliance like these security network appliances. It’s not just like a single web application and that’s it.”

This can also make it difficult for product developers themselves to understand the risks of a feature they add on one component if they don’t have a full understanding of the entire product architecture. In large product organizations, it’s not unusual for different development teams to handle different codebases for different parts of one product’s system.

But Harris offers a counterargument: The product security team only has to recognize a code bug with potential security implications and fix it. They don’t have to develop a working exploit, like an attacker does.

“If you’re a product security team, your job is not really exploitation, like getting a shell,” he says. “Your aim is to work out how many of these vulnerabilities that you identify are exploitable. Can you remove the low-hanging fruit — the things that are trivial that someone is going to find — and then you can invest your efforts in finding more and more complex things.”

Harris adds: “In our opinion, again, looking at what we’ve seen the last 12 months, there’s no evidence that those efforts being made by those vendors are having an effect.”

2025 networking and security device zero-day flaws

Security debt and prioritization challenges

Another problem? These appliances have a lot of legacy code, some that is 10 years or older. Plus, products and code bases inherited through acquisitions often means the developers who originally wrote the code might be long gone. For example, Ivanti, one of the more frequently targeted vendors over the past two years, acquired Pulse Secure in 2020, and the Pulse Connect Secure SSL VPN has since become Ivanti Connect Secure.

According to Chris Wysopal, co-founder and chief security evangelist at application security testing company Veracode, tackling vulnerabilities in old code, known as security debt, is expensive and hard. And developers are more reluctant to fix certain issues, particularly those in C and C++ code, such as buffer and integer overflows, due to concern that they might break something they don’t fully understand how it works.

“If you have a modern process of application security testing and flaws are detected soon after code is written, the developer can go in and fix it,” Wysopal says. “But when you’re dealing with legacy code — we’ve actually seen some C++ applications where you have literally thousands of overflow issues and the original developers are long gone — it’s very difficult to get a new developer to look at it, and they don’t really want to touch the code. They get to a point where it’s like: Well, prove to me it’s exploitable, because this is a critical old piece of code that no one understands and it’s dangerous to touch it.”

As a result, some flaws require more proof of impact than others, and proving that a buffer overflow can result in arbitrary code execution is not straightforward; it requires also bypassing exploit mitigations on the OS, such as ASLR, which randomizes memory addresses. Command injection issues, on the other hand, are much easier to fix, according to Wysopal, even in old code bases. Then authorization bypasses usually require manual penetration testing to find.

“Each one of these flaw categories is a little different and this is why application security is hard,” he says. “But these are all top 10 issues. Things that these organizations should have a plan to say, ‘We’re going to eliminate the top 10 classes of vulnerabilities in our product.’ And it’s frankly just expensive and hard to do when you have big legacy code bases.”

Vendors need to set a higher standard for themselves

All researchers interviewed for this story agree that manufacturers of security appliances need to do a better job when it comes to their secure development lifecycle programs, internal application security testing, code reviews, and legacy code rewrites. Some, however, don’t have much hope for things to change because financial incentives to do so are missing.

Rewriting old code to be secure by design requires a lot of development time. Even fixing all the bugs that static and dynamic scanners find can incur budgetary challenges, resulting in the need to prioritize some over others.

But security vendors need to be held to a higher standard because they sell products marketed to protect banks, government agencies, and critical infrastructure. They shouldn’t become a liability for customers, or in Harris’ words: “Are we expecting APT [Advanced Persistent Threat] groups to be our internal QA teams?”

Wysopal pointed to the Secure Software Development Attestation Form that the US Cybersecurity and Infrastructure Security Agency (CISA) launched last year and its Secure by Design principles as a step in the right direction. The CISA program has seen some setbacks with two of the program’s architects and leaders, Lauren Zabierek and Bob Lord, leaving CISA in April amid staff and budget cuts. But it wouldn’t be surprising if other governments enacted legislation in the future to force the market’s hand. “I would be shocked if there’s not a conversation about regulation ongoing after the number of breaches we’ve now seen across fairly critical industries due to vulnerabilities in appliances that are mission-critical repeatedly, and then the root cause being questionable,” watchTowr’s Harris says. “It’s really now a race to see: Will enterprises vote with their wallets and their budgets, or will regulation come in first to help us begin to deal with this? But either way, something must change.”

For more insights into this topic watch our conversation on the Global Tech Tales podcast with Daniel dos Santos, the head of research at cyber risk management firm Forescout Technologies.