{"id":14984,"date":"2025-10-20T07:06:17","date_gmt":"2025-10-20T07:06:17","guid":{"rendered":"https:\/\/newestek.com\/?p=14984"},"modified":"2025-10-20T07:06:17","modified_gmt":"2025-10-20T07:06:17","slug":"network-security-devices-endanger-orgs-with-90s-era-flaws","status":"publish","type":"post","link":"https:\/\/newestek.com\/?p=14984","title":{"rendered":"Network security devices endanger orgs with \u201990s era flaws"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
<\/div>\n<\/section>\n

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.<\/p>\n

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 \u2014 buffer overflows, command injections, SQL injections \u2014 remain prevalent in mission-critical codebases maintained by companies whose core business is cybersecurity.<\/p>\n

Attackers constantly evolve their techniques. Security engineering, inherently challenging, can\u2019t 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<\/a>, CEO of cybersecurity and penetration testing firm watchTowr. \u201cBut 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.\u201d<\/p>\n

Network edge devices: The new battleground<\/h2>\n

Google\u2019s Threat Intelligence Group tracked 75 exploited zero-day vulnerabilities in 2024<\/a>. 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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<\/a>, 16% from stolen or weak credentials, and only 14% from phishing.<\/p>\n

\u201cAttackers are not trying to do the newest and greatest thing every single day,\u201d watchTowr\u2019s Harris explains. \u201cThey will do what works at scale. And we\u2019ve 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\u2019t deployed, exploit that, and then pivot from there.\u201d<\/p>\n

It\u2019s also possible that attack campaigns against network-edge devices are becoming more visible to security teams because they are looking into what\u2019s happening on these appliances more than they did in the past.<\/p>\n

\u201cTen years ago, I was professionally doing exploit development for these types of routers,\u201d Jacob Baines<\/a>, CTO and head of research at vulnerability intelligence company VulnCheck, tells CSO. \u201cI 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\u2019ve gotten better at protecting against phishing, so this is the next area that we\u2019re trying to improve upon. So, there are a lot more eyes on it from the security field, but not necessarily attackers. I think they\u2019ve always been there.\u201d<\/p>\n

2024 networking and security device zero-day flaws<\/h3>\n
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Product<\/strong><\/td>\nCVE<\/strong><\/td>\nFlaw type<\/strong><\/td>\nCVSS<\/strong><\/td>\n<\/tr>\n
Check Point Quantum Security Gateways and CloudGuard Network Security<\/td>\nCVE-2024-24919<\/a><\/td>\nPath traversal leading to information disclosure<\/td>\n8.6 (High)<\/td>\n<\/tr>\n
Cisco Adaptive Security Appliance<\/td>\nCVE-2024-20359<\/a><\/td>\nArbitrary code execution<\/td>\n6.6 (Medium)<\/td>\n<\/tr>\n
Cisco Adaptive Security Appliance<\/td>\nCVE-2024-20353<\/a><\/td>\nDenial of service<\/td>\n8.6 (High)<\/td>\n<\/tr>\n
Cisco Adaptive Security Appliance \u00a0<\/td>\nCVE-2024-20481<\/a><\/td>\nRemote Access VPN denial of service<\/td>\n5.8 (Medium)<\/td>\n<\/tr>\n
Cisco NX-OS switches<\/a><\/td>\nCVE-2024-20399<\/a><\/td>\nCLI command injection<\/td>\n6.0 (Medium)<\/td>\n<\/tr>\n
Fortinet FortiManager<\/td>\nCVE-2024-47575<\/a><\/td>\nMissing authentication leading to full system compromise<\/td>\n9.8 (Critical)<\/td>\n<\/tr>\n
Fortinet FortiOS SSL VPN<\/a><\/td>\nCVE-2024-21762<\/a><\/td>\nArbitrary code execution<\/td>\n9.6 (Critical)<\/td>\n<\/tr>\n
Ivanti Cloud Services Appliance<\/td>\nCVE-2024-8963<\/a><\/td>\nPath traversal leading to remote code execution<\/td>\n9.4 (Critical)<\/td>\n<\/tr>\n
Ivanti Cloud Services Appliance<\/td>\nCVE-2024-9381<\/a><\/td>\nPath traversal chained with CVE-2024-8963<\/td>\n7.2 (High)<\/td>\n<\/tr>\n
Ivanti Cloud Services Appliance \u00a0<\/td>\nCVE-2024-9379<\/a><\/td>\nSQL injection leading to application takeover chained with CVE-2024-8963<\/td>\n6.5 (Medium)<\/td>\n<\/tr>\n
Ivanti Cloud Services Appliance \u00a0<\/td>\nCVE-2024-9380<\/a><\/td>\nOS command injection chained with CVE-2024-8963<\/td>\n7.2 (High)<\/td>\n<\/tr>\n
Ivanti Connect Secure<\/a> \u00a0<\/td>\nCVE-2024-21893<\/a><\/td>\nServer-side request forgery<\/td>\n8.2 (High)<\/td>\n<\/tr>\n
NetScaler ADC and NetScaler Gateway \u00a0<\/td>\nCVE-2023-6548<\/a><\/td>\nCode injection<\/td>\n5.5 (Medium)<\/td>\n<\/tr>\n
NetScaler ADC and NetScaler Gateway<\/td>\nCVE-2023-6549<\/a><\/td>\nBuffer overflow<\/td>\n8.2 (High)<\/td>\n<\/tr>\n
Palo Alto Networks PAN-OS<\/a><\/td>\nCVE-2024-3400<\/a><\/td>\nCommand injection<\/td>\n10.0 (Critical)<\/td>\n<\/tr>\n
Palo Alto Networks PAN-OS<\/a><\/td>\nCVE-2024-0012<\/a><\/td>\nImproper authentication chained with CVE-2024-9474, command injection<\/td>\n9.3 (Critical)<\/td>\n<\/tr>\n
Versa Networks Director<\/a> \u00a0<\/td>\nCVE-2024-39717<\/a><\/td>\nArbitrary file upload and execution<\/td>\n6.6 (Medium)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/figure>\n

Basic flaws persist in network device codebases<\/h2>\n

Harris of watchTowr doesn\u2019t 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.<\/p>\n

Some VPN flaws were \u201ctrivial to the point of embarrassing for the vendor,\u201d he says, while even the complex ones should have been caught by any organization seriously investing in product security.<\/p>\n

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.<\/p>\n

\u201cI wouldn\u2019t necessarily call them complex exploit chains, but I think it\u2019s a little unfair to call them simple as well,\u201d VulnCheck\u2019s Baines says. \u201cSomething 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.\u201d<\/p>\n

Caleb Gross<\/a>, 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\u2019t 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.<\/p>\n

\u201cIdentifying 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,\u201d Gross says. \u201cBut I think the trouble is understanding a really complicated appliance like these security network appliances. It\u2019s not just like a single web application and that\u2019s it.\u201d<\/p>\n

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\u2019t have a full understanding of the entire product architecture. In large product organizations, it\u2019s not unusual for different development teams to handle different codebases for different parts of one product\u2019s system.<\/p>\n

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\u2019t have to develop a working exploit, like an attacker does.<\/p>\n

\u201cIf you\u2019re a product security team, your job is not really exploitation, like getting a shell,\u201d he says. \u201cYour aim is to work out how many of these vulnerabilities that you identify are exploitable. Can you remove the low-hanging fruit \u2014 the things that are trivial that someone is going to find \u2014 and then you can invest your efforts in finding more and more complex things.\u201d<\/p>\n

Harris adds: \u201cIn our opinion, again, looking at what we\u2019ve seen the last 12 months, there\u2019s no evidence that those efforts being made by those vendors are having an effect.\u201d<\/p>\n

2025 networking and security device zero-day flaws<\/h2>\n
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Product<\/strong><\/td>\nCVE<\/strong><\/td>\nFlaw type<\/strong><\/td>\nCVSS<\/strong><\/td>\n<\/tr>\n
Cisco Adaptive Security Appliance<\/a><\/td>\nCVE-2025-20362<\/a><\/td>\nAccess restricted URL without authentication<\/td>\n6.5 (Medium)<\/td>\n<\/tr>\n
Cisco IOS XE<\/td>\nCVE-2025-20352<\/a><\/td>\nDenial of service<\/td>\n7.7 (High)<\/td>\n<\/tr>\n
Fortinet FortiOS and FortiProxy firewalls<\/a> and secure web gateways<\/td>\nCVE-2024-55591<\/a><\/td>\nAuthentication bypass<\/td>\n9.6 (Critical)<\/td>\n<\/tr>\n
Fortinet FortiSIEM<\/a><\/td>\nCVE-2025-25256<\/a><\/td>\nOS command injection<\/td>\n9.8 (Critical)<\/td>\n<\/tr>\n
Fortinet FortiVoice<\/td>\nCVE-2025-32756<\/a><\/td>\nStack-based buffer overflow<\/td>\n9.6 (Critical)<\/td>\n<\/tr>\n
Gladinet CentreStack<\/a><\/p>\n<\/td>\nCVE-2025-11371<\/a><\/td>\nLocal file inclusion flaw<\/td>\n\u00a0<\/td>\n<\/tr>\n
Ivanti Connect Secure SSL VPN appliances<\/a><\/p>\n<\/td>\nCVE-2025-22457<\/a><\/td>\nStack-based buffer overflow<\/td>\n9.0 (Critical)<\/td>\n<\/tr>\n
Ivanti Connect Secure SSL VPN appliances<\/a><\/td>\nCVE-2025-0282<\/a><\/td>\nStack-based buffer overflow<\/td>\n9.0 (Critical)<\/td>\n<\/tr>\n
Ivanti Connect Secure SSL VPN appliances<\/a><\/td>\nCVE-2025-0283<\/a><\/td>\nStack-based buffer overflow<\/td>\n7.0 (High)<\/td>\n<\/tr>\n
Ivanti Endpoint Manager Mobile<\/a> (formerly MobileIron Core)<\/td>\nCVE-2025-4427<\/a><\/td>\nAuthentication bypass<\/td>\n5.3 (Medium)<\/td>\n<\/tr>\n
Ivanti Endpoint Manager Mobile<\/a> (formerly MobileIron Core)<\/td>\nCVE-2025-4428<\/a><\/td>\nRemote code execution<\/td>\n7.2 (High)<\/td>\n<\/tr>\n
Juniper MX Series routers<\/a><\/td>\nCVE-2025-21590<\/a><\/td>\nArbitrary code execution<\/td>\n6.7 (Medium)<\/td>\n<\/tr>\n
Libraesva Email Security Gateway<\/p>\n<\/td>\nCVE-2025-59689<\/a><\/td>\nCommand injection<\/td>\n6.1 (Medium)<\/td>\n<\/tr>\n
NetScaler ADC<\/a><\/p>\n<\/td>\nCVE-2025-7775<\/a><\/td>\nMemory overflow leading to remote code execution or denial of service<\/td>\n9.2 (Critical)<\/td>\n<\/tr>\n
NetScaler Gateway<\/a><\/td>\nCVE-2025-6543<\/a><\/td>\nMemory overflow vulnerability leading to unintended control flow and denial of service<\/td>\n9.2 (Critical)<\/td>\n<\/tr>\n
Palo Alto Networks firewalls<\/p>\n<\/td>\nCVE-2025-0108<\/a><\/td>\nAuthentication bypass<\/td>\n8.8 (High)<\/td>\n<\/tr>\n
SonicWall Secure Mobile Access<\/a><\/td>\nCVE-2025-23006<\/a><\/td>\nPre-authentication deserialization of untrusted data<\/td>\n\u00a0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/figure>\n

Security debt and prioritization challenges<\/h2>\n

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<\/a> over the past two years, acquired Pulse Secure in 2020, and the Pulse Connect Secure SSL VPN has since become Ivanti Connect Secure<\/a>.<\/p>\n

According to Chris Wysopal<\/a>, 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\u2019t fully understand how it works.<\/p>\n

\u201cIf 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,\u201d Wysopal says. \u201cBut when you\u2019re dealing with legacy code \u2014 we\u2019ve actually seen some C++ applications where you have literally thousands of overflow issues and the original developers are long gone \u2014 it\u2019s very difficult to get a new developer to look at it, and they don\u2019t really want to touch the code. They get to a point where it\u2019s like: Well, prove to me it\u2019s exploitable, because this is a critical old piece of code that no one understands and it\u2019s dangerous to touch it.\u201d<\/p>\n

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.<\/p>\n

\u201cEach one of these flaw categories is a little different and this is why application security is hard,\u201d he says. \u201cBut these are all top 10 issues. Things that these organizations should have a plan to say, \u2018We\u2019re going to eliminate the top 10 classes of vulnerabilities in our product.\u2019 And it\u2019s frankly just expensive and hard to do when you have big legacy code bases.\u201d<\/p>\n

Vendors need to set a higher standard for themselves<\/h2>\n

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\u2019t have much hope for things to change because financial incentives to do so are missing.<\/p>\n

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.<\/p>\n

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\u2019t become a liability for customers, or in Harris\u2019 words: \u201cAre we expecting APT [Advanced Persistent Threat] groups to be our internal QA teams?\u201d<\/p>\n

Wysopal pointed to the Secure Software Development Attestation Form<\/a> that the US Cybersecurity and Infrastructure Security Agency (CISA) launched last year and its Secure by Design principles<\/a> as a step in the right direction. The CISA program has seen some setbacks<\/a> with two of the program\u2019s architects and leaders, Lauren Zabierek and Bob Lord, leaving CISA in April amid staff and budget cuts. But it wouldn\u2019t be surprising if other governments enacted legislation in the future to force the market\u2019s hand. \u201cI would be shocked if there\u2019s not a conversation about regulation ongoing after the number of breaches we\u2019ve now seen across fairly critical industries due to vulnerabilities in appliances that are mission-critical repeatedly, and then the root cause being questionable,\u201d watchTowr\u2019s Harris says. \u201cIt\u2019s 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.\u201d<\/p>\n