Fortinet disclosed in two advisories that multiple vulnerabilities have been identified in versions of FortiSandbox.

• CVE-2026-39808: An OS command injection vulnerability exists within an API endpoint due to the improper neutralization of special elements. A remote, unauthenticated attacker could exploit this vulnerability by sending specially crafted HTTP requests, potentially allowing for the execution of unauthorized code or commands. This vulnerability has been designated CVE-2026-39808 and has been rated critical with a CVSS score of 9.1.
• CVE-2026-39813: An API privilege escalation vulnerability exists due to a path traversal flaw. A remote, unauthenticated attacker could exploit this vulnerability by sending specially crafted HTTP requests to the JRPC API. Successful exploitation may allow an attacker to bypass authentication and escalate privileges on the system. This vulnerability has been designated CVE-2026-39813 and has been rated critical with a CVSS score of 9.1.

The following versions are affected:

• FortiSandbox 4.4: Versions 4.4.0 through 4.4.8 (affected by both CVEs)
• FortiSandbox 5.0: Versions 5.0.0 through 5.0.5 (affected by CVE-2026-39813 only)

What is Fortinet FortiSandbox?

Fortinet FortiSandbox is a security appliance that identifies unknown threats by executing suspicious files in isolated virtual environments to monitor their behavior and then automates a response by sharing that intelligence across the network to block the detected threat.

What is the impact?

Successful exploitation of these vulnerabilities would allow an attacker to gain unauthorized API access, enabling them to escalate privileges and execute code or commands on the vulnerable host.

Are updates or workarounds available?

Users are encouraged upgrade affected systems to the following versions:

• FortiSandbox 4.4: Upgrade to 4.4.9 or later
• FortiSandbox 5.0: Upgrade to 5.0.6 or later

How to find potentially vulnerable systems with runZero

From the Asset Inventory, use the following query to locate potentially impacted assets:

os:="Fortinet FortiSandbox%"

The remaining principles (numbers five through eight) in the guidance detail how OT system owners can set themselves up for success against adversaries, including recommendations for preventing breaches and detecting them if they occur. The final four principles are pivotal for system owners to get right.

Principle 5: Harden your OT boundary

Many OT systems are difficult to update or replace, increasing the prevalence of obsolete assets and weak security controls. Because of this inability to modernize, oftentimes the primary defense against external threats to OT systems is their network boundary. As such, organizations should invest in modern, modular, and easily replaceable boundary protections. Additionally, the guidance suggests a robust checklist of actions to help harden your OT boundary:

• Change default passwords

  • Default credentials provide an easy-to-fix and easy-to-exploit avenue for attackers to gain initial access.

• Enforce the principle of least privilege

  • Human-to-machine and machine-to-machine connectivity should follow the concept of least privilege, following joiners, movers, leavers (JML) processes to ensure proper access rights throughout user lifecycles.

• Restrict unused services and ports

  • Only required ports and protocols should be exposed on assets.

• Implement phishing-resistant multi-factor authentication (MFA) for external services

  • Phish-resistant MFA should be implemented where possible for human-to-machine connectivity.

• Use context-aware access

  • Where possible, controls should be enabled that enforce connectivity based on attributes of the connection, like device location, time of access, or OS version.

• Enforce security requirements on third parties

  • Controls should be applied to third-party connections into the OT environment. NCSC’s previous guidance provides more details about this in principle five.

• Enforce unidirectional traffic flows

• Where possible, organizations should use Cross Domain Solutions and Data Diodes to help facilitate secure data transfers between untrusted and trusted domains.

As the convergence between OT and IT progresses, implementing principle five is critical for OT system owners in order to define and harden the boundary between OT and IT in their environments.

Principle 6: Limit the impact of compromise

There is a saying that goes, “You should be prepared for WHEN you get breached, not IF.” Organizations should take steps to limit the impact of a breach before it happens. OT systems owners need to focus on two risks:

• Contamination

  • Contamination refers to malicious or insecure code that makes its way into a trusted environment, often through the abuse of weak configurations, bad implementation, or vulnerable products.

• Lateral movement

  • Lateral movement describes how attackers expand their reach to neighboring nodes after initial access. Lateral movement can involve scanning, compromising hosts with stolen credentials, escalating privileges to gain access to systems, and more. Lateral movement should be seen as a threat both from external attackers and from insider and third-party threats.

Strategies for OT (and all) system owners to protect their environments include:

• Segmentation

  • Organizations should segment their networks behind firewalls or network architecture, dividing the network into smaller, functionally isolated networks, to reduce risk.

  • Microsegmentation: Microsegmentation applies controls on a much more granular level, usually at the host level, to restrict services, protocols, or specific clients from communicating.

  • Separation of duties: Separation of duties ensures that no one person has the ‘keys to the kingdom’. If you divide the responsibilities of individuals or systems within the environment, it limits exposure in the event of a breach or an insider threat.

• The browse down principle

  • The browse down principle states that you should trust the device on which administrative work is done as much as, or more than, the system you are managing. In essence, you don't want to manage a trusted system with an untrusted device.

• Boundary controls
  • Principle five discusses ways for organizations to harden their boundary, and principle six provides additional recommendations:

    • Host-based Controls

    • Static network controls

    • Dynamic network controls

    • Threat detection and response.

The best time for OT system owners to plan for a breach was yesterday, and the second-best time is today. OT system owners need to take proper precautions now to ensure that when, not if, a breach occurs, they are ready.

Principle 7: Ensure all connectivity is logged and monitored

While it's important to take all possible steps to prevent a breach, the last line of defense organizations have is their alerting and logging implementation. The ideal implementation of a good collection and alerting system is to empower system owners to expediently detect, contain, or prevent a breach, rather than simply collect logs.

There are at least four considerations OT system owners should look to address when a log collection and analysis program is implemented:

• Unauthorized activity

  • Any change in an OT (or IT) environment should come through strict change management procedures. Having a strong change management program, along with the ability to monitor for and alert on unauthorized changes, should be a major consideration.

• Anomaly detection

  • There should be detection of traffic patterns that deviate from the norm, or baseline, of known-good network traffic. Anomaly-based detection should not replace actual controls designed to prevent undesired traffic.

• Break-glass

  • Break-glass or use only in case of emergency access should be used only in emergency situations. Any use thereof should trigger an alarm of the highest criticality to the Security Operations Center (SOC). Break-glass account abuse is often how bad actors try to gain access to an environment through legitimate means.

• Data flow monitoring

  • Continuously monitoring data both within and across network segments and the OT boundary enables early detection of compromise.

NCSC has extensive guidance on proper log implementation, but principle seven serves as a brief reminder that logging for the sake of logging is not enough. Logs should be actionable within an organization to detect a breach and, if possible, prevent it from spreading.

Principle 8: Establish an isolation plan

There may be times when it's necessary to isolate OT environments from external influences, for example, if there is a compromise in connected IT systems or an increased threat from adversaries. OT systems should be designed, where possible, to still provide critical functions while isolated. It's essential that an isolation plan is designed and tested to ensure that critical functions remain operational while preventing unforeseen or unintended consequences during isolation.

There are three primary isolation strategies that an organization could consider:

• Site isolation

  • Site isolation works well in flat networks or networks without sophisticated security measures. Site isolation primarily involves removing or terminating external connections, either physically (e.g., cable disconnect) or via software (e.g., firewall configuration)

• Application or service-specific isolation

  • If an organization has successfully implemented the secure connectivity controls outlined in the guidance, application isolation might be more effective than site isolation. Application isolation enables an organization to isolate affected services or assets using the controls outlined in the guidance, such as microsegmentation.

• Site isolation with hardware-enforced trusted communications

  • This isolation plan allows organizations that have used either data diodes, a CDS, or other hardware-based traffic enforcement to isolate their network while keeping the hardware enforced data flows open. This allows isolating the trusted network from the untrusted network while still enabling secure data transfer.

Isolation plans, just like breach contingency plans, should be built and tested before they are needed. Ideally, isolation plans will never be needed, but with the evolving threat landscape, organizations should take action now to be prepared in the event isolation is needed.

How runZero can help

In our previous blog on this guidance, we mentioned five ways we help organizations protect and secure their OT systems. Those features of runZero also apply to principles five through eight, but there are more ways that runZero can help secure OT environments:

1. Default password checks

   • runZero can run default password checks to discover assets and software that have not changed their default settings.

2. Discover gaps in coverage

   • runZero can surface hidden assets, assets missing security controls, and assets that are bridging networks they shouldn't.

3. Alerting on unauthorized changes

   • runZero provides a comprehensive asset inventory and can detect and alert when assets are added or removed from a network, or when asset changes occur.

4. Edge device detection

   • Many organizations think they know where their edge lies, but runZero can expose assets with network connections you didn’t know existed.

If you stuck with us through all three blog posts, thanks for being here! These weren’t short posts, but neither was the guidance. If you need help protecting your OT assets, runZero is here to help. Try us out for free, or get in touch with us today.

If you missed the livestream, here’s a quick look at the themes and sessions from the day hosted by runZero’s Tod Beardsley and Rob King.

The vulnerability crisis: Quality, prediction, and noise

Right now, the industry is overwhelmed by a flood of CVEs, and we’re pretty sure this is just the beginning of a pretty steep slope. With vulnerability disclosures at an all-time high, the debate over quality versus quantity is more important than ever. In the ‘CVE quagmire’ segment, Jerry Gamblin (RogoLabs) told Tod that we’re facing an average of more than 160 new CVEs per day. He highlighted that while we’re hearing a lot about the potential for an artificial intelligence (AI) tsunami of bugs, we still haven’t addressed people-generated bugs and the inconsistent metadata that have hindered security teams for decades. On a positive note, they discussed how projects like RogoLabs’ CVE.ICU is making the CVE program more transparent, and how the upcoming Schema 6.0 could also help by requiring better, machine-readable data for automated discovery and fixes.

Next, we had the perfect follow-up session, ‘Predicting exploitation’with Jay Jacobs (Empirical Security), exploring the practice of predicting vulnerability exploitation. Jacobs detailed the evolution of the Exploit Prediction Scoring System (EPSS) from a research initiative into a vital, daily-published API that provides probability scores and percentile rankings for hundreds of thousands of CVEs.

They discussed how EPSS differs from other scoring systems and frameworks, specifically explaining the relationship between a probability score and the percentile rank. Jacobs also addressed common misconceptions about low-probability scores, noting that even a small percentage can be highly significant when measured across a massive population of vulnerabilities.

Rounding out our discussions on CVEs was the 'Mute the sirens' session with Mark Lambert (ArmorCode). Given the increasing volume and velocity of vulnerabilities, Lambert explains how an important step in reducing the noise includes determining what actually needs to be fixed, and it’s not just about picking the critical ones. He noted that they leverage threat intelligence from CISA’s KEV and EPSS to determine what’s being actively exploited, which is particularly important given that nearly all CVEs are never actually exploited in the real world.

Then, they further analyze this vulnerability intelligence by using integrations with other solutions to get an inventory of assets, determine what’s externally facing, and understand if a fix is urgently needed from a business-priority perspective. Using this unified exposure management approach goes beyond focusing only on traditional CVEs to include issues found through penetration testing and static analysis, providing a comprehensive picture of an organization’s security posture.

Research-driven reporting in cybersecurity journalism

With more AI-generated content and smaller newsrooms, cybersecurity journalism faces new challenges. In the 'Signal vs. slop' session, current and former reporters discussed how research-driven reporting is changing. Our panel of experts included Bill Brenner (CYBR.SEC.Media), Dennis Fisher (Decipher), and Steve Ragan (1Password).

The group discussed how reduced funding for traditional media has pushed many journalists to work for and with vendors directly, where brand journalism now fills the gap left by shrinking newsrooms, creating challenges for editorial independence amid the pressures of advertising and sponsored content. They also reflected on how large language models (LLMs) are affecting the quality of security reporting and how the rise of automated content lacks the human insight needed for good communication.

Expanding on the cybersecurity journalist’s perspective, the 'On the frontlines of investigative journalism' session with investigative journalist and author Joseph Menn examined the intersection of technology, crime, geopolitics, and hacktivism.

Menn shared with Tod that today’s most interesting stories aren’t just about business deals or stock prices; they focus on the complex areas where organized crime groups and state-sponsored intelligence operations overlap, especially in places like Russia and China.

They also discussed Menn’s book, Cult of the Dead Cow. They talked about the group's role in pressuring tech giants like Microsoft to take security seriously, effectively shifting the industry from a culture of hobbyist tinkering to one of professionalized defense and public policy influence.

Bridging the physical and digital divide

In the 'From risk to resilience' session, Mary Gannon (GuidePoint Security) and Patrick Gillespie (GuidePoint Security) talked with Rob about how IT and Operational Technology (OT) are converging. They discussed the unique challenges of securing industrial systems in sectors such as manufacturing and mining, where older software like Windows 98 and even Windows 3.1 is still in use. They pointed out that while bringing IT and OT together offers benefits such as real-time data and remote work, it also poses serious safety risks.

One key takeaway is the importance of knowing what assets are on your network. Many OT organizations don’t have a clear picture of what’s connected, often because the security teams don’t actually own the physical equipment. They explained that in OT, the priorities are different: IT cares most about keeping data private, while OT focuses on safety and keeping systems running. That’s why things like immediate patching aren’t always possible — shutting down a system could put people’s lives at risk.

This shift from physical assets to decentralized systems is also redefining the very concept of a network perimeter. In the ‘Perimeters and pathways’ session with Jared Atkinson (SpecterOps), Zakir Durumeric (Censys), and HD Moore (runZero), our experts stressed that the idea of a single, clear network perimeter is outdated, replaced by a satellite model of thousands of cloud accounts, remote control systems, and data-sovereignty-compliant providers. They also pointed out that network infrastructure, like firewalls, VPNs, and LTE modems, is now a top target for initial access, blurring the line between internal and external assets.

They discussed the pathways attackers take once they gain initial access, and how defenders can use solutions to map identity-based attack paths through systems. The conversation also noted that fingerprinting internal TLS services and searching for matching hashes on the public internet reveals hidden connections and misconfigurations, such as management ports exposed to guest wireless networks that completely bypass intended segmentation.

And this is especially risky at ‘The network edge,’ where old hardware like routers that no longer get updates are easy targets for attackers. During this session, Kimber Duke (VulnCheck) and Patrick Garrity (VulnCheck) discussed the critical intersection of end-of-life (EOL) hardware and this notion of a porous network edge with Tod.

Our experts revealed that edge devices, such as consumer routers and firewalls, are some of the most targeted assets for exploitation. They also talked about the zombie cycle of the internet, where unpatched, unsupported devices remain online indefinitely, creating a massive, static attack surface. Unfortunately, this problem is exacerbated by Internet Service Providers (ISPs) that continue to issue EOL hardware to new customers as well as the lack of consumer awareness regarding router updates.

As the conversation shifted to AI, our experts noted that they’re seeing a mix of valid bugs and ‘AI slop,’ and they anticipate the volume of valid vulnerabilities to increase geometrically over time.

The AI frontier: Bounties and asymmetric defense

And speaking of AI (which is nearly impossible to avoid in San Francisco, it turns out), it was also a focus in several sessions, including the discussion Tod had with Casey Ellis (Bugcrowd) about ‘Bug bounties in the age of AI.’ They talked about how AI is making it easier for both attackers and defenders, but that the primary drivers of security research still depend on human intent and quick decision-making. They also discussed the challenge of the 'defender's dilemma,' where attackers can try new things quickly and with little risk, while defenders must secure entire environments and face severe operational consequences if their automated 'agents' cause a production outage.

As the session continued, Ellis stressed the importance of vulnerability research and the need to standardize disclosure practices, which is why he’s focusing on disclose.io to make vulnerability disclosure and vulnerability report acceptance easier through standardized legal templates and a vendor-neutral database of disclosure policies.

As noted earlier, we weren’t done with AI yet. 'The infinite eye' segment with Jonathan Cran (Mallory) and HD Moore (runZero) talked with Tod about how AI-powered threat intelligence is giving defenders a real edge in a noisy security landscape. The conversation highlights a major shift in vulnerability management; defenders are transitioning away from waiting for official CVE numbers to tracking emerging threats through GitHub issues, mailing lists, and security advisories. By being more intentional about embracing the strengths of LLMs to filter out slop and fake exploits, defenders can answer critical questions much faster about their exposure in minutes, often beating CVE assignment and official vulnerability databases to the punch.

Strengthening the shield: Community and visibility

In the 'Force multiplied' session, Rishiraj Sharma (ProjectDiscovery) and Tod discussed how the open-source framework Nuclei has revolutionized how security teams validate vulnerabilities. Sharma explained that Nuclei was created to cut through the noise from traditional scanners, which often flag thousands of potentially vulnerable instances based solely on version detection. Instead, Nuclei lets security pros outline the exact steps a person would take to verify an exploit, making it clear which assets are really at risk and need immediate attention.

Thanks to input from pentesters, bug bounty hunters, and researchers worldwide, Nuclei can now create verified exploit templates in just hours instead of days. Sharma also noted that ProjectDiscovery’s bug bounty program incentivizes researchers to write new templates and validate existing ones to ensure high quality and reduce false positives.

A new kind of RSAC experience

At the end of the day, the best part of runZero Day wasn’t just one session — it was the insights shared and the format. By moving the conversation beyond the Moscone Center, we were able to broaden the audience for the major themes of the cybersecurity industry and RSAC to the world beyond Silicon Valley.

In the end, we hope you dip into the recorded stream, and if you just can’t get enough, you should definitely join the next runZero Hour, where Tod and Rob will chat it up with Caroline Wong, author of The AI Cybersecurity Handbook. They’ll talk more about the ups and downs of our machine-brained tooling in our day-to-day practice of cybersecurity.

First off, I’m glad to get these CVE out the door, which may sound a little strange. After all, nobody’s happy when their product ships with vulnerabilities. But, this does give me, incorrigible vulnerability-gazer todb, a reason to tout runZero’s overarching commitment to transparently communicate with our customers, users, and fans about the occasional bug that we happen to write, then find, and then fix. Best of all, there’s no reason to believe any of these were exploited in the wild (and we did check; if we ever find indicators of compromise, the affected customers would be the first to know).

In our role as a designated CVE Numbering Authority (or CNA), we are now expected to voluntarily (and, dare I say, enthusiastically), publish CVE records noting vulnerabilities that affect our own software. This first batch covers several months of bug-writing, concluding with CVE identifiers for an even dozen vulnerabilities. While most of them are pretty boring (everything in the set requires you to already be at least an authorized runZero user, and most are in the CVSS 5.8 Medium range) we’re committed to showing some uncomfortable proof that we actually do practice what we preach when it comes to security audits. We take our compliance requirements quite seriously, and we are going beyond an auditor’s checkbox when it comes to rolling out fixes before anything actually bad happens.

Going forward, we’re targeting the first Tuesday of every month for these CVE rollups, in order to give our customers and users a chance to apply fixes as we release them. To be clear, I expect there will be first-Tuesdays that go by with nary a bug to document. You'll notice that our most recent security issue was back in February, and I'm writing this in April, so you can expect to see a monthly report when there's something to share.

I’d also like to note that runZero has spent its entire corporate life offering security fixes as regular point releases, and we don’t expect to change that cadence now we’re a CNA. Instead, we’re offering our customers the best of both worlds: rapid fixes for security issues (no matter how minor they seem), and follow up documentation for the folks who continue to rely on the CVE ecosystem for alerting. This works for us because the runZero Platform is, at heart, a SaaS offering, which means that most of our users get these fixes without any heavy lifting or other action on their part. However, we’re also used in high security environments that require an on-prem, air-gapped installation. Ironically, this means that those high-security customers may miss out on security fixes for a while, so we’re hopeful that publishing these CVEs might nudge them along to getting not just security fixes, but all of our sweet new features and refinements that they miss out on with a slower-than-instant update cycle.

Of course, in the unlikely event that things go really off the rails and someone else discovers and publishes a vulnerability of ours before we do ourselves, we’ll be first on the scene with a fix and a CVE in hand.

So, nobody likes shipping vulns, but the least we can do is be clear about our vulnerabilities when we find and fix them, both practically in release notes, and logistically for the global CVE community. Everybody writes bugs, but not everyone is on board with owning them, and that’s why I’m (weirdly) pleased to announce our twelve newly minted CVEs. For more details, swing by runZero’s Security Advisories page, or just look these up directly with your favorite CVE client.

CVEs for April, 2026

The below are ordered by CVSS general ratings (High to Low, there were no Criticals). All runZero Platform hosted customers have already been fixed, while on-prem customers will need to update to the latest version.

High

• CVE-2026-5373: runZero Platform superuser privilege escalation, CVSS 8.1 (High)

Medium

• CVE-2026-5372: runZero Platform SQL injection in saved queries, CVSS 6.4 (Medium)
• CVE-2026-5376: runZero Platform session timeout failure, CVSS 5.9 (Medium)
• CVE-2026-5374: runZero Platform MCP information leak, CVSS 5.8 (Medium)
• CVE-2026-5378: runZero Platform user creation leak, CVSS 5.8 (Medium)
• CVE-2026-5384: runZero Platform incorrect credential scope, CVSS 5.8 (Medium)
• CVE-2026-5380: runZero Platform clear-text secret exposure, CVSS 5.3 (Medium)
• CVE-2026-5383: runZero Explorer missing authorization check (CVSS 4.4 (Medium)

Low

• CVE-2026-5379: runZero Platform MCP certification information leak, CVSS 3.0 (Low)
• CVE-2026-5382: runZero Platform MCP endpoint information leak, CVSS 3.0 (Low)
• CVE-2026-5375: runZero Platform API credential information leak, CVSS 2.7 (Low)
• CVE-2026-5381: runZero Platform task information leak, CVSS 2.2 (Low)

Fortinet disclosed certain versions of the FortiClient Endpoint Management Server (EMS) are susceptible to an API authentication and authorization bypass vulnerability caused by improper access control. A remote, unauthenticated attacker could exploit this flaw by sending specially crafted requests to the server. A successful exploit may allow the attacker to execute unauthorized code or commands. This vulnerability has been designated CVE-2026-35616 and has been rated critical with a CVSS score of 9.1.

Both Fortinet and CISA have now confirmed that this vulnerability is being actively exploited in the wild.

The following versions are affected:

• FortiClientEMS 7.4: Versions 7.4.5 through 7.4.6

What is Fortinet FortiClient Endpoint Management Server?

Fortinet FortiClient Endpoint Management Server (EMS) is a centralized application used to deploy, configure, and monitor security settings on devices running the FortiClient agent.

What is the impact?

Successful exploitation of these vulnerabilities would allow an adversary to execute unauthorized code or commands on the vulnerable host.

Are updates or workarounds available?

Users are encouraged upgrade affected systems to the following versions or apply the relevant hotfixes immediately:

• FortiClientEMS 7.4: Upgrade to 7.4.7 or later.
• FortiClientEMS 7.4.5: Apply hotfix 7.4.5.2111.
• FortiClientEMS 7.4.6: Apply hotfix 7.4.6.2170.

How to find potentially vulnerable systems with runZero

From the Service inventory, use the following query to locate potentially impacted assets:

_asset.protocol:http AND protocol:http AND favicon.ico.image.mmh3:=-800551065

Cisco disclosed in two advisories that multiple vulnerabilities have been identified in versions of their Smart Software Manager On-Prem (SSM On-Prem).

• CVE-2026-20160: A vulnerability that could allow a remote, unauthenticated attacker to execute arbitrary commands on the underlying operating system of an affected host. This issue stems from the unintentional exposure of an internal service. An attacker could exploit this by sending a crafted request to the exposed service's API. A successful exploit could grant the attacker root level privileges on the underlying operating system. This vulnerability has been designated CVE-2026-20160 and has been rated critical with a CVSS score of 9.8.
• CVE-2026-20151: A vulnerability in the web interface that could allow a remote, low-privileged attacker (System User role) to elevate their privileges. This flaw exists due to the improper transmission of sensitive user information. An attacker could exploit this by sending a crafted message to the host and retrieving session credentials from subsequent status messages. This would allow an attacker to elevate their role from System User to administrative. Note: This vulnerability only exposes information regarding users currently logged into the web interface; SSH sessions are not affected. This vulnerability has been designated CVE-2026-20151 and has been rated high with a CVSS score of 7.3.

The following versions are affected by one or both vulnerabilities:

• CVE-2026-20151: Cisco SSM On-Prem versions 9-202510 and earlier.
• CVE-2026-20160: Cisco SSM On-Prem versions 9-202502 through 9-202510.

What is Cisco Smart Software Manager On-Prem?

Cisco Smart Software Manager On-Prem is a local virtual appliance that enables organizations to manage and track Cisco software licenses within a private network, eliminating the need to connect individual devices directly to Cisco's cloud-based licensing portal.

What is the impact?

Successful exploitation of these vulnerabilities would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• Cisco SSM On-Prem: Upgrade to 9-202601 or later.

How to find potentially vulnerable systems with runZero

From the Service inventory, use the following query to locate potentially impacted assets:

_asset.protocol:http AND protocol:http AND html.title:="On-Prem License Workspace"

Our presence had front-row feels with back-row vibes — spanning demos, meetings, social events, and our first-ever day-long livestream — all focused on building community, learning from industry experts, and pushing the boundaries to ensure defenders win by default.

BSidesSF: The deep cuts

Our week began at BSidesSF, the ultimate opening act of deep dive tech talks and backstage conversations with the expert practitioners who drive innovation and aren’t afraid to get their hands on a keyboard. We love to get social, so it’s only appropriate that we were the daytime social sponsor posted up between the bar and the outdoor lounge. We loved reconnecting with old friends and making lots of new ones.

We also have to give a special shoutout to the entire BSidesSF crew for the warm welcome they gave Zeti the Yeti. Our beloved 6.5’ furry mascot was presented with his own special BSides badge, which literally brought a tear or two to our eyes. We are thankful that the BSides community gets us! (And we had a lot of fun going all in with the musical theme, including cipher puzzles that matched up our favorite Broadway shows with cybersecurity trivia.)

After our crew packed up our BSidesSF booth, we headed off to the iconic Tongacon, which made a victorious return to the Tonga Room this year, complete with indoor rain and plenty of tiki drinks. We were proud to sponsor this year, and we enjoyed catching up with longtime friends and forging new connections before shifting our focus to the hustle and bustle of RSAC.

RSAC: Headliners and headlines

On Monday, the marquee acts took to the stage to deliver industry news, influential conversations, and thought leadership!

We started our RSA tour with two speaking sessions, media interviews, and social gatherings.

First, our CEO, HD Moore, examined how AI is changing vulnerability discovery and how to prepare for it. Followed by our VP of Security Research, Tod Beardsley, who explored the CVE program, its fragility, and its possible future.

Then, we focused on our community-centered gigs.

We hosted incredible book signings with two influential voices in our industry, Caroline Wong and Joseph Menn. Caroline Wong drew a packed room as we celebrated her new book, The AI Cybersecurity Handbook. We had a fascinating discussion about how AI is transforming cybersecurity, and everyone wanted a signed copy. Next, Joseph Menn, investigative journalist and author of Cult of the Dead Cow, captivated the audience by sharing his journey as a journalist and the inspiration behind his latest book. Attendees were thrilled to get their hands on a personalized, signed copy.

And the hits kept rolling, with pop-up moments throughout the conference featuring the runZero team (and Zeti the Yeti sightings powered by iconic SF pedicabs!).

But we didn’t just rock in person!

Livestream: Our debut tracks

It was a lights, sound, magic moment for the runZero team as we launched the inaugural runZero Day, a live-streamed event held alongside RSAC, bringing insights to everyone who wanted to experience the magic of the week virtually.

On March 25, we broadcast live for almost six amazing hours! runZero Day brought together more than a dozen unique voices to explore the issues shaping cybersecurity today and what’s coming next. We were beyond honored to host an incredible lineup of industry trailblazers, innovators, founders, journalists, and subject matter experts.

The program covered a wide range of topics, including:

• The evolving role of the CVE program in modern defense

• The realities of reporting on cybersecurity in a high-pressure, high-stakes environment

• Challenges in securing OT, applications, and increasingly complex attack surfaces

• Perspectives from startup founders working to rethink the future of security

• Impacts of AI on our rapidly morphing industry

Merging technical perspectives with industry insights, our big, crazy, audacious goal was to make RSAC-related content accessible to a global audience, giving more people the opportunity to interact, learn, and contribute regardless of their location — no badge required!

Liner notes

It was music to our ears when BSidesSF and RSAC 2026 once again proved that the most valuable part of the week isn’t just what you learn or what happens on stage — it’s who you meet (or reconnect with) and how you apply the knowledge you gained moving forward.

Join the fan club

If you missed us in San Francisco, there are still plenty of ways to connect with the runZero band and learn how we provide unrivaled exposure detection and insights across your entire internal and external attack surface:

• Try the Platform: Interested in seeing runZero in action? You can explore the platform for free for 21 days, and following your trial, you can transition to our free Community Edition (for environments with fewer than 100 assets).

• Learn More: Explore our Platform features and Resources for more information about runZero.

Cisco disclosed in two advisories that multiple vulnerabilities have been identified in versions of their Integrated Management Controller (IMC).

• CVE-2026-20093: A vulnerability in the password change functionality could allow a remote, unauthenticated attacker to bypass authentication. Due to incorrect handling of password requests, an attacker could send a crafted HTTP request to alter any user's password, including an Admin account, to gain full system access. This vulnerability has been designated CVE-2026-20093 and has been rated critical with a CVSS score of 9.8.
• CVE-2026-20094: A vulnerability in the web-based management interface could allow a remote, low-privileged (read-only) attacker to perform command injection. By sending crafted commands to the interface, an attacker could exploit improper input validation to execute arbitrary commands as the root user. This vulnerability has been designated CVE-2026-20094 and has been rated high with a CVSS score of 8.8.
• CVE-2026-20095 and CVE-2026-20096: Two vulnerabilities in the web-based management interface could allow a remote, high-privileged (admin-level) attacker to perform command injection. Due to improper input validation, an attacker could execute arbitrary commands on the underlying operating system as the root user. The vulnerabilities designated CVE-2026-20095 and CVE-2026-20096 have been rated medium with a CVSS score of 6.5.
• CVE-2026-20097: A vulnerability in the web-based management interface could allow a remote, high-privileged (admin-level) attacker to execute arbitrary code. By sending crafted HTTP requests to an affected device, an attacker could exploit improper input validation to execute arbitrary code on the underlying operating system as the root user. This vulnerability has been designated CVE-2026-20097 and has been rated medium with a CVSS score of 6.5.

The following Cisco products are affected if they are running a vulnerable release of Cisco IMC, regardless of device configuration:

5000 Series Enterprise Network Compute Systems (ENCS):
(Affected by CVE-2026-20093, CVE-2026-20095, and CVE-2026-20096)

• Cisco NFV Infrastructure Software (NFVIS) versions 4.15 and earlier

Catalyst 8300 Series Edge uCPE:
(Affected by CVE-2026-20093, CVE-2026-20094, CVE-2026-20095, and CVE-2026-20096)

• Cisco NFVIS versions 4.16 and earlier
• Cisco NFVIS version 4.18

UCS C-Series M5 & M6 Rack Servers (Standalone Mode):
(Affected by all CVEs: CVE-2026-20093, CVE-2026-20094, CVE-2026-20095, CVE-2026-20096, and CVE-2026-20097)

• Cisco IMC versions 4.2 and earlier
• Cisco IMC version 4.3
• Cisco IMC version 6.0 (M6 only)

UCS E-Series M3 & M6:
(Affected by CVE-2026-20093, CVE-2026-20094 (M6 only), CVE-2026-20095, and CVE-2026-20096)

• Cisco IMC versions 3.2 and earlier (M3)
• Cisco IMC versions 4.15 and earlier (M6)

UCS S-Series Storage Servers (Standalone Mode):
(Affected by CVE-2026-20094, CVE-2026-20095, and CVE-2026-20096)

• Cisco IMC versions 4.2 and earlier
• Cisco IMC version 4.3

Cisco Appliances:
The following appliances are affected if the Cisco IMC user interface (UI) is exposed, as these platforms are built upon preconfigured versions of the UCS C-Series Servers listed above:

• Application Policy Infrastructure Controller (APIC) Servers
• Business Edition 6000 and 7000 Appliances
• Catalyst Center Appliances, formerly DNA Center
• Cisco Telemetry Broker Appliances
• Cloud Services Platform (CSP) 5000 Series
• Common Services Platform Collector (CSPC) Appliances
• Connected Mobile Experiences (CMX) Appliances
• Connected Safety and Security UCS Platform Series Servers
• Cyber Vision Center Appliances
• Expressway Series Appliances
• HyperFlex Edge Nodes
• HyperFlex Nodes in HyperFlex Datacenter without Fabric Interconnect (DC-No-FI) deployment mode
• IEC6400 Edge Compute Appliances
• IOS XRv 9000 Appliances
• Meeting Server 1000 Appliances
• Nexus Dashboard Appliances
• Prime Infrastructure Appliances
• Prime Network Registrar Jumpstart Appliances
• Secure Endpoint Private Cloud Appliances
• Secure Firewall Management Center Appliances
• Secure Malware Analytics Appliances
• Secure Network Analytics Appliances
• Secure Network Server Appliances
• Secure Workload Servers

What is Cisco Integrated Management Controller?

The Cisco Integrated Management Controller is a dedicated baseboard management controller that provides out-of-band hardware configuration, monitoring, and remote control for Cisco UCS C-Series and S-Series servers via a web interface, CLI, or API, independent of the host operating system.

What is the impact?

Successful exploitation of these vulnerabilities would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

5000 Series ENCS:

• Cisco NFVIS versions 4.15 and earlier: Upgrade to 4.15.5 or later.

Catalyst 8300 Series Edge uCPE:

• Cisco NFVIS versions 4.16 and earlier: Migrate to a fixed release.
• Cisco NFVIS version 4.18: Upgrade to 4.18.3 (Apr 2026) or later.

UCS C-Series M5 Rack Server:

• Cisco IMC versions 4.2 and earlier: Migrate to a fixed release.
• Cisco IMC version 4.3: Upgrade to 4.3(2.260007) or later.

UCS C-Series M6 Rack Server:

• Cisco IMC versions 4.2 and earlier: Migrate to a fixed release.
• Cisco IMC version 4.3: Upgrade to 4.3(6.260017) or later.
• Cisco IMC version 6.0: Upgrade to 6.0(2.260044) or later.

UCS E-Series M3:

• Cisco IMC versions 3.2 and earlier: Upgrade to 3.2.17 or later.

UCS E-Series M6:

• Cisco IMC versions 4.15 and earlier: Upgrade to 4.15.3 or later.

UCS S-Series Storage Server:

• Cisco IMC versions 4.2 and earlier: Migrate to a fixed release.
• Cisco IMC version 4.3: Upgrade to 4.3(6.260017) or later.

Notes:

• NFVIS Platforms: Upgrading Cisco IMC on 5000 Series ENCS and Catalyst 8300 Series Edge uCPE requires an upgrade of the Cisco Enterprise NFVIS. The IMC is updated automatically during the firmware auto-upgrade process.
• Cisco Appliances: Administrators can typically perform a direct upgrade of the Cisco IMC using the Cisco Host Upgrade Utility (HUU). For specific exceptions, please refer to the detailed instructions in the official Cisco Security Advisory.

How to find potentially vulnerable systems with runZero

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:=Cisco AND product:="Integrated Management Controller"

Progress Software disclosed two vulnerabilities in 5.x versions of customer-managed ShareFile Storage Zones Controller (SZC).

• CVE-2026-2699: Allows a remote, unauthenticated adversary to access restricted configuration pages. This could lead to unauthorized system configuration changes and potential Remote Code Execution (RCE) resulting from an Execution After Redirect (EAR) vulnerability. This vulnerability has been designated CVE-2026-2699 and has been rated critical with a CVSS score of 9.8.
• CVE-2026-2701: Allows a remote, high-privileged user to upload a malicious file to the server and execute it to achieve RCE. This vulnerability has been designated CVE-2026-2701 and has been rated critical with a CVSS score of 9.1.

The following versions are affected:

• ShareFile Storage Zones Controller 5.x versions prior to 5.12.4

What is Progress ShareFile Storage Zones Controller?

Progress ShareFile Storage Zones Controller is a software application that enables organizations to store their ShareFile data on-premises or in a private cloud infrastructure, rather than using the default ShareFile cloud storage.

What is the impact?

Successful exploitation of these vulnerabilities would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• ShareFile Storage Zones Controller 5.x: Upgrade to version 5.12.4 or later.
• Alternative: Users on version 5.x may also upgrade to any v6 version, as all v6 versions are unaffected by these
  vulnerabilities.

How to find potentially vulnerable systems with runZero

From the Software Inventory, use the following query to locate potentially impacted assets:

(vendor:="Progress Software" OR vendor:=Citrix OR vendor:=ShareFile) AND
  (product:="ShareFile Storage Zones Controller" OR product:="ShareFile StorageZones Controller")

We are continuing our blog series on this guidance by taking a closer look at the first four principles that lay the foundation for a robust OT security posture and how runZero can help empower OT network defenders.

Let’s dive in.

Principle 1: Balance the risks and opportunities

At the heart of the first principle is the idea that connectivity decisions should be risk‑informed and auditable. Before adding or modifying any connection into or out of an OT system, organizations must create and document business use cases for all permitted connectivity within OT systems. These must clearly document why the connection is needed, the benefits it provides, and what risk it introduces. Specifically, when documenting the justification and use case of connections, organizations should consider, at a minimum, the following:

• Why the connection is required and what operational function it enables

• What benefits are expected, like improved monitoring or predictive maintenance

• What risks are acceptable based on organisational threat context

• Potential impacts if the connection is misused or compromised

• How new dependencies might affect isolation or resilience

• Who is accountable at a senior level for the decision

This principle also deliberately highlights two major considerations for organizations to weigh that greatly increase risk when expanding OT connectivity: obsolete products (both software and hardware) and operational risks that ensure the safety, reliability, and availability of OT systems.

Organizations need to understand, evaluate, and address the risks associated with obsolete products. These risks may include the lack of security updates and the loss of institutional knowledge to help support older systems.

To reduce operational risk, organizations also need to consider loss of connectivity, single points of failure, and manual fallback capabilities.

This principle ensures OT system owners and operators carefully consider and document the impacts, effects, and ramifications of increasing the connectivity of their OT systems, especially when they are using old or obsolete products that could compromise the integrity of the OT system.

Principle 2: Limit the exposure of your connectivity

Exposure refers to how accessible OT systems are to both internal networks and external systems. The more reachable an OT asset is, the broader the potential attack surface becomes. To protect against exploitation, organizations should adopt an exposure management approach to their environment. It’s important to note that exposure management is not the same as vulnerability management and should not be treated as such.

An exposure management approach considers factors such as internet, adjacent, or internal network accessibility, End of Life (EOL) devices, obsolete protocol usage, administrative service or interface accessibility, and the many non-CVE risks that often lead to exploitation.

The guidance provides suggestions for limiting the exposure of OT systems, including:

• Reduce time of exposure

  • When possible, utilize just-in-time (JIT) access to reduce the time window for attacks to occur.

• Remove inbound port exposure

  • Only brokered connections through a secure gateway should be allowed. All other connections should initiate outbound from the OT system.

• Manage obsolescence risks

  • When obsolete OT devices cannot be upgraded, system owners should implement network segmentation, boundary controls, access restrictions, and device monitoring and logging.

• Manage unique connectivity risks

  • Even if encrypted, wireless communications like WiFI or radio are not bound by the physical perimeter of your site and introduce risk. Compensating controls should be implemented to mitigate risk from wireless mediums.

The second principle highlights the necessity for organizations to understand what is on their networks and how those components are connected to reduce their risk.

Principle 3: Centralize and standardize network connections

Principle three encourages organizations to standardize their network connections to combat the ever-present decentralized, inconsistent, and needlessly complex connections that introduce risk. The guidance recommends:

• Flexibility

  • Maintain a robust change management process to protect against emerging threats by continuously evaluating and refining connectivity and controls. Organizations must select products with ongoing support to adapt to regulatory changes and newer threat models.

• Repeatability

  • Connectivity models and plans should be standardized and reusable to reduce or eliminate the need for bespoke solutions that can lead to unnecessary and unexpected exposures.

• Categorized

  • While repeatability is necessary, distinctions in device and data types (across and within systems) allow selection of the most appropriate protections and controls for each system.

While more concise, the third principle should not be overlooked, given that complexity in systems can create unknown connections, leading to an increased attack surface.

Principle 4: Use standardized and secure protocols

OT system owners most often prioritize availability in the CIA (confidentiality, integrity, and availability) triad, especially in industrial or critical infrastructure environments. With that said, they should implement all components of the triad, including confidentiality and integrity, where possible.

The guidance suggests two main approaches:

Protocol Validation:

System owners should validate both the protocol and the data payloads within and between systems to ensure the traffic seen is expected and valid. The protocols in use and the payloads should be inspected at key trust boundaries, for example, the OT/IT boundary or between services, such as SCADA control software and a PLC. It is recommended that the validation of allowed traffic should be schema-based, that is, following a ‘known good’ model that only allows expected and desired traffic.

Industrial Protocols:

When evaluating what industrial protocols to use in your OT system, you should:

• Use modern, secure versions of protocols (CIP Security vs CIP or DNP2-SAv5 vs DNP3) that support cryptographic protections for integrity.

• Implement protocols that use open standards to allow for vendor-agnostic solutions to avoid vendor lock in and bespoke implementations.

• If utilized, require a business use case for the use of insecure protocols and implement compensating controls to manage the risk.

• Restrict OT protocols to isolated OT network segments, blocking, or when necessary, brokering external connections.

OT system owners need to implement modern and secure OT protocols to reduce the attack surface of their environments.

How runZero helps

When implemented correctly, these first four principles create a structured, repeatable approach to designing OT connectivity that simultaneously supports operational goals and strengthens cybersecurity posture.

runZero helps OT system owners implement these principles by:

1. Providing an asset inventory of OT, IoT, and IT assets

   • You can’t protect what you can’t see. runZero’s asset inventory enables system owners to see everything on the network.

2. Obsolete device detection

   • runZero natively provides EOL information for devices. In cases where EOL information is unavailable, runZero provides deep asset-level insight, including software and hardware version information. This allows system owners to know exactly what is on the network.

3. Detection of protocols and ports

   • With safe active scanning, runZero enables system owners to find the open ports and protocols on devices that may have been missed by other methods.

4. Segmentation validation

   • runZero can empower OT system owners to validate their network segmentation, ensuring their OT systems are not erroneously or incorrectly connected to the IT network.

5. Exposure management

   • runZero’s unauthenticated scanning provides a unique opportunity for system owners to uncover risks and exposures that matter. Instead of focusing on vulnerabilities that will never be exploited, runZero surfaces the problems that plague OT systems: obsolete protocols, misconfigurations, exposed admin interfaces, and more.

In OT environments — where uptime, safety, and reliability are paramount — these four foundational principles, along with runZero, empower OT systems owners to reduce their attack surface and keep their critical infrastructure secure.

Stay tuned for our third and final blog in this series as we discuss the final four principles from the guidance.

On October 15, 2025, F5 disclosed a denial of service vulnerability, designated CVE-2025-53521, in F5 BIG-IP Access Policy Manager (APM).

On Friday, March 27, 2026, F5 updated the CVE entry to indicate that the vulnerability is now known to be a remote code execution vulnerability (RCE) with a CVSS score of 9.8. This vulnerability is now known to allow a remote, unauthenticated attacker to perform remote code execution.

This vulnerability is known to be exploited in the wild and was added to the CISA.gov Known Exploited Vulnerabilities (KEV) list on March 27, 2026.

The following versions are affected:

• F5 BIG-IP Access Policy Manager versions 17.5.0 - 17.5.1 (inclusive)
• F5 BIG-IP Access Policy Manager versions 17.1.0 - 17.1.2 (inclusive)
• F5 BIG-IP Access Policy Manager versions 16.1.0 - 16.1.6 (inclusive)
• F5 BIG-IP Access Policy Manager versions 15.1.0 - 15.1.10 (inclusive)

What is F5 BIG-IP Access Policy Manager (APM)?

F5 BIG-IP Access Policy Manager (APM) is a software module on F5 BIG-IP appliances that acts as an identity-aware proxy and VPN.

What is the impact?

Successful exploitation of this vulnerability would allow a remote, unauthenticated attacker to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are any updates or workarounds available?

Upgrade affected versions of F5 BIG-IP Access Policy Manager to the latest patched version.

• 17.5.x upgrade to 17.5.1.3 or later
• 17.1.x upgrade to 17.1.3 or later
• 16.1.x upgrade to 16.1.6.1 or later
• 15.1.x upgrade to 15.1.10.8 or later

How do I find F5 Big-IP assets with runZero?

From the Software Inventory, use the following query to locate potentially affected systems:

vendor:=F5 AND product:="BIG-IP Access Policy Manager"

October 2025: CISA Emergency Directive

On October 15, 2025, CISA issued an emergency directive to mitigate vulnerabilities on F5 Big-IP appliances. According to the directive, the general guidance is to "inventory F5 BIG-IP products, evaluate if the networked management interfaces are accessible from the public internet, and apply newly released updates from F5."

What is F5 Big-IP?

F5 Big-IP appliances provide application delivery and security services to enhance security and improve performance of network applications.

What is the impact?

According to the directive, "a nation-state affiliated actor compromised F5 systems and exfiltrated data, including portions of the Big-IP proprietary source code and vulnerability information". The emergency directive specifically calls out "all instances of F5 BIG-IP hardware devices and F5OS, BIG-IP TMOS, Virtual Edition, BIG-IP Next, BIG-IP IQ software, and BNK / CNF". Organizations should apply the latest vendor updates and disconnect any affected publicly-connected devices that have reached their end-of-support date.

For more information, refer directly to the CISA emergency directive. 

How do I find F5 Big-IP assets with runZero?

From the Asset Inventory, use the following query to locate potentially affected systems:

os:="F5%"

May 2022: CVE-2022-1388

In May 2022, technology vendor F5 published information on over 40 vulnerabilities, mostly affecting their BIG-IP line of products. While these vulnerabilities included a mix of types and severities, a particular authentication bypass vulnerability that affected all BIG-IP modules was concerning enough that CISA specifically called it out.

What was the impact?

Known as CVE-2022-1388 (CVSS “critical” score of 9.8), a vulnerable BIG-IP target could allow for takeover by an unauthenticated attacker via network connection or management port. Once connected to a vulnerable target, successful exploitation was achieved via a crafted HTTP request sent by the attacker, bypassing iControl REST authentication and providing the attacker full access and control. F5 did add that there was no data plane exposure via exploitation of this vulnerability, rather "this being a control plane issue only".

Were updates available?

Patches were made available by F5 for CVE-2022-1388, as well for many of the other vulnerabilities included in their security advisory overview. Guidance also included mitigation steps if immediate or near-term patching was not an option.

On January 13, 2026, Microsoft disclosed a remote code execution vulnerability, designated CVE-2026-20963, in Microsoft SharePoint. The vulnerability is due to deserialization of untrusted data in Microsoft SharePoint which allows a remote, unauthenticated attacker attacker to execute code over a network.

While initially released with a CVSS score of 8.8, the score was updated to 9.8 on March 17, 2026.

This vulnerability is known to be exploited in the wild and was added to the CISA.gov Known Exploited Vulnerabilities (KEV) list on March 18, 2026.

The following versions are affected:

• SharePoint Enterprise Server 2016 before version 16.0.5535.1001
• SharePoint Server 2019 before version 16.0.10417.20083
• SharePoint Server Subscription Edition before version 16.0.19127.20442

What is the impact?

Successful exploitation of this vulnerability would allow a remote, unauthenticated attacker to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are any updates or workarounds available?

Upgrade affected versions of SharePoint Server to the latest patched version.

• SharePoint Enterprise Server 2016 version 16.0.5535.1001 or later

• SharePoint Server 2019 version 16.0.10417.20083 or later

• SharePoint Server Subscription Edition version 16.0.19127.20442 or later

How do I find Microsoft SharePoint Server installations with runZero?

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:=Microsoft AND (
  (product:="SharePoint Server 2016" AND (version:>=16.0 AND version:<16.0.5535.1001)) OR
  (product:="SharePoint Server 2019" AND (version:>=16.0 AND version:<16.0.10417.20083)) OR
  (product:="SharePoint Server Subscription Edition" AND (version:>=16.0 AND version:<16.0.19127.20442))
  ) AND NOT version:=""

July 2025 (Multiple CVEs)

Microsoft has disclosed two vulnerabilities in certain versions of on-premises Microsoft SharePoint Server:

• SharePoint Server deserializes untrusted data without sufficiently ensuring that the resulting data will be valid resulting in a remote code execution (RCE) vulnerability. The vulnerability allows an unauthenticated adversary to remotely execute code on the vulnerable server. This vulnerability has been designated CVE-2025-53770 and has been rated critical with a CVSS score of 9.8. This vulnerability is a variant of a remote code execution vulnerability designated CVE-2025-49704 that was patched earlier this month. There is evidence that this vulnerability is being actively exploited in the wild.
• SharePoint Server improperly limits a pathname to a restricted directory allowing path traversal in Microsoft Office SharePoint resulting in a spoofing vulnerability. The vulnerability allows an authorized adversary to perform spoofing over a network. This vulnerability has been designated CVE-2025-53771 and has been rated medium with a CVSS score of 6.3. This vulnerability is a variant of a spoofing vulnerability designated CVE-2025-49706 that was patched earlier this month.

The following versions are affected

• Microsoft SharePoint Enterprise Server 2016 versions currently unknown
• Microsoft SharePoint Server 2019 versions currently unknown
• Microsoft SharePoint Server Subscription Edition versions 16.0.0 prior to 16.0.18526.20508

What is the impact?

Successful exploitation of these vulnerabilities would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are any updates or workarounds available?

As of 7/20/2025 security updates are available for Microsoft SharePoint Server Subscription Edition. A patch is currently unavailable for other affected versions, but Microsoft is actively working on a security update.

• Mitigate attacks against on-premises SharePoint Server environments by configuring the Windows Antimalware Scan Interface (AMSI) integration in SharePoint and deploying Defender AV on all SharePoint servers. This should stop an unauthenticated adversary from successfully exploiting the vulnerability.
• Rotate SharePoint Server ASP.NET machine keys.

• Upgrade affected systems to the new versions when a patch is available.

How do I find Microsoft SharePoint Server installations with runZero?

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:="Microsoft" AND product:="SharePoint Server%"

Several vulnerabilities affecting Apple's device ecosystem have been weaponized into an exploit chain known as DarkSword. These vulnerabilities enable remote code execution and payload deployment when a user visits a malicious website.

This exploit chain is known to have been used by multiple commercial surveillance vendors and suspected state-sponsored actors. In March 2026, the chain and related exploit kit tooling was leaked publicly and is now available for use by a wider range of malicious actors.

While the exploit kit was used to attack iOS, the vulnerabilities are known to have existed in iPadOS, macOS, tvOS, watchOS, and visionOS.

There are 6 vulnerabilities known to be part of the DarkSword exploit chain:

• CVE-2025-14174 - Memory corruption vulnerability in ANGLE, patched in 18.7.3 and 26.2
  
• CVE-2025-31277 - Memory corruption vulnerability in JavaScriptCore, patched in 18.6
• CVE-2025-43510 - Memory management vulnerability in the iOS kernel, patched in 18.7.2 and 26.1
• CVE-2025-43520 - Memory corruption vulnerability in the iOS kernel, patched in 18.7.2 and 26.1
• CVE-2025-43529 - Memory corruption vulnerability in JavaScriptCore, patched in 18.7.3 and 26.2
• CVE-2026-20700 - User-mode Pointer Authentication Code (PAC) bypass in dyld, patched in 26.3

What is the impact?

Upon successful exploitation of the exploits above the attacker is able to compromise the target device and install backdoor software.

Are updates or workarounds available?

Vulnerable devices should be upgraded 26.3 or later. If the device cannot be updated to 26.3, update to 18.7.3 or later. Both of these updates were released in Feb 2026.

If the device cannot be updated then Lockdown mode can be enabled to mitigate the risk of these vulnerabilities. Lockdown mode is a highly restrictive security mode that may cause some functionality to be limited.

How do I find potentially vulnerable Apple devices with runZero?

From the Asset Inventory, use the following query to locate assets running potentially vulnerable versions of the affected products:

(os:="apple ios" OR os:="apple ipados" OR os:="apple tvos" OR os:="apple macos" OR os:="apple watchos" OR os:="apple visionos") AND osversion:>0 AND ((osversion:>="26.0" AND osversion:<"26.3") OR (osversion:>="18.0" AND osversion:<"18.7.3"))

Citrix has published Security Bulletin CTX696300, documenting multiple vulnerabilities that impact customer-managed installations of NetScaler ADC (formerly Citrix ADC) and NetScaler Gateway (formerly Citrix Gateway). In certain gateway and load-balancing configurations, these devices are vulnerable to multiple vulnerabilities:

• CVE-2026-3055 - Insufficient input validation leading to memory overread. This vulnerability is considered critical with a CVSS score of 9.3.
  
• CVE-2026-4368 - A race condition could lead to user session mixup. This vulnerability is considered severe, with a CVSS score of 7.7.

The following versions are affected:

• NetScaler ADC and NetScaler Gateway 14.1 BEFORE 14.1-66.59
• NetScaler ADC and NetScaler Gateway 13.1 BEFORE 13.1-62.23
• NetScaler ADC FIPS and NDcPP BEFORE 13.1-37.262

Note: Citrix ADC / NetScaler 13.0 and prior have reached end of life. Citrix has made no statements regarding the vulnerabilities in these versions, but they are possibly affected as well.

What is the impact?

Citrix has not published guidance on the impact of these vulnerabilities. Given the values that they have provided for the CVSS score it likely that successful exploitation of these vulnerabilities could result in full system compromise.

Are updates or workarounds available?

Citrix recommends upgrading affected systems to one of the following versions as soon as possible:

• NetScaler ADC and NetScaler Gateway 14.1-66.59 and later releases
• NetScaler ADC and NetScaler Gateway 13.1-62.23 and later releases of 13.1
• NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1.37.262 and later releases of 13.1-FIPS and 13.1-NDcPP

How do I find potentially vulnerable systems with runZero?

From the Asset Inventory, use the following query to locate systems running potentially vulnerable software:

hw:="Citrix NetScaler%" OR hw:="Citrix ADC%" OR os:="Citrix NetScaler%" OR os:="Citrix ADC"

September 2025 (CVE-2025-7775, CVE-2025-7776, CVE-2025-8424)

Citrix has published Security Bulletin CTX694938, documenting multiple vulnerabilities that impact customer-managed installations of NetScaler ADC (formerly Citrix ADC) and NetScaler Gateway (formerly Citrix Gateway). In certain gateway and load-balancing configurations, these devices are vulnerable to multiple vulnerabilities:

• CVE-2025-7775 - A memory corruption vulnerability that could allow a remote attacker to execute arbitrary code on the system. This vulnerability is considered critical with a CVSS score of 9.2.
  
• CVE-2025-7776 - A memory corruption vulnerability that could allow a remote attacker to create a denial-of-service condition. This vulnerability is considered severe, with a CVSS score of 8.8.
• CVE-2025-8424 - An improper authentication vulnerability that could allow a remote attacker to gain access to sensitive system resources without proper authorization. This vulnerability is considered severe, with a CVSS score of 8.7.

There is evidence that CVE-2025-775 is being actively exploited in the wild.

The following versions are affected:

• NetScaler ADC and NetScaler Gateway 14.1  before 14.1-47.48
• NetScaler ADC and NetScaler Gateway 13.1  before 13.1-59.22
• NetScaler ADC 13.1-FIPS and NDcPP before 13.1-37.241-FIPS and NDcPP
• NetScaler ADC 12.1-FIPS and NDcPP before 12.1-55.330-FIPS and NDcPP

What is the impact?

Successful exploitation of this vulnerability could allow an adversary to execute arbitrary code on the vulnerable system, potentially leading to total system compromise or a denial-of-service condition.

Are updates or workarounds available?

Citrix recommends upgrading affected systems to one of the following versions as soon as possible:

• NetScaler ADC and NetScaler Gateway 14.1-47.48 and later releases
• NetScaler ADC and NetScaler Gateway 13.1-59.22 and later releases of 13.1
• NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1-37.241 and later releases of 13.1-FIPS and 13.1-NDcPP
• NetScaler ADC 12.1-FIPS and 12.1-NDcPP 12.1-55.330 and later releases of 12.1-FIPS and 12.1-NDcPP

How do I find potentially vulnerable systems with runZero?

From the Asset Inventory, use the following query to locate systems running potentially vulnerable software:

hw:="Citrix NetScaler%" OR hw:="Citrix ADC%" OR os:="Citrix NetScaler%" OR os:="Citrix ADC"

June 2025 (CVE-2025-6543)

Citrix published Security Bulletin CTX694788 that documented a vulnerability that impacts customer-managed installations of NetScaler ADC (formerly Citrix ADC) and NetScaler Gateway (formerly Citrix Gateway) configured as a Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or Authentication, Authorization and Auditing (AAA) virtual server are affected by a memory overflow vulnerability. This vulnerability has been designated CVE-2025-6543 and has been rated critical with a CVSS score of 9.2.

There is evidence that this vulnerability is being actively exploited in the wild.

The following versions are affected

• NetScaler ADC and NetScaler Gateway 14.1 prior to 14.1-47.46
• NetScaler ADC and NetScaler Gateway 13.1 prior to 13.1-59.19
• NetScaler ADC 13.1-FIPS and NDcPP prior to 13.1-37.236-FIPS and NDcPP

What is the impact?

Successful exploitation of this vulnerability could allow an adversary to make unintended changes to control flow, potentially allowing remote code execution (RCE) or causing denial-of-service (DoS).

Are updates or workarounds available?

Citrix recommends upgrading affected systems to one of the following versions as soon as possible:

• NetScaler ADC and NetScaler Gateway to version 14.1-47.46 and later releases
• NetScaler ADC and NetScaler Gateway to version 13.1-59.19 and later releases of 13.1
• NetScaler ADC 13.1-FIPS and 13.1-NDcPP to version 13.1-37.236 and later releases of 13.1-FIPS and 13.1-NDcPP

NetScaler ADC and NetScaler Gateway versions 12.1 and 13.0 are end-of-life (EOL) and no longer supported. It is recommended to upgrade to one of the currently supported versions that address the vulnerabilities.

How do I find potentially vulnerable systems with runZero?

From the Asset Inventory, use the following query to locate systems running potentially vulnerable software:

hw:="Citrix NetScaler%" OR hw:="Citrix ADC%" OR os:="Citrix NetScaler%" OR os:="Citrix ADC"

June 2025 (CVE-2025-5777, CVE-2025-5349)

Citrix published Security Bulletin CTX693420 that documented two vulnerabilities that impact customer-managed installations of NetScaler ADC (formerly Citrix ADC) and NetScaler Gateway (formerly Citrix Gateway). There is evidence that one of the vulnerabilities, designated by CVE-2025-5777, is being actively exploited in the wild.

• NetScaler configured as a Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or Authentication, Authorization and Auditing (AAA) virtual server are at risk of an insufficient input validation vulnerability leading to memory out-of-bounds read in the NetScaler Management Interface which could allow access to secret values, bypass of protection mechanism, DoS or other unexpected results. This vulnerability has been designated CVE-2025-5777 and has been rated critical with a CVSS score of 9.3.
• An attacker with access to the NetScaler appliance IP (NSIP) address, Cluster Management IP (CLIP) address or local Global Server Load Balancing (GSLB) Site IP (GSLBIP) address could utilize an improper access control vulnerability to gain access the the NetScaler Management Interface and its management functions. This vulnerability has been designated CVE-2025-5349 and has been rated high with a CVSS score of 8.7.

The following versions are affected

• NetScaler ADC and NetScaler Gateway 14.1 prior to 14.1-43.56
• NetScaler ADC and NetScaler Gateway 13.1 prior to 13.1-58.32
• NetScaler ADC 13.1-FIPS and NDcPP prior to 13.1-37.235-FIPS and NDcPP
• NetScaler ADC 12.1-FIPS prior to 12.1-55.328-FIPS

What is the impact?

Successful exploitation of these vulnerabilities could allow an attacker to obtain sensitive information, potentially disrupt system operations and cause a denial-of-service, or gain control over the NetScaler Management Interface and its management functions potentially leading to system compromise.

Are updates or workarounds available?

Citrix recommends upgrading affected systems to one of the following versions as soon as possible:

• NetScaler ADC and NetScaler Gateway to version 14.1-43.56 and later releases
• NetScaler ADC and NetScaler Gateway to version 13.1-58.32 and later releases of 13.1
• NetScaler ADC 13.1-FIPS and 13.1-NDcPP to version 13.1-37.235 and later releases of 13.1-FIPS and 13.1-NDcPP
• NetScaler ADC 12.1-FIPS to version 12.1-55.328 and later releases of 12.1-FIPS

NetScaler ADC and NetScaler Gateway versions 12.1 and 13.0 are end-of-life (EOL) and no longer supported. It is recommended to upgrade to one of the currently supported versions that address the vulnerabilities.

How do I find potentially vulnerable systems with runZero?

From the Asset Inventory, use the following query to locate systems running potentially vulnerable software:

hw:="Citrix NetScaler%" OR hw:="Citrix ADC%" OR os:="Citrix NetScaler%" OR os:="Citrix ADC"

February 2025 (CVE-2024-12284)

Citrix issued a security bulletin for the on-premise NetScaler Console (formerly NetScaler ADM) and NetScaler Agent products. CVE-2024-12284 is rated high with a CVSS score of 8.8, which could lead to privilege escalation.

What is the impact?

For customers running an on-premise installation of NetScaler Console with NetScaler Console Agents deployed, an authenticated remote attacker could "execute commands without additional authorization". NetScaler emphasized that an attacker must be authenticated, which limits the potential impact. 

Are updates or workarounds available?

Citrix recommends upgrading to one of the following versions as soon as possible:

• NetScaler Console 14.1-38.53 and later releases
• NetScaler Console 13.1-56.18 and later releases of 13.1
• NetScaler Agent 14.1-38.53 and later releases
• NetScaler Agent 13.1-56.18 and later releases of 13.1

How do I find potentially vulnerable systems with runZero?

From the Service Inventory, use the following query to locate systems running potentially vulnerable software:

_asset.protocol:http AND protocol:http AND html.title:="NetScaler Console"

June 2024: (CVE-2023-6548, CVE-2023-6549)

In January Citrix published Security Bulletin CTX584986 that documented two vulnerabilities that impact NetScaler ADCs and Gateways. The most severe of these, CVE-2023-6549, was discovered and documented by BishopFox.

CVE-2023-6549 is rated high with a CVSS score of 8.2. This vulnerability is an unauthenticated out-of-bounds memory read which could be exploited to collect information from the appliance’s process memory, including HTTP request bodies. While serious, this is not thought to be a bad as the Citrix Bleed vulnerability due to the new vulnerability being less likely to leak high risk data.

CVE-2023-6548 is rated medium with a CVSS score of 5.5. This vulnerability is a code injection flaw that allows remote code injection by an authenticated attacker (with low privileged) with access to a management interface on one of the NSIP, CLIP or SNIP interfaces.

What is the impact?

The vulnerability would enable an attacker to remotely obtain sensitive information from a NetScaler appliance configured as a Gateway or AAA virtual server via a very commonly connected Web interface, and without requiring authentication. CVE-2023-6549 is nearly identical to the Citrix Bleed vulnerability (CVE-2023-4966), except it is less likely to return highly sensitive information to an attacker. CVE-2023-6548 could be used by an attacker with credentials to execute code.

Are updates or workarounds available?

Citrix recommends limiting access to management interfaces as well as upgrading to one of the following versions:

• NetScaler ADC and NetScaler Gateway 14.1-12.35 and later releases
• NetScaler ADC and NetScaler Gateway  13.1-51.15 and later releases of 13.1
• NetScaler ADC and NetScaler Gateway 13.0-92.21 and later releases of 13.0
• NetScaler ADC 13.1-FIPS 13.1-37.176 and later releases of 13.1-FIPS 
• NetScaler ADC 12.1-FIPS 12.1-55.302 and later releases of 12.1-FIPS 
• NetScaler ADC 12.1-NDcPP 12.1-55.302 and later releases of 12.1-NDcPP

Warning: NetScaler ADC and NetScaler Gateway version 12.1 is now End Of Life (EOL). Citrix advises customers to upgrade their appliances to one supported version that addresses the vulnerabilities.

How do I find potentially vulnerable systems with runZero?

From the Asset Inventory, use the following query to locate systems running potentially vulnerable software:

product:netscaler OR product:"citrix adc"

July 2023 (CVE-2023-3519)

In July, 2023, Citrix alerted customers to three vulnerabilities in its NetScaler ADC and NetScaler Gateway products. Surfaced by researchers at Resillion, these vulnerabilities included a critical flaw currently being exploited in the wild to give attackers unauthenticated remote code execution on vulnerable NetScaler targets (CVE-2023-3519). Compromised organizations included a critical infrastructure entity in the U.S., where attackers gained access the previous month and successfully exfiltrated Active Directory data. And at the time of publication, there appear to be over 5,000 public-facing vulnerable NetScaler targets.

What was the impact?

The three reported vulnerabilities affecting NetScaler ADC and Gateway products were of various types, and each include different preconditions required for exploitation:

• Unauthenticated remote code execution (CVE-2023-3519; CVSS score 9.8 - "critical")
  • Successful exploitation required the NetScaler target be configured as a Gateway (VPN virtual server, ICA Proxy, CVPN, or RDP Proxy) or "authentication, authorization, and auditing" (AAA) virtual server.
• Reflected cross-site scripting (XSS) (CVE-2023-3466; CVSS score 8.3 - "high")
  • Successful exploitation required the victim to be on the same network as the vulnerable NetScaler target when the victim loaded a malicious link (planted by the attacker) in their web browser.
• Privilege escalation to root administrator (nsroot) (CVE-2023-3467; CVSS score 8.0 - "high")
  • Successful exploitation required an attacker having achieved command-line access on a vulnerable NetScaler target.

U.S.-based CISA reported attackers exploiting CVE-2023-3519 to install webshells used in further network exploration and data exfiltration, causing CVE-2023-3519 to be added to CISA's Known Exploited Vulnerabilities Catalog. Other common attacker goals, like establishing persistence, lateral movement, and malware deployment, were all potential outcomes following successful exploitation.

Citrix made patched firmware updates available. Admins were advised to update older firmware on vulnerable NetScaler devices as soon as possible.

CISA also made additional information available around indicators of compromise and mitigations.

How to find potentially vulnerable NetScaler instances with runZero

From the Asset inventory, they used the following prebuilt query to locate NetScaler instances on their network:

hw:="Citrix NetScaler%" OR hw:="Citrix ADC%" OR os:="Citrix NetScaler%" OR os:="Citrix ADC"

Results from the above query should be triaged to verify they are affected ADC or Gateway products and if they are running updated firmware versions.

The following query could also be used in on the Software and Services inventory pages to locate NetScaler software:

product:netscaler

Results from the above query should be triaged to verify they are affected ADC or Gateway products and if they are updated versions.

As always, any prebuilt queries are available from your runZero console. Check out the documentation for other useful inventory queries.

Oracle has disclosed a vulnerability in specific versions of its Identify Manager and Web Services Manager products, contained within the Oracle Fusion Middleware suite that, when exploited, may allow a remote, unauthenticated adversary to takeover vulnerable Oracle Identity Manager and Web Services Manager installations. This vulnerability has been designated CVE-2026-21992 and has been rated critical with a CVSS score of 9.8.

The following versions are affected

• Oracle Identity Manager versions 12.2.1.4.0 and 14.1.2.1.0

What is Oracle Identity Manager?

Oracle Identity Manager is a complete security platform that manages user lifecycles and provides secure access to enterprise resources. It automates user management across cloud and on-premises systems, enables secure sign-on with features like multi-factor authentication.

What is the impact?

Successful exploitation of this vulnerability can result in takeover of Oracle Identity Manager and Oracle Web Services Manager.

Are updates or workarounds available?

Users are encouraged to upgrade affected versions of Oracle Identity Manager and Oracle Web Services Manager to the latest patched version as quickly as possible. Oracle has included patching instructions on their website.

How to find potentially vulnerable systems with runZero

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:=Oracle AND (product:"Identity Manager" OR product:"Web Services Manager")

November 2025: Oracle Identity Manager vulnerability: CVE-2025-61757

Oracle has disclosed a vulnerability in certain versions of its Identify Manager contained within the Oracle Fusion Middleware suite that, when exploited, may allow a remote, unauthenticated adversary to achieve arbitrary remote code execution (RCE). This vulnerability has been designated CVE-2025-61757 and has been rated critical with a CVSS score of 9.8.

There is evidence that this vulnerability is being actively exploited in the wild.

The following versions are affected

• Oracle Identity Manager versions 12.2.1.4.0 and 14.1.2.1.0

What is the impact?

Successful exploitation of these vulnerabilities would allow an adversary to execute arbitrary commands on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

Users are encouraged to upgrade affected versions of Oracle Identity Manager to the latest patched version as quickly as possible.

How to find potentially vulnerable systems with runZero

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:="Oracle" product:="Identity Manager"

A vulnerability has been discovered in Langflow. 

This vulnerability, designated CVE-2026-33017 has a CVSS score of 9.3 (critical). Exploiting this vulnerability allows a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system.

There is evidence that this vulnerability is being actively exploited in the wild.

The following versions are affected

• All versions prior to 1.8.2

What is Langflow?

Langflow is a popular, open-source tool for building and deploying AI-powered agents and workflows.

What is the impact?

Successful exploitation of this vulnerability would allow an attacker to execute arbitrary code on the vulnerable system with the privileges of the Langflow process. This vulnerability is remotely exploitable without authentication.

Are updates available?

The Langflow project has released version 1.8.2 to address this vulnerability and urges all users to upgrade to that or a later version as quickly as possible.

How do I find potentially vulnerable Langflow installations with runZero?

Vulnerable devices can be found by navigating to the Software Inventory and using the following query:

vendor:=Langflow AND product:=Langflow AND (version:>0 AND version:<1.8.2)

June 2025: Langflow vulnerability (CVE-2025-3248)

A vulnerability has been discovered in Langflow, a popular framework for building AI workflows. This vulnerability, designated CVE-2025-3248 has a CVSS score of 9.8 (critical). Successfully exploiting this vulnerability would allow a remote, unauthenticated attacker to execute arbitrary code on the vulnerable system.

Note that CISA has indicated that there is evidence this vulnerability is being exploited in the wild.

Update: As of June 17th, 2025, there is evidence that this vulnerability is actively being exploited as part of the Flodrix botnet. Trend Micro has published a report detailing an active campaign that utilizes an open-source proof of concept (PoC) exploit for CVE-2025-3248 to initially compromise the system. The attacker then downloads and executes the Flodrix malware to establish communication with the command and control (C&C) server for the Flodrix botnet.

What is the impact?

Successful exploitation of this vulnerability would allow an attacker to execute arbitrary code on the vulnerable system with the privileges of the Langflow process. This vulnerability is exploitable remotely and without authentication.

Are updates available?

The Langflow project has released version 1.3.0 to address this vulnerability and urges all users to upgrade to that or a later version as quickly as possible.

How do I find potentially vulnerable Langflow installations with runZero?

Vulnerable devices can be found by navigating to the Software Inventory and using the following query:

_asset.protocol:http AND product:Langflow AND (version:>0 AND version:<1.3.0)

A configuration injection vulnerability was discovered and fixed in the Kubernetes Ingress-NGINX controller software.

• The vulnerability has been designated CVE-2026-4342 and has been rated high with a CVSS score of 8.8.

The following versions are affected

• Ingress-NGINX controller versions through v1.13.9 (exclusive)
• Ingress-NGINX controller versions through v1.14.5 (exclusive)
• Ingress-NGINX controller versions through v1.15.1 (exclusive)

What is Kubernetes Ingress-NGINX?

Kubernetes Ingress-NGINX controller provides reverse proxy and load balancing to Kubernetes services, providing an HTTP/HTTPS gateway to cluster resources.

What's the impact?

Successful exploitation could lead to arbitrary code execution in the context of the Ingress-NGINX controller, as well as disclosure of secrets accessible to the controller. The Ingress-NGINX controller can access all cluster-wide secrets in its default configuration.

Are updates or workarounds available?

Users are encouraged to update to versions 1.13.9, 1.14.5, 1.15.1 or a later version.

How to find potentially vulnerable Ingress-Nginx services with runZero

From the Services Inventory, use the following query to locate potentially vulnerable systems:

(_asset.protocols:tls AND protocol:tls AND tls.issuer:="O=nil1" AND tls.subject:="O=nil2" AND tls.names:"%nginx%")

February 2026: Kubernetes Ingress-NGINX Controller (CVE-2026-1580, CVE-2026-24512, CVE-2026-24513, and CVE-2026-24514)

Today, in a message from the Kubernetes Security Response Committee (SRC), users were notified of four vulnerabilities, which, if left exposed and unpatched, could be exploited to achieve remote code execution by unauthenticated attackers.

What's the impact?

Three of the vulnerabilities relate to validation and sanitation of user-controlled fields (CVE-2026-24512, CVE-2026-24513, and CVE-2026-24514). Out of the three, CVE-2026-24513 is the most concerning, which potentially allows for an attacker to bypass the auth-url annotation if the backend service fails to honor the X-Code HTTP header. In addition, CVE-2026-1580 potentially allows for attackers to inject configuration into NGINX, leading to arbitrary code execution in the context of the Ingress-NGINX controller. Notably, the attack does appear to depend on a clear shot to the admission controller for the Ingress-NGINX controller, which itself is an optional component that allows for Kubernetes-homed services to be reached from the wider network.

Finally, it’s important to note that the very similarly-named NGINX Ingress controller is not affected by these Ingress-NGINX controller vulnerabilities.

Are updates or workarounds available?

Users are advised to update to version 1.13.7, 1.14.3, or any later version as quickly as possible.

How to find potentially vulnerable Ingress-Nginx services with runZero

From the Services Inventory, use the following query to locate potentially vulnerable systems:

(_asset.protocols:tls AND protocol:tls AND tls.issuer:="O=nil1" AND tls.subject:="O=nil2" AND tls.names:"%nginx%")

ConnectWise released a security bulletin for an improper verification of cryptographic signature vulnerability found in the ScreenConnect software.

The following versions are affected:

• ConnectWise ScreenConnect versions prior to 26.1

This vulnerability has been designated CVE-2026-3564 and has a CVSS score of 9 (critical).

What is ConnectWise ScreenConnect?

ConnectWise ScreenConnect provides remote desktop access for end-users and IT professionals for support, maintenance,
or collaboration.

What is the impact?

Successful exploitation can allow unauthorized access to ScreenConnect and unauthorized actions within the application, including privilege escalation in certain scenarios. Cloud installations are already patched.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible (within days). The latest available release for on-premise installations is 26.1.

How do I find vulnerable ScreenConnect installations with runZero?

From the Software Inventory, use the following query to locate potentially vulnerable ConnectWise ScreenConnect installations:

vendor:ConnectWise AND product:ScreenConnect AND (version:>0 AND version:<26.1)

June 2025, ScreenConnect vulnerability (CVE-2025-3935)

Certain versions of ConnectWise ScreenConnect may be susceptible to ViewState code injection attacks in ASP.NET Web Forms. The ViewState is used by ASP.NET to preserve page state across multiple requests. The data is encoded using Base64 and protected by cryptographic keys referred to as machine keys. It is important to note that it typically requires privileged system level access to obtain these machine keys. This issue could potentially impact any product utilizing ASP.NET framework ViewStates. There is evidence that this vulnerability is being actively exploited in the wild.

The following versions are affected:

• ConnectWise ScreenConnect versions prior to 25.2.4

This vulnerability has been designated CVE-2025-3935 and has a CVSS score of 8.1 (high).

What is the impact?

If machine keys are compromised, successful exploitation of the vulnerability could allow attackers to create and send a malicious ViewState to the website, potentially leading to remote code execution on the server.

Are updates or workarounds available?

ConnectWise has released an update, 25.2.4, that fixes these issues by disabling the ViewState and removing any dependency on it. ConnectWise recommends that all users upgrade to this version immediately.

How do I find vulnerable ScreenConnect installations with runZero?

From the Software Inventory, use the following query to locate potentially vulnerable ConnectWise ScreenConnect installations:

vendor:ConnectWise AND product:ScreenConnect AND (version:>0 AND version:<25.2.4)

Previous ScreenConnect vulnerabilities (CVE-2024-1708, CVE-2024-1709)

On February 19, 2024, ConnectWise disclosed two serious vulnerabilities in their ScreenConnect (formerly Control) remote-access product.

The first vulnerability is an authentication bypass vulnerability. Successful exploitation of this vulnerability would allow attackers to execute arbitrary commands with full privileges on the target system. This vulnerability has been assigned a CVSS score of 10, indicating a highly critical vulnerability.

The second issue is a path-traversal vulnerability. Successful exploitation of this vulnerability would allow attackers to access restricted resources on vulnerable systems. The vendor has not disclosed what resources may be accessed when exploiting this vulnerability. This vulnerability has been assigned a CVSS score of 8.4, indicating a high severity.

Note that CVEs are not yet assigned for these vulnerabilities.

Note that there is evidence that these vulnerabilities are being actively exploited in the wild.

What is the impact?

Successful exploitation of these vulnerabilities would allow attackers to execute arbitrary commands with full privileges on the target system, potentially leading to complete system compromise.

Are updates or workarounds available?

ConnectWise has released an update, version 23.9.8, that fixes these issues. ConnectWise recommends that all users upgrade to this version immediately.

How do I find ScreenConnect installations with runZero?

From the Services Inventory, use the following query to locate potentially vulnerable ConnectWise ScreenConnect systems:

vendor:ConnectWise AND (product:Control OR product:ScreenConnect)

Note the check for the former product name (“Control”).

Additional fingerprinting research is ongoing, and additional queries will be published as soon as possible.

Ubiquiti disclosed multiple vulnerabilities affecting certain versions of the UniFi Network Application:

• A path traversal vulnerability. Successful exploitation allows a network, unauthenticated adversary to access files on the underlying system that could be manipulated to access an underlying account. The vulnerability has been designated CVE-2026-22557 and has been rated critical with a CVSS score of 10.0.
• A NoSQL injection vulnerability. Successful exploitation allows a network, authenticated adversary to escalate privileges. The vulnerability has been designated CVE-2026-22558 and has been rated high with a CVSS score of 7.7.

The following versions are affected

• UniFi Network Application versions 10.1.85 and earlier
• UniFi Network Application versions 10.2.93 and earlier
• UniFi Network Application versions 9.0.114 and earlier

What is Ubiquiti UniFi Network Application?

What is the impact?

Successful exploitation of the vulnerabilities could allow an adversary to gain unauthorized access to the UniFi Network Application compromising the overall system integrity.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• UniFi Network Application versions 10.1.89 or later
• UniFi Network Application versions 10.2.97 or later.
• UniFi Express firmware to 4.0.13 or later, which updates the UniFi Network Application to version 9.0.118 or later.

How to find potentially vulnerable systems with runZero

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:Ubiquiti AND product:"UniFi Network"

This guidance builds on the earlier publication Foundations for OT Cybersecurity, which focused on helping organizations establish a foundational OT asset inventory — because you can’t secure what you can’t see. The newly released Secure Connectivity Principles for Operational Technology expands on that work by providing system owners with a framework to design, implement, and manage secure connectivity across both new and existing OT environments.

Why secure OT connectivity matters

OT environments differ significantly from traditional IT systems because they directly interact with the physical world. As a result, cyber incidents affecting OT systems can have far more serious consequences than typical IT disruptions. Potential impacts include environmental damage, disruption of essential services, or even risks to human safety.

Historically, many OT environments were air-gapped or heavily segmented from enterprise IT networks. However, modernization, remote management, and increasing integration with IT systems have made OT environments far more connected than they once were. While this connectivity enables greater efficiency and visibility, it also expands the attack surface and increases the risk of compromise.

The new guidance is intended to help organizations navigate this reality by providing practical principles for securing connectivity while still enabling the operational benefits that modern OT environments require.

8 principles for a secure OT environment

Threat actors are consistently, effectively, and intentionally targeting OT systems with the intent to steal, disrupt, or destroy critical infrastructure. As a result, organizations responsible for OT environments should treat this guidance as a desired end-state, even when it is not a regulatory requirement. Given the importance of these systems, the agencies responsible for this guidance believe all OT system owners should expediently operationalize the principles outlined to help secure critical infrastructure against adversarial action.

The Secure Connectivity Principles for Operational Technology guidance outlines eight core principles designed to help organizations reduce risk and strengthen their defensive posture:

1. Balance risks and opportunities
2. Limit the exposure of connectivity
3. Centralize and standardize network connections
4. Use standardized and secure protocols
5. Harden your OT boundary
6. Limit the impact of compromise
7. Ensure all connectivity is logged and monitored
8. Establish an isolation plan

Together, these principles provide a practical roadmap for designing and operating OT networks that are resilient to modern cyber threats while still supporting operational requirements.

What’s next

In the coming weeks, we’ll take a closer look at each of these principles — exploring why they matter, how organizations can implement them in real-world OT environments, and what challenges teams may encounter along the way.

Stay tuned for parts two and three. We’ll unpack these principles and discuss how runZero can help operators gain visibility and control to better protect critical infrastructure.

Cisco disclosed in two advisories that certain versions of Cisco Secure Firewall Management Center (FMC) are affected by the following vulnerabilities:

• The Cisco FMC web interface contains an authentication bypass vulnerability stemming from an improper system process created at boot time. A remote, unauthenticated adversary could exploit this by sending crafted HTTP requests, allowing them to bypass authentication and execute script files or commands to obtain root access to the underlying operating system. The vulnerability has been designated CVE-2026-20079 and has been rated critical with a CVSS score of 10.0.
• The Cisco FMC web-based management interface contains a remote code execution (RCE) vulnerability due to insecure deserialization of a user-supplied Java byte stream. A remote, unauthenticated adversary could exploit this by sending a crafted serialized Java object to the interface, allowing them to execute arbitrary code and elevate privileges to root. Note: Deployments where the management interface lacks public Internet access significantly reduce the associated attack surface. The vulnerability has been designated CVE-2026-20131 and has been rated critical with a CVSS score of 10.0.

There is evidence that CVE-2026-20131 is being actively exploited in the wild.

The following versions of Cisco FMC are affected by one or both vulnerabilities

• Cisco FMC versions prior to 7.0.9
• Cisco FMC versions prior to 7.2.11
• Cisco FMC versions prior to 7.4.4 (CVE-2026-20079) and prior to 7.4.6 (CVE-2026-20131)
• Cisco FMC versions prior to 7.6.4 (CVE-2026-20079) and prior to 7.6.5 (CVE-2026-20131)
• Cisco FMC versions prior to 7.7.12
• Cisco FMC versions prior to 10.0.1 (CVE-2026-20131 only)

What is Cisco Secure Firewall Management Center?

Cisco Secure Firewall Management Center (FMC) is a centralized administrative platform used to configure security policies, manage firmware updates, and aggregate threat telemetry across physical and virtual Cisco security appliances from a single interface.

What is the impact?

Successful exploitation of these vulnerabilities would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• Cisco FMC 6.4.0.13 through 6.4.0.18 upgrade to version 7.0.9 and later
• Cisco FMC 7.0.x upgrade to version 7.0.9 and later
• Cisco FMC 7.1.x through 7.2.x upgrade to version 7.2.11 and later
• Cisco FMC 7.3.x through 7.4.x upgrade to version 7.4.6 and later
• Cisco FMC 7.6.x upgrade to version 7.6.5 and later
• Cisco FMC 7.7.x upgrade to version 7.7.12 and later
• Cisco FMC 10.0.0 upgrade to version 10.0.1 and later

How to find potentially vulnerable systems with runZero

From the Asset Inventory, use the following query to locate potentially impacted assets:

os:="Cisco FMC%" AND os_version:>0 AND
  ((os_version:>="6.4.0.13" AND os_version:<="6.4.0.18") OR
  (os_version:>="7.0.0" AND os_version:<"7.0.9") OR
  (os_version:>="7.1.0" AND os_version:<"7.2.11") OR
  (os_version:>="7.3.0" AND os_version:<"7.4.6") OR
  (os_version:>="7.6.0" AND os_version:<"7.6.5") OR
  (os_version:>="7.7.0" AND os_version:<"7.7.12") OR
  (os_version:="10.0.0"))

A vulnerability found within CraftCMS was published in a recent security advisory.

• A privilege escalation vulnerability exists due to token mishandling.The vulnerability has been designated CVE-2026-32267 and rated high with a CVSS score of 7.7.

The following versions are affected

• CraftCMS versions 4.0.0-RC1 up to 4.17.6 (exclusive)
• CraftCMS versions 5.0.0-RC1 up to 5.9.12 (exclusive)

What is Craft CMS?

CraftCMS is a flexible content management system (CMS) used to build and manage websites.

What is the impact?

Successful exploitation of the vulnerability could allow a low-privilege user (or an unauthenticated user who has been sent a shared URL) to escalate their privileges to admin by abusing a vulnerability found in the user management

Are updates available?

Upgrade affected versions of CraftCMS to the latest patched version.

• CraftCMS 4.x upgrade to version 4.17.6 and later
• CraftCMS 5.x upgrade to version 5.9.12 and later

How do I find potentially vulnerable instances with runZero?

From the Software Inventory, use the following query to locate systems running potentially vulnerable software:

vendor:=CraftCMS AND product:="Craft CMS"

April 2025: CVE-2025-32432 and CVE-2024-58136

Two zero-day vulnerabilities impacting Craft CMS are being actively exploited by chaining the vulnerabilities together to compromise the affected systems.

• CVE-2025-32432 is rated critical with a CVSSv3 base score of 10.0.
• CVE-2024-58136 is rated critical with a CVSSv3 base score of 9.0. This vulnerability is found within the Yii framework, which is used by Craft CMS.

What is the impact?

Successful exploitation of the vulnerability could allow a low-privilege user (or an unauthenticated user who has been sent a shared URL) to escalate their privileges to admin by abusing a vulnerability found in the user management 

Are updates available?

Although the Yii framework update is not included in the latest Craft CMS patch, the primary vulnerability was patched within 3.9.15, 4.14.15, and 5.6.17. Users are strongly encouraged to update their installation as soon as possible. In addition to applying a patch, users might want to rotate their security keys as a safety precaution. Additionally, a best practices write-up is available online with steps on how to harden the security of the installation.

How do I find potentially vulnerable instances with runZero?

From the Service Inventory, use the following query to locate systems running potentially vulnerable software:

_asset.protocol:http AND protocol:http AND (has:http.head.xPoweredBy AND http.head.xPoweredBy:="Craft CMS")

February 2025: CVE-2025-23209

In late January, CraftCMS published a security advisory for a code injection vulnerability that can lead to remote code execution. On February 20, 2025 CISA added CVE-2025-23209 to the known exploited vulnerabilities catalog (KEV).

What is the impact?

Successful exploitation of the vulnerability requires that a remote attacker already has control of the installation's security key. In this case, the attacker can then inject code using an specially crafted backup directory variable provided by the user.

The affected versions include:

• Versions greater than or equal to 5.0.0-RC1 through 5.5.5 (exclusive)

• Versions greater than or equal to 4.0.0-RC1 through 4.13.8 (exclusive)

Are updates available?

The vulnerability was patched in 5.5.8 and 4.13.8. Users are strongly encouraged to update their installation as soon as possible. In addition to applying a patch, users might want to rotate their security keys as a safety precaution. Additionally, a best practices write-up is available online with steps on how to harden the security of the installation.

How do I find potentially vulnerable instances with runZero?

From the Service Inventory, use the following query to locate systems running potentially vulnerable software:

_asset.protocol:http AND protocol:http AND (has:http.head.xPoweredBy AND http.head.xPoweredBy:="Craft CMS")

Adiel Sol reported a GNU Inetutils telnetd buffer overflow vulnerability within its handling of the LINEMODE suboption SLC (Set Local Characters). This flaw occurs during option negotiation, before a login prompt is even presented. A remote, unauthenticated adversary can achieve pre-authentication remote code execution (RCE) by sending a specially crafted SLC suboption containing an excessive number of triplets. Because the telnetd service frequently runs with root privileges, exploitation can lead to a full system compromise. No CVE has been assigned to this vulnerability at this time (March 13, 2026).

Update: The vulnerability has been designated CVE-2026-32746 and has been rated critical with a CVSS score of 9.8.

The following versions are affected:

• GNU Inetutils telnetd all versions up to and including 2.7

What is GNU Inetutils telnetd?

GNU Inetutils (inet-utils) is a collection of common network programs and servers, most frequently deployed on Linux-based systems. The GNU Inetutils telnetd daemon provides a server for the Telnet protocol. While Telnet is a legacy remote-access protocol that has been largely supplanted by SSH, it remains widely used in low-power and legacy environments.

What is the impact?

Successful exploitation of these vulnerabilities would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

A patched version of telnetd has not yet been released. It is strongly recommended to disable the telnetd service on all potentially vulnerable systems.

How to find potentially vulnerable systems with runZero

From the Service Inventory, use the following query to locate systems running potentially vulnerable software:

_asset.protocol:=telnet AND protocol:=telnet AND os:Linux AND banner:="%login:"
  AND NOT (type:device OR type:"ip camera" OR type:"ip phone" OR banner:busybox)

This query is focused on Linux devices utilizing GNU telnetd. However, please note that results may include other Linux-hosted Telnet services that are not necessarily vulnerable to this specific flaw.

January 2026: CVE-2026-24061

Simon Josefsson has reported a vulnerability in the the GNU inet-utils telnetd server. GNU inet-utils (InetUtils) is a collection of Internet-related servers and utilities. It is most commonly deployed on Linux systems.

GNU telnetd contains an authentication bypass vulnerability in its handling of user-supplied environment variables. A specially crafted $USER environment variable can bypass authentication and allow a remote, unauthenticated attacker to access a vulnerable system with the privileges of any known user, including root.

This vulnerability has been assigned CVE-2026-24061 and has a CVSS score of 9.8 (extremely critical).

The following versions are affected

• GNU inet-utils telnetd versions 1.9.3 and higher

What is telnetd?

GNU inet-utils telnetd provides a server for the standard Telnet protocol. Telnet is a legacy remote-access protocol similar that has been largely supplanted by SSH and other, more secure, protocols. However, Telnet is still widely used in low-power or legacy devices.

What is the impact?

Successful exploitation of this vulnerability would allow an adversary to bypass authentication on a vulnerable host.

Are updates or workarounds available?

There is currently no patched version available. Users are advised to disable telnet access if possible, and to ensure proper network access controls are in place.

How to find potentially vulnerable systems with runZero

From the Asset inventory, use the following query to locate potentially vulnerable assets:

_asset.protocol:=telnet AND protocol:=telnet AND os:Linux AND banner:="%login:" AND NOT banner:busybox

Note that this query will locate many Telnet services running on Linux hosts; GNU inet-utils telnetd is one of the most common Telnet servers deployed on Linux systems, but this query may discover other Telnet servers as well.

Veeam Software disclosed in two advisories that multiple vulnerabilities have been identified in Veeam Backup & Replication which could allow for remote code execution (RCE), privilege escalation, and credential theft.

Version 12.3.x Vulnerabilities

• CVE-2026-21666 & CVE-2026-21667: Allows a remote, low-privileged authenticated domain user to perform RCE on the Backup Server. The vulnerabilities designated CVE-2026-21666 and CVE-2026-21667 have been rated critical with a CVSS score of 9.9.
• CVE-2026-21668: Allows a remote, low-privileged authenticated domain user to bypass restrictions and manipulate arbitrary files on a Backup Repository. This vulnerability has been designated CVE-2026-21668 and has been rated high with a CVSS score of 8.8.

Version 13.0.x Vulnerabilities

• CVE-2026-21669: Allows a remote, low-privileged authenticated domain user to perform RCE on Windows-based Backup Servers. This vulnerability has been designated CVE-2026-21669 and has been rated critical with a CVSS score of 9.9.
• CVE-2026-21670: Allows a remote, low-privileged user to extract saved SSH credentials from Windows-based servers or the Veeam Software Appliance. This vulnerability has been designated CVE-2026-21670 and has been rated high with a CVSS score of 7.7.
• CVE-2026-21671: Allows a remote, high-privileged user with the "Backup Administrator" role to perform RCE in high availability (HA) deployments. This vulnerability has been designated CVE-2026-21671 and has been rated critical with a CVSS score of 9.1.

Vulnerabilities Affecting Both 12.3.x and 13.0.x

• CVE-2026-21672: A vulnerability allowing local privilege escalation on Windows-based Backup Servers. This vulnerability has been designated CVE-2026-21672 and has been rated high with a CVSS score of 8.8.
• CVE-2026-21708: Allows a remote, low-privileged user with the "Backup Viewer" role to perform RCE as the postgres user. This vulnerability has been designated CVE-2026-21708 and has been rated critical with a CVSS score of 9.9.

The following versions are affected:

• Veeam Backup & Replication versions 12.3.x prior to 12.3.2.4465
• Veeam Backup & Replication versions 13.0.x prior to 13.0.1.2067

What is Veeam Backup & Replication?

Veeam Backup & Replication is data protection software that supports image-level backup, recovery, and replication for virtual, physical, and cloud machines.

What is the impact?

Successful exploitation of these vulnerabilities would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• Veeam Backup & Replication versions 12.3.x upgrade to version 12.3.2.4465 or later
• Veeam Backup & Replication versions 13.0.x upgrade to version 13.0.1.2067 or later

How to find potentially vulnerable systems with runZero

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:=Veeam AND (product:="Backup & Replication" OR product:="Veeam Backup & Replication")

November 2025: CVE-2025-48983, and CVE-2025-48984

Veeam Software has disclosed two remote code execution (RCE) vulnerabilities affecting certain versions of Veeam Backup & Replication. These flaws in different software components allow a remote, low-privileged adversary (authenticated domain user) to execute arbitrary code.

• The first method is via a vulnerability in the Mount service on domain-joined backup infrastructure servers. This vulnerability has been designated CVE-2025-48983 and has been rated critical with a CVSS score of 9.9.
• The second method is via a vulnerability in domain-joined backup servers. This vulnerability has been designated CVE-2025-48984 and has been rated critical with a CVSS score of 9.9.

The following versions are affected:

• Veeam Backup & Replication versions 12.x prior to 12.3.2.4165

What is Veeam Backup & Replication?

Veeam Backup & Replication is data protection software that supports image-level backup, recovery, and replication for virtual, physical, and cloud machines.

What is the impact?

Successful exploitation of these vulnerabilities would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• Veeam Backup & Replication versions 12.x upgrade to version 12.3.2.4165 or later

How to find potentially vulnerable systems with runZero

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:=Veeam AND product:="Veeam Backup & Replication" AND (version:>0 AND version:>=12 AND version:<12.3.2.4165)

Currently, runZero prebuilt integrations can identify these findings.

December 2024:

Veeam has disclosed two vulnerabilities found internally within their Veeam Service Provider Console (VSPC).

• CVE-2024-42448 is rated Critical with a CVSS score of 9.9, which potentially allows remote code execution.
• CVE-2024-42449 is rated High with a CVSS score of 7.1, which potentially leaks the NTLM hash of a service account and allows for the deletion of files on the server.

What is the impact?

Although there an no known exploitations of the vulnerabilities in the wild, CVE-2024-42448 could allow remote code execution by an attacker on the server. An attacker would need to launch their attack from an authorized VSPC management agent server in order to exploit either of the disclosed vulnerabilities.

Are updates or workarounds available?

No mitigations are available for the disclosed vulnerabilities. Instead, the vendor is strongly encouraging customers to "update to the latest cumulative patch".

How to find potentially vulnerable systems with runZero

From the Service Inventory, use the following query to locate systems running potentially vulnerable software:

has:"html.title" html.title:"Veeam Service Provider Console"

December 2022

Veeam published information on two vulnerabilities in the Veeam Backup & Replication product, originally reported by Nikita Petrov of Positive Technologies.

As of December 16th, CISA had announced the addition of two critical vulnerabilities (tracked as CVE-2022-26500 and CVE-2022-26501) to the KEV catalog. These CVEs were actively being exploited, putting systems at risk. It was critical that these systems were updated to patch these vulnerabilities as soon as possible.

Which versions were affected?

These vulnerabilities affected Backup & Replication versions 9.5, 10, and 11, allowing for exploitation by attackers to achieve unauthenticated remote code execution via the Veeam Distribution Service API. Details on the vulnerabilities (identified as CVE-2022-26500 and CVE-2022-26501) were not published at the time of writing, though Veeam had assigned a "critical" CVSS score of 9.8.

Were updates made available?

Patched releases of Veeam Backup & Replication were made available (see the "Solution" section). Guidance from Veeam was for administrators to update to these newer versions as soon as possible. If near-term updating was not possible, Veeam offered a temporary mitigation strategy via stopping-and-disabling the Veeam Distribution Service (see the "Solution->Notes" section).

How runZero users found potentially vulnerable Veeam instances

We added the default port (9380) for the Veeam Distribution Service API to our runZero Explorer and Scanner. If you were using Explorer or Scanner v2.11.5 or later, you just needed to ensure you had performed a recent scan of your assets prior to running the query below. If you were using an older Explorer or Scanner, users simply added port 9380 to the "Included TCP ports" (under the Advanced tab) and then ran a scan to gather the necessary data.

From the Asset Inventory, users ran the following pre-built query to locate Veeam Distribution Service instances within their network that could have potentially ran vulnerable versions of Veeam Backup & Replication:

tcp_port:9380

As always, any prebuilt queries we create are available from our Queries Library. Check out the library for other useful inventory queries.

Cisco disclosed certain versions of Cisco Catalyst SD-WAN Controller (formerly vSmart) and Cisco Catalyst SD-WAN Manager (formerly vManage) contain a vulnerability in the peering authentication mechanism. A remote, unauthenticated adversary could exploit this by sending crafted requests to an affected system to bypass authentication and obtain administrative privileges. By leveraging an internal, high-privileged, non-root user account, the adversary could access NETCONF, enabling them to manipulate the network configuration for the entire SD-WAN fabric. The vulnerability has been designated CVE-2026-20127 and has been rated critical with a CVSS score of 10.0.

There is evidence that this vulnerability is being actively exploited in the wild.

On March 11, 2026, CISA published V1: ED 26-03: Mitigate Vulnerabilities in Cisco SD-WAN Systems. This version supersedes the actions outlined in the original February 25 directive, introducing updated remediation steps and new reporting requirements for affected organizations.

The following deployment environments are affected

• On-Premise deployments
• Cisco Hosted SD-WAN Cloud (Standard, Cisco Managed, and FedRAMP)

The following versions are affected

• Catalyst SD-WAN releases prior to 20.9
• Catalyst SD-WAN release 20.9 versions prior to 20.9.8.2
• Catalyst SD-WAN release 20.11 versions prior to 20.12.6.1
• Catalyst SD-WAN release 20.12.5 versions prior to 20.12.5.3
• Catalyst SD-WAN release 20.12.6 versions prior to 20.12.6.1
• Catalyst SD-WAN release 20.13 versions prior to 20.15.4.2
• Catalyst SD-WAN release 20.14 versions prior to 20.15.4.2
• Catalyst SD-WAN release 20.15 versions prior to 20.15.4.2
• Catalyst SD-WAN release 20.16 versions prior to 20.18.2.1
• Catalyst SD-WAN release 20.18 versions prior to 20.18.2.1

What is Cisco Catalyst SD-WAN Controller and Manager?

The Cisco Catalyst SD-WAN Controller serves as the centralized control-plane element, utilizing the Overlay Management Protocol (OMP) to manage routing intelligence, distribute security keys, and enforce network-wide policies. In contrast, the Cisco Catalyst SD-WAN Manager acts as the centralized management system, providing the graphical interface necessary for the configuration, monitoring, and orchestration of all devices within the fabric.

What is the impact?

Successful exploitation of the vulnerability would allow an adversary to obtain administrative privileges manipulate the network configuration for the entire SD-WAN fabric.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• Catalyst SD-WAN releases prior to 20.9 migrate to a fixed release
• Catalyst SD-WAN release 20.9 upgrade to version 20.9.8.2 and later
• Catalyst SD-WAN release 20.11 upgrade to version 20.12.6.1 and later
• Catalyst SD-WAN release 20.12.5 upgrade to version 20.12.5.3 and later
• Catalyst SD-WAN release 20.12.6 upgrade to version 20.12.6.1 and later
• Catalyst SD-WAN release 20.13 upgrade to version 20.15.4.2 and later
• Catalyst SD-WAN release 20.14 upgrade to version 20.15.4.2 and later
• Catalyst SD-WAN release 20.14 upgrade to version 20.15.4.2 and later
• Catalyst SD-WAN release 20.16 upgrade to version 20.18.2.1 and later
• Catalyst SD-WAN release 20.18 upgrade to version 20.18.2.1 and later

How to find potentially vulnerable systems with runZero

From the Asset Inventory, use the following query to locate potentially impacted assets:

hw:="Cisco vManage" OR os:="Cisco Viptela OS"

Note: The query locates Cisco Catalyst SD-WAN Manager installations.

HPE disclosed multiple vulnerabilities in specific versions of AOS-CX software:

• An authentication bypass in the web-based management interface allows unauthenticated admin password reset. Successful exploitation could allow a remote, unauthenticated adversary to circumvent existing authentication controls and, in some instances, reset the administrator password. The vulnerability has been designated CVE-2026-23813 and has been rated critical with a CVSS score of 9.8.
• An authenticated command injection vulnerability exists due to improper validation of parameters to a certain AOS-CX CLI command. Successful exploitation could allow a remote, low-privilege adversary to inject malicious commands resulting in unwanted behavior. The vulnerability has been designated CVE-2026-23814 and has been rated high with a CVSS score of 8.8.
• An authenticated command injection vulnerability exists in a custom binary used in AOS-CX CLI for an administrative command. Successful exploitation could allow a remote, high-privilege adversary to perform command injection and execute unauthorized commands. The vulnerability has been designated CVE-2026-23815 and has been rated high with a CVSS score of 7.2.
• An authenticated OS command injection vulnerability exists in an administrative AOS-CX CLI command. Successful exploitation could allow a remote, high-privilege adversary to execute arbitrary commands directly on the underlying operating system. The vulnerability has been designated CVE-2026-23816 and has been rated high with a CVSS score of 7.2.
• An unauthenticated open redirect vulnerability exists in the web-based management interface. Successful exploitation could allow a remote, unauthenticated adversary to redirect users to arbitrary, potentially malicious URLs. The vulnerability has been designated CVE-2026-23817 and has been rated medium with a CVSS score of 6.5.

The following versions are affected

• AOS-CX 10.10.xxxx versions prior to 10.10.1180
• AOS-CX 10.13.xxxx versions prior to 10.13.1161
• AOS-CX 10.16.xxxx versions prior to 10.16.1030
• AOS-CX 10.17.xxxx versions prior to 10.17.1001

What is HPE Aruba Networking AOS-CX?

HPE Aruba Networking AOS-CX is a network operating system built on a modular Linux architecture that utilizes a state-database design and REST APIs to enable automated configuration and embedded system-level visibility.

What is the impact?

Successful exploitation of the vulnerabilities allows an adversary to bypass authentication controls and potentially execute arbitrary commands on the underlying operating system of the vulnerable device.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• AOS-CX 10.10.xxxx upgrade to version 10.10.1180 and later
• AOS-CX 10.13.xxxx upgrade to version 10.13.1161 and later
• AOS-CX 10.16.xxxx upgrade to version 10.16.1030 and later
• AOS-CX 10.17.xxxx upgrade to version 10.17.1001 and later

How to find potentially vulnerable systems with runZero

From the Asset Inventory, use the following query to locate potentially impacted assets:

hw:="HPE Aruba CX%" AND protocol:http

Gogs has disclosed that certain versions are affected by a cross-repository Large File Storage (LFS) object overwrite vulnerability due to missing content hash verification. Git LFS is an open-source extension designed to manage large files, such as audio samples, videos, and datasets, more efficiently within Git repositories. Because Gogs stores all LFS objects in a single location without repository isolation, this flaw could allow a remote, unauthenticated adversary to overwrite existing objects. The vulnerability has been designated CVE-2026-25921 and has been rated critical with a CVSS score of 9.3.

The following versions are affected

• Gogs versions prior to 0.14.2

What is Gogs?

Gogs is an open-source, self-hosted Git repository management system written in Go that provides a web-based interface for version control with minimal hardware resource requirements.

What is the impact?

Successful exploitation of the vulnerability enables an adversary to overwrite legitimate LFS objects with malicious content. This introduces a significant risk of a supply-chain attack; because the Gogs web interface does not present integrity warnings, users may unknowingly download and utilize compromised assets.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• Gogs upgrade to version 0.14.2 or later

How to find potentially vulnerable systems with runZero

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:=Gogs AND product:=Gogs

December 2025: CVE-2025-8110

Security researchers at Wiz have reported a 0-day vulnerability in Gogs. This flaw allows remote, authenticated attackers to overwrite arbitrary files on the vulnerable system. Successful exploitation of this vulnerability would allow an attacker to execute arbitrary code on the vulnerable system with the privileges of the Gogs server process.

This vulnerability has been assigned CVE-2025-8110 and has a CVSS score of 7.8.

Note that there is evidence that this vulnerability is being actively exploited in the wild.

The following versions are affected

• Gogs versions 0.13.3 and prior

What is Gogs?

Gogs is a self-hosted Git software forge, allowing users to collaborate on development using Git repositories.

What is the impact?

Successful exploitation of these vulnerabilities would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

There is currently no patched fixed version of Gogs available. Users are encouraged to disable auto-registration of users and avoid Internet exposure for any Gogs installations.

How to find potentially vulnerable systems with runZero

From the Service inventory, use the following query to locate potentially vulnerable assets:

_asset.protocol:=http AND protocol:=http AND favicon.ico.image.md5:=5f5b7539f014b9996959f5dcd063d383

Well, we’ve gone and made it even easier with a new Findings tab, right in the console. Down with typey-typing, and up with clicky-clicking! 

Check it out:

For those who missed the earlier posts, BOD 26-02 is CISA’s two-year program requiring federal civilian agencies to identify and address unsupported edge devices like firewalls, VPNs, routers, proxies, etc. The clock started ticking on February 5th which means the first milestone of having a mechanism in place to identify all edge devices (supported and unsupported) in production begins on May 5, 2026.

One wrinkle worth noting is that unlike BOD 22-01 and the KEV, CISA decided to keep their official EOL edge device list private. This Finding maps directly to the query we shared last time, surfacing devices in “EOL Extended” state that are exposed to the public internet and aren’t normal servers, desktops, or laptops.

With this update — free to all customers, even the free-trial folks — runZero users can enjoy a consistent, obvious way to track against what CISA (and we) believe are some of the most critically exposed assets on your network. Going forward, we’ll continue to make things easy and clear for you with this Findings tab as we integrate more fingerprints and profiles of commonly-attacked endpoints, so you can get down to the business of upgrading, retiring, or segmenting off these attractive-to-attackers assets.

Nginx UI disclosed that certain versions of Nginx UI are affected by a vulnerability that allows for unauthenticated backup data downloads and the disclosure of associated encryption keys. This flaw stems from missing authentication on the /api/backup endpoint. Additionally, the AES-256 encryption key and IV (Initialization Vector) required to decrypt the backup are transmitted in plaintext within the X-Backup-Security response header. The vulnerability has been designated CVE-2026-27944 and has been rated critical with a CVSS score of 9.8.

The following versions are affected

• Nginx UI all versions prior to 2.3.3

What is Nginx UI?

Nginx UI is a web-based graphical interface used to manage Nginx server configurations, SSL certificates, and system logs without manual command-line editing.

What is the impact?

Successful exploitation of the vulnerability enables a remote, unauthenticated adversary to download and decrypt a full system backup containing sensitive information, such as user credentials, session tokens, SSL private keys, and Nginx configurations.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• Nginx UI upgrade to version 2.3.3 and later

How to find potentially vulnerable systems with runZero

From the Service Inventory, use the following query to locate systems running potentially vulnerable software:

_asset.protocol:=http AND protocol:=http AND favicon.ico.image.mmh3:="-1565173320"

Juniper Networks disclosed certain versions of Junos OS Evolved on PTX series routers contain a vulnerability in the On-Box Anomaly Detection framework. A remote, unauthenticated adversary could exploit this by sending crafted requests to an affected system to bypass authentication and execute code with root access. The vulnerability has been designated CVE-2026-21902 and has been rated critical with a CVSS score of 9.8.

The following versions are affected

• Junos OS Evolved on PTX Series versions 25.4 through 25.4R1-S1-EVO
• Junos OS Evolved on PTX Series versions prior to 25.4R2-EVO

What is Junos OS Evolved?

Junos OS Evolved is a next generation network operating system made by Juniper Networks that power many of their high-end routing and data center platforms.

What is the impact?

Successful exploitation of the vulnerability could allow an adversary the ability to remotely execute code as the root user. This would allow them to take complete control of the device.

Are updates or workarounds available?

Administrators are encouraged to update to the latest version as soon as possible. Additionally, administrators can disable the affected service on vulnerable devices using the following:

request pfe anomalies disable

How to find potentially vulnerable systems with runZero

From the Service Inventory, use the following query to locate potentially impacted assets:

os:="Juniper Junos OS Evolved" AND   
  ((os_version:>="25.4R1-EVO" AND os_version:<"25.4R1-S1-EVO") OR   
  (os_version:>"25.4R1-S1-EVO" AND os_version:<"25.4R2-EVO"))

Note: The query locates all potentially vulnerable Junos OS Evolved installations. However, it does not specifically identify PTX Series routers.

Attackers exploit edge device zero-days, abuse forgotten cellular backup links, and pivot through multi-homed systems that quietly route around every control you've deployed. The tools most teams rely on, including passive monitoring, vulnerability scanners, and OEM software, consistently miss the exposure paths that matter most.

In his presentation, Segmentation Theater, HD breaks down how to address these gaps. Below, we’ve highlighted several key failure modes and what you can do about them. 

The thing protecting your OT environment is also the thing attackers walk through first

Firewalls are the load-bearing wall of OT segmentation. They show up at every Purdue level, and they work…right up until they don't. Mandiant looked back at a full year of OT incident response and found that roughly 30% of those incidents started with initial access through a perimeter security device. Palo Alto, Ivanti, Fortinet, the products we've spent years deploying to protect these environments, were the top three compromised entry points. The attackers aren't looking for some exotic OT-specific exploit. They're using a Fortinet zero-day and walking right in.

The structural problem here is that when you deploy a single firewall vendor from your enterprise zone all the way down to Level 2, you haven't built defense in depth, you've built a single control that spans everything. An authentication bypass at the top collapses the whole stack. Layering vendors helps, but it doesn't solve the underlying issue, which is that firewalls have become both the most critical and the most attacked component in OT networks simultaneously. They need to be treated like assets you actively monitor, not infrastructure you set and forget.

Your devices are routing between zones you're trying to keep separate

A device that has two network connections, a wired OT segment and guest Wi-Fi for example, can route traffic between them without a single packet ever touching your firewall. No alert. No log entry. Just quiet, invisible bridging.

We did research on how many devices have IP forwarding enabled by default and the honest answer is: most of them, including printers, smart TVs, and ESP32-based IoT hardware. We had a harder time finding devices that didn't have it on than ones that did. The situation gets worse when developers install tools like Docker on workstations that sit on OT-adjacent segments. Docker enables IP forwarding across all interfaces as a side effect of its virtual networking. The developer doesn't know they've just turned their workstation into a multi-interface router. Nobody told them that was a firewall configuration problem they now own.

At scale, these unintended connections compound fast. In a network of 30 devices the path graph is already messy. In an enterprise with thousands of employees and dozens of OT sites, you've effectively got one big hairball where any point can reach any other in a hop or two.

The least-secure thing on your network is often the thing managing everything else

Serial console servers, KVM-over-IP switches, and IPMI interfaces are everywhere in OT environments. They exist because you need a way to get remote access to hardware that can't otherwise be managed remotely. They're also consistently the worst-secured devices in the building. Across MOXA, Digi, Pi KVM, SuperMicro IPMI, runZero has found unauthenticated session access, insecure proprietary protocols, and hardcoded credentials. These are consumer-grade bugs sitting directly in front of hardened industrial equipment.

SuperMicro IPMI is a good example of how slowly this problem moves. California passed a law requiring device manufacturers to ship with unique passwords instead of hardcoded defaults. SuperMicro now ships with a password derived from your device serial number. Progress. They also still ship with IPMI and RAKP enabled by default, which is enough for an attacker to dump and crack credentials remotely without any exploitation at all. The attacker doesn't need to go after your hardened server. They go after the KVM attached to its serial port, and they're in.

IPv6 is already on your network & you're probably not watching it

A quick count on a modern laptop turns up 28 active network interfaces, the majority of them IPv6. This is normal. What's not normal is that most teams are only writing firewall rules for IPv4. A device with solid IPv4 filtering and no equivalent IPv6 rules may be exposing databases, fileshares, and credential stores to anyone on the same subnet through its IPv6 address, an address nobody is scanning for, and that doesn't show up in any normal monitoring.

Recently, a customer using runZero was flagged for having a device with a public IP. The customer looked at it and said, that's impossible and that they knew every public IP on this network. It was a packet capture server which was supposed to be completely internal. It had a global IPv6 address assigned by the upstream ISP router that nobody had ever noticed. The device was globally reachable in a way the customer had no visibility into whatsoever. This is not an unusual story. Shodan has indexed over 200 million IPv6 addresses, partly by running NTP servers that quietly log the source address of anything that syncs to them. Your OT devices might already be in there.

So what can you do? It goes beyond monitoring

Passive monitoring alone won't catch any of this. Span port captures don't see traffic that bypasses your choke points. They don't find multi-homed devices. They don't surface link-local IPv6 paths. Vulnerability scanners will tell you whether your firmware is out of date but they won't tell you whether your network is bridged in ways it shouldn't be.

This is the problem runZero was built to solve. We use safe, active scanning designed specifically for fragile OT environments to query devices and have them report back everything: all interfaces, all IP addresses, IPv4 and IPv6, secondary NICs, VPN adapters, cellular connections. We cross-reference internal fingerprints against our internet-wide scan data so you can find out if something internal is externally reachable without having to start from the internet side. We find the bridges, the unexpected management interfaces, the IPv6 exposure, the out-of-band hardware that's been forgotten in a rack somewhere.

The point isn't that these problems are unfixable. It's that you can't fix what you can't see. The first step is knowing what's actually on your network, not the diagram version, the real one.

Book a demo to see how runZero can help in your environment, or begin your free trial here.

Working solely with Enterprise customers at runZero, the topic of “how can we effectively and accurately discover all the assets in our attack surface” comes up quite frequently. At this scale, security teams must balance availability, segmentation, and performance while defending against increasingly sophisticated threats. Asset visibility, continuous discovery, and attack surface monitoring become even more pertinent the larger the environment is.

In this guide, we’ll walk through how to optimize runZero for large-scale deployments using a hypothetical retail enterprise example.

Ex. scenario: global retail enterprise with six hour scan window

Let’s discuss a hypothetical scenario where runZero is working with a large retail provider called ACME Corp and they want to achieve a six hour scan window for their whole infrastructure. This large retail has different brands they manage each with their own datacenter, stores, distribution centers and corporate offices. To add complexity, these brands use overlapping private IP ranges (e.g., multiple business units using 192.168.10.0/24) because they function as semi-independent entities.

Let’s dive into how runZero offers the flexibility and options to perform effective and accurate discovery of the retail provider’s total attack surface.

Establishing the ground rules: Sites and IP organization

First thing will be setting the foundation of IP address organization, since the brands are using overlapping IP addresses and they are distinct entities, we will leverage the concept of Sites in runZero. Sites allows enterprises to organize their data and each runZero Site is a unique view of the entire IP address space.

While many organizations use Sites to segment by geography, they are equally effective for:

• Business unit separation
• Brand isolation
• Temporary environments
• One-off testing

For ACME Corp, the best practice would be:

• Create one runZero Site per brand
• Upload subnet allocations per Site
• Apply structured tagging for reporting, dashboards, and queries

This approach ensures that overlapping IP ranges do not collide in reporting or discovery results.

Assuming here that runZero Explorers have already been deployed to the network, the next phase is to explore the plethora of configuration options available from runZero to customize the active scans.

runZero provides several key controls that directly influence scan speed and network impact. Adjusting these settings impacts performance in terms of Explorer availability, network traffic load, and scan completion times.

Performance tuning (scan speed)

To ensure scans complete within their scheduled frequency without overwhelming the network, runZero provides several performance tuning options. The most direct way to reduce scan time is to increase the rate at which probes are sent. Increasing the scan speed (specially for IT/IoT environments that don't have fragile devices) and dividing up the scan scope will reduce the time to cover the network scanning.

Scan Speed (Packets Per Second): The default scan rate is 1,000 packets per second. For large, robust networks (e.g., data centers or high-speed corporate LANs), increasing this significantly (e.g., 10,000+ pps) to reduce the completion time. A rate of 1,000 packets per second is standard, while 10,000+ is available for large, fast networks. However, higher speeds increase the load on the network and may cause congestion on slower links.Note: The approximate formula for scan time is `hosts × ports × attempts ÷ scan speed`. Increasing the packet rate directly decreases the duration.

Max Group Size: This setting determines how many IP addresses are scanned simultaneously. Increasing this (default is 4,096) allows for higher concurrency, which is essential for utilizing high packet rates effectively. Reducing this number lowers the concurrency of connections, which helps prevent crashing stateful devices like firewalls and routers that have limited session tables. In enterprise environments with high-capacity infrastructure, raising this value often improves efficiency.

Max Host Rate: This limits the packets sent to a single host per second. While the default is conservative (40 pps) to protect fragile devices, increasing this for known robust segments can marginally speed up the scan of individual assets. This limits the packets sent to a single host per second. Lowering this is critical when scanning fragile IoT or OT environments to prevent device instability.

Scan frequency options

runZero allows users to configure scans to run based on specific temporal requirements:

Scheduled and Recurring Tasks: Scans can be set to run once at a specific future date or on a recurring basis. Recurring options include standard intervals (such as daily, weekly, or monthly) as well as more granular options like "Every N Hours" or specific multiples of minutes...

Continuous Scanning: For organizations requiring near real-time visibility, runZero supports continuous recurring scans. These scans run back-to-back; as soon as one scan completes, the next begins. It is important to note that an Explorer running a continuous scan will not be able to run additional tasks unless its concurrency setting is increased beyond the default of 1.

Impact on performance and resources

Adjusting the frequency and speed of scans directly affects the load on the network and the Explorer.

Important considerations:

• Windows Explorers are limited to a single concurrent scan task due to raw packet driver limitations. If a continuous scan is running, other tasks (such as integrations or on-demand scans) may be queued or blocked.
• Linux/macOS Explorers can perform multiple tasks simultaneously. runZero recommends keeping concurrent tasks between 1 and 4 to manage system resources effectively.

Scheduling Grace Period: To prevent scan failures caused by busy Explorers, users can configure a "scheduling grace period." This defines how long a task will wait for an available Explorer before timing out (e.g., if an Explorer is busy with a previous scan in a high-frequency schedule).

This is critical in high-frequency or distributed scan strategies.

Optimization for large IP spaces

Large CIDRs such as /16 or /8 ranges can significantly increase scan time — especially when sparsely populated. To address this, runZero offers two powerful optimization methods called Prescan Modes:

Subnet Sampling: This feature speeds up discovery by sending a small number of probes to a subnet to determine if it is active before launching a full scan. This significantly reduces the time required to scan large, sparse network ranges (e.g., /16 or /8), allowing for more frequent discovery cycles. Enabling the option "Only scan subnets with active hosts" This runs a pre-scan phase where runZero samples a percentage of a subnet (default 3%). If no assets respond, the subnet is skipped entirely. This dramatically reduces wasted time in unused address space and is essential for scanning massive environments within strict windows.

Host Ping: Enabling "Limit scans to pingable hosts", in this mode, runZero first checks if a host responds to ICMP, TCP, or UDP pings. If it does not respond, the system skips the full deep-dive scan for that specific IP. This drastically reduces time but may miss assets that block pings.

This setting should be evaluated based on security tolerance and network policy.

Enforcing the window

To ensure we are adhering to the six hour window, runZero provides a hard limit configuration.

Scan Duration Limit: A maximum duration (in hours) can be specified for a scan task. If the scan is still running after six hours, runZero will automatically cancel the task. This ensures scan activity never bleeds outside the provided six hour maintenance window.

Distributed scanning (Explorer Groups)

A single Explorer scanning a global enterprise is often a bottleneck.

Explorer Groups: Explorers can be deployed and organized into an "Explorer Group" and when assigned the scan task to a group, the platform distributes the workload among the available Explorers in that group. This allows parallelization of the scanning effort to fit within the six hour window.

For ACME Corp:

• Deploy Explorers per data center or region
• Group them by brand or geography
• Run scans in parallel across Sites

This is often the most impactful method for achieving aggressive scan windows.

Concurrent Scans: If Linux or macOS Explorers are used, they can be configured to run multiple scan tasks simultaneously (Windows Explorers are limited to one concurrent scan). This is helpful to break a large network into multiple smaller sites and schedule them to run at the same time.

Scope management

Exclusions: Some subnets create disproportionate delays and If there are specific subnets known to be slow (e.g., legacy networks) or that contain "tarpits" (firewalls that respond slowly to every probe), adding them to the Excluded hosts list will prevent them from consuming disproportionate amounts of time.

Adding these to the Excluded Hosts list prevents them from consuming excessive time during global scans.

This allows prioritization of high-value segments while isolating problematic areas for separate tuning.

Summary: Checklist for achieving a six hour global scan

As a summary, to meet a strict enterprise-wide window:

✔ Deploy multiple Explorers and use Explorer Groups

✔ Segment environments using Sites

✔ Enable Subnet Sampling for large ranges

✔ Increase scan speed where infrastructure permits

✔ Adjust Max Group Size and Host Rate per segment

✔ Configure a six hour Scan Duration Limit

✔ Exclude known bottlenecks

Final Thoughts

Large global enterprises do not fail at asset discovery due to scale and complexity but because of tool limitations and operational constraints.

runZero’s flexibility in segmentation, distributed scanning, prescan optimization, and performance tuning allows security architects to design discovery programs that are both comprehensive and operationally safe.

When configured strategically, even the most complex retail or global enterprise network can achieve accurate, repeatable asset visibility — within a defined and predictable time window.

Start a free trial or request a demo today to see firsthand how runZero can bring clarity to your most complex environments and turn visibility into your greatest security advantage.

A vulnerability has been disclosed in Roundcube Webmail stable versions from 1.5 prior to 1.5.10, and stable versions 1.6 prior to 1.6.11 that would allow a remote, authenticated attacker to perform remote code execution (RCE) due to deserialization of untrusted data. The _from parameter in a URL is not validated in program/actions/settings/upload.php, resulting in untrusted PHP Object Deserialization. This vulnerability has existed within the product for approximately 10 years.

This vulnerability has been designated CVE-2025-49113 and has a CVSS score of 9.9 (critical).

There is evidence that this vulnerability is being actively exploited in the wild.

What is the impact?

Successful exploitation of this vulnerability would allow an attacker to execute arbitrary code on the vulnerable system, potentially leading to complete system compromise.

Are any updates or workarounds available?

Roundcube has released updates to mitigate this issue. Users are encouraged to update to the latest stable version as quickly as possible.

• For Roundcube Webmail stable version 1.5, update to version 1.5.10 or later.
• For Roundcube Webmail stable version 1.6, update to version 1.6.11 or later.

How do I find Roundcube Webmail installations with runZero?

From the Service Inventory, use the following query to locate potentially impacted assets:

_asset.protocol:http AND protocol:http AND ((has:html.title AND html.title:="RoundCube%") OR (has:favicon.ico.image.md5 AND (favicon.ico.image.md5:="924a68d347c80d0e502157e83812bb23" OR favicon.ico.image.md5:="f1ac749564d5ba793550ec6bdc472e7c" OR favicon.ico.image.md5:="ef9c0362bf20a086bb7c2e8ea346b9f0")))

Security researchers at Rapid7 reported a stack-based buffer overflow vulnerability in the HTTP API endpoint /cgi-bin/api.values.get. Successful exploitation could allow a remote, unauthenticated adversary achieve remote code execution (RCE) with root privileges on the phone. The vulnerability has been designated CVE-2026-2329 and has been rated critical with a CVSS score of 9.3.

The following models and versions are affected

• GXP1610, GXP1615, GXP1620, GXP1625, GXP1628, and GXP1630 firmware versions prior to 1.0.7.81

What are Grandstream GXP1600 Series VoIP Phones?

The Grandstream GXP1600 series is a collection of entry-level, Linux-based Voice over Internet Protocol (VoIP) phones used for making and receiving voice calls over a network via the Session Initiation Protocol (SIP).

What is the impact?

Successful exploitation of the vulnerability would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• GXP1610, GXP1615, GXP1620, GXP1625, GXP1628, and GXP1630 upgrade to firmware version 1.0.7.81 or later

How to find potentially vulnerable systems with runZero

From the Asset Inventory, use the following query to locate potentially impacted assets:

hw:="Grandstream GXP16__" AND (os_version:>0 AND os_version:<"1.0.7.81")

At first, we were all very excited about this BOD. It reads a whole lot like BOD 22-01, which is the binding operational directive that spawned the KEV, which is one of the most useful, free-to-use vulnerability intelligence resources the US Government has ever produced (of course, only if you use it correctly).

Alas, CISA has decided to make their list of identified EOL edge devices private, rather than blasting it out to the world. This is a real bummer, but it really does highlight how special the CISA KEV really is. As a former federal employee, I am here to tell you that when it comes to civilian government (and most other large enterprises), the default stance is to keep your mouth shut. Even in the best of times, cybersecurity people are often stingy with any scrap of intelligence, lest you accidentally inform the enemy on what's up with your infrastructure, and the federal government, doubly so.

I do expect that the list that CISA is compelled to produce in the BOD will get out regardless, since they've already committed to share it privately with state, local, tribal, and territorial governments (SLTT) and critical infrastructure providers (CI), but it won't be published in a formal or referenceable (or remixable or collidable) as the KEV.

Find EOL/EOS devices with one simple query

But in the meantime, we wanted to let runZero customers know how you can approximate the spirit, if not the letter, of what BOD 26-02 is after. It comes down to a fairly straightforward asset query:

os_eol_extended:<=now AND has_public:t AND NOT (type:Server OR type:Desktop OR type:Laptop)

What this does is go over your already-collected inventory and looks for those devices that are a) in "EOL Extended" state, which is runZero's tag for those devices that are so end-of-life/end-of-service they will never see another security fix, b) exposed to the internet, and c) isn't a normal server, desktop or laptop.

Now, excluding (c) there is a little bit dubious – you probably also don't want EOS stuff that people are actually using to type email and surf the web, all naked and exposed to the wild and woolly internet – but this gets you to a place where you can seek out all those "devices" discussed on BOD 26-02, like so:

(This is a particularly dirty network, and yours is certainly not this awful, but you get the idea.)

At any rate, we'll be fiddling with this over the next couple of weeks, and have a pretty self-contained single push-button thing to get you ahead of any BOD 26-02 worries, much like how we do with Section 889 compliance. And if you don't already know about Section 889… the feds certainly do, so you probably should too.

Try runZero now!

Dell disclosed certain versions of Dell RecoverPoint for Virtual Machines (RP4VMs) contain a hardcoded credential vulnerability. Successful exploitation could allow a remote, unauthenticated adversary with knowledge of the hardcoded credential to gain unauthorized access to the underlying operating system and achieve root-level persistence. The vulnerability has been designated CVE-2026-22769 and has been rated critical with a CVSS score of 10.0.

There is evidence that this vulnerability is being actively exploited in the wild.

The following versions are affected

• RecoverPoint for Virtual Machines versions prior to 6.0.3.1 HF1

What is Dell RecoverPoint for Virtual Machines?

Dell RecoverPoint for Virtual Machines is a software-based orchestration tool that provides continuous data protection for VMware environments by capturing and replicating hypervisor-level write operations to a journal, allowing a VM to be rolled back to any specific point in time.

What is the impact?

Successful exploitation of the vulnerabilities would allow an adversary to gain unauthorized access to the underlying operating system and achieve root-level persistence.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• RecoverPoint for Virtual Machines upgrade to version 6.0.3.1 HF1 and later

If an immediate upgrade is not feasible, apply the remediation script for DSA-2026-079 as soon as possible to mitigate risk.

How to find potentially vulnerable systems with runZero

From the Asset Inventory, use the following query to locate potentially impacted assets:

hw:="RecoverPoint for Virtual Machines" OR os:="EMC RecoverPoint" OR hw:="EMC RecoverPoint"

SolarWinds has disclosed multiple vulnerabilities affecting certain versions of Web Help Desk (WHD).

• An untrusted data deserialization vulnerability that could lead to remote code execution (RCE) designated CVE-2025-40551 and has been rated critical with a CVSS score of 9.8. Successful exploitation allows a remote, unauthenticated adversary to execute arbitrary code on the host machine. There is evidence that this vulnerability is being actively exploited in the wild.
• An authentication bypass vulnerability designated CVE-2025-40552 and has been rated critical with a CVSS score of 9.8. A remote, unauthenticated adversary could exploit this to trigger actions and methods that should otherwise be restricted.
• An untrusted data deserialization vulnerability that could lead to RCE designated CVE-2025-40553 and has been rated critical with a CVSS score of 9.8. Successful exploitation allows a remote, unauthenticated adversary to execute arbitrary code on the host machine.
• An authentication bypass vulnerability designated CVE-2025-40554 and has been rated critical with a CVSS score of 9.8. A remote, unauthenticated adversary could exploit this to invoke specific actions within Web Help Desk.
• A security control bypass vulnerability designated CVE-2025-40536 and has been rated high with a CVSS score of 8.1. Successful exploitation allows a remote, unauthenticated adversary to gain access to certain restricted functionality. There is evidence that this vulnerability is being actively exploited in the wild.

The following versions are affected

• SolarWinds Web Help Desk versions prior to 12.8.8 Hotfix 1 (HF1)

What is SolarWinds Web Help Desk?

SolarWinds Web Help Desk is an on-premises IT service management (ITSM) software that automates help desk ticketing, asset tracking, and change management through a centralized, self-hosted platform.

What is the impact?

Successful exploitation of the vulnerability would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• SolarWinds Web Help Desk upgrade to version 12.8.8 Hotfix 1 (HF1) or later

How to find potentially vulnerable systems with runZero

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:=SolarWinds AND product:="Web Help Desk"

September 2025: CVE-2025-26399

SolarWinds has disclosed a deserialization of untrusted data vulnerability in the AjaxProxy component of its Web Help Desk (WHD). Successful exploitation allows a remote, unauthenticated adversary to achieve remote code execution (RCE) on the host machine. This vulnerability has been designated CVE-2025-26399 and has been rated critical with a CVSS score of 9.8. This vulnerability bypasses the patch for CVE-2024-28988, which in turn was an incomplete fix for the original vulnerability, CVE-2024-28986.

There is evidence that this vulnerability is being actively exploited in the wild.

The following versions are affected

• SolarWinds Web Help Desk versions prior to 12.8.7 Hotfix 1 (HF1)

What is the impact?

Successful exploitation of the vulnerability would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• SolarWinds Web Help Desk upgrade to version 12.8.7 Hotfix 1 (HF1) or later

How to find potentially vulnerable systems with runZero

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:=SolarWinds AND (product:="Web Help Desk" OR product:="webhelpdesk") AND (version:>0 AND version:<12.8.7.2174)

October 2024: CVE-2024-28987

According to the US Cybersecurity and Infrastructure Security Agency (CISA), a critical hardcoded password vulnerability within SolarWinds' Web Help Desk software is actively being exploited and was added to their Known Exploited Vulnerability (KEV) catalog. 

• CVE-2024-28987 is rated critical with CVSS score of 9.1 allowing for unauthorized access by a remote attacker.

What is the impact?

A remote attacker has the ability to log in to a vulnerable system using hardcoded credentials, providing access to internal information with the ability to modify the data.

Are updates or workarounds available?

According to the security advisory issued by SolarWinds, systems running "WHD 12.8.3 HF1 and all previous versions" of the Web Help Desk software are affected. Organizations are recommended to manually apply the hot fix released by SolarWinds to remove the hardcoded credentials from the software.

How to find potentially vulnerable systems with runZero

From the Service Inventory, use the following query to locate systems running potentially vulnerable software:

_service.product:="SolarWinds:Web Help Desk:"

That's the gap our new tool, KEV Collider, fills. This is our daily-updated web application that lets you layer signals, test filters, and watch how different risk indicators interact across the catalog in real time. No installation. No credentials. Just open it and start experimenting.

What you can actually do with it

The KEV Collider is designed to help you figure out what’s most important for your organization and your team by making the data interrogatable. Here's what that looks like in practice.

Filter for your infrastructure

Every environment has its own risk profile. Maybe you care about network-accessible vulnerabilities that require no user interaction. Or maybe you need to identify everything Microsoft released on Patch Tuesday that's since appeared on the KEV. 

KEV Collider allows you to filter across:

• CVSS metrics: Attack vector, privileges required, user interaction, impact scores

• KEV metadata: Date added, date due, vendor, product, ransomware usage

• EPSS signals: Current probability, trending direction, magnitude of change

• Exploit availability: Public “commodity” exploits vs targeted, private exploitation

Want to see only straight-shot remote code execution vulnerabilities? There's a preset for that. Need to track EPSS vulnerabilities where exploitation probability is actively shifting? Filter for it.

Test signal combinations, not just individual scores

One of the KEV Collider's core design principles is that single metrics don't tell the whole story. A high CVSS score without active exploitation is different from a moderate score that's trending on EPSS. A KEV entry added last month behaves differently than one added this week, even if both have the same due date.

The tool makes these combinations visible. For example, maybe you want to look at just Microsoft vulnerabilities, cross-referenced against reported ransomware campaign usage, and really only those rated as a CVSS “High” or worse, then sort what’s left by the KEV due date rather than the KEV add date. Here’s a sample filter for just that, all through the magic of HTTP GET parameters. The goal is to surface patterns that only emerge when you look at multiple signals together.

Understand timing

When a vulnerability appears on the KEV matters as much as whether it appears at all. The KEV Collider tracks:

• Date added to the KEV

• Date due under BOD 22-01

• Day of the week it was added (useful for spotting Patch Tuesdays or unusual Friday to Sunday additions)

• EPSS momentum: whether exploitation probability is increasing, decreasing, or stable, as of today.

This temporal context helps distinguish between commoditized mass exploitation and newly emerging threats. A vulnerability added to the KEV three months ago with stable EPSS tells a different operational story than one added yesterday with a sharp EPSS spike.

Three ways to start using KEV Collider today

1. Run the presets, then modify them

Start with one of the built-in presets and see what they return. Then adjust the filters to reflect your own priorities. The presets are hypothesis starters, not final answers.

2. Compare vendor behavior

Filter by specific vendors and watch how their KEV entries cluster. Do certain vendors show up disproportionately on particular days? Do their vulnerabilities trend differently on EPSS? These patterns can inform patching cadence and vendor risk assessments.

3. Test your assumptions

Think high CVSS scores correlate perfectly with KEV urgency? Filter for CVSS 9+ and sort by date due. Believe all network-accessible RCE is equally critical? Layer in EPSS to see which ones are actually being exploited at scale. The tool is designed to challenge conventional wisdom by letting you measure it.

Built to help empower defenders like you

The KEV Collider is a community resource. It's hosted by runZero, updated daily, and built entirely on open-source data. There's no paywall, no required sign-up, and no attempt to prescribe priorities. We're releasing it because defenders need tools that support thoughtful, repeatable reasoning, not just checkbox coverage.

Compliance-driven patching treats every KEV entry the same because regulations can't accommodate nuance. But operational security requires exactly that: distinguishing signal from noise, urgency from ceremony, and real risk from theoretical possibility.

Where it fits in your workflow

The KEV Collider doesn't replace your vulnerability management platform or patching process. It's a layer above those tools, offering a place to validate assumptions, explore signal combinations, and test prioritization hypotheses before translating them into operational decisions.

Use KEV Collider to:

• Audit whether your current patching priorities align with actual threat behavior

• Identify blind spots in your vulnerability triage process

• Build evidence-based arguments for resource allocation

• Train your team to think critically about risk signals instead of treating scores as gospel

The CISA KEV is an operational signal, not a static list. The KEV Collider treats it that way.

Get started

Explore the KEV Collider. For the research foundation behind it, read our new KEVology report. And if you want to see how KEV entries map to your actual asset inventory, try runZero for free.

BeyondTrust disclosed a pre-authentication remote code execution (RCE) vulnerability affecting certain versions of both Remote Support (RS) and Privileged Remote Access (PRA). This flaw is triggered via specially crafted client requests sent to the appliance. Successful exploitation could allow a remote, unauthenticated adversary to execute arbitrary operating system commands in the context of the site user, potentially leading to full system compromise. The vulnerability has been designated CVE-2026-1731 and has been rated critical with a CVSS score of 9.9.

There is evidence that this vulnerability is being actively exploited in the wild.

The following versions are affected

• Remote Support (RS) versions 25.3.1 and prior
• Privileged Remote Access (PRA) versions 24.3.4 and prior

What are BeyondTrust Remote Support, and Privileged Remote Access?

BeyondTrust Remote Support (RS) is an enterprise platform designed for help desks to securely access and troubleshoot end-user devices or mobile platforms across any network without a VPN.

BeyondTrust Privileged Remote Access (PRA) is a zero-trust security solution providing vendors and internal admins with granular, audited access to critical infrastructure without granting full network visibility.

What is the impact?

Successful exploitation of the vulnerability would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• Remote Support (RS) versions 21.3 and older upgrade to a newer version to apply patch BT26-02-RS
• Remote Support (RS) versions 25.3.1 and prior upgrade to version 25.3.2 and later
• Privileged Remote Access (PRA) versions 22.1 and older upgrade to a newer version to apply patch BT26-02-PRA
• Privileged Remote Access (PRA) versions 24.3.4 and prior upgrade to version 25.1.1 and later

How to find potentially vulnerable systems with runZero

From the Services Inventory, use the following query to locate potentially impacted assets:

_asset.protocol:=http AND protocol:=http AND
  (product:="BeyondTrust Remote Support" OR
  product:="Beyond Trust Remote Support" OR
  product:="BeyondTrust BeyondTrust Remote Support" OR
  product:="BeyondTrust Privileged Remote Access")
  AND _service.product:beyondtrust

January 2025: CVE-2024-12356

BeyondTrust disclosed that affects their Privileged Remote Access (PRA) and Remote Support (RS) appliances. This has also been added to the CISA KEV as it has been exploited in the wild.

• CVE-2024-12356 is rated highly-critical with a CVSS score of 9.8. Successful exploitation of this vulnerability would allow an attacker execute arbitrary commands on the appliance.

What is the impact?

The issue impacts PRA and RS versions 24.3.1 and earlier.

Are updates or workarounds available?

BeyondTrust has released a patch for all supported iterations of PRA and RS versions 22.1.x and higher and has applied the patch to cloud customers earlier this week.

How do I find potentially vulnerable systems with runZero?

From the Services Inventory, use the following query to locate systems running potentially vulnerable software:

vendor:BeyondTrust or http.body:BeyondTrust

From the Assets Inventory, use the following query to locate systems running potentially vulnerable software:

os:BeyondTrust OR hw:BeyondTrust OR os:Bomgar OR hw:Bomgar

For context, a Binding Operational Directive (BOD) is a “compulsory direction to federal, executive branch, departments and agencies for purposes of safeguarding federal information and information systems.” ¹  While BODs do not apply to certain agencies whose systems are classified as national security systems (NSS), they do apply to all federal civilian executive branch agencies.

What is BOD 26-02?

BOD 26-02 mandates a two-year program requiring all affected agencies to identify and address unsupported edge devices, effective February 5, 2026.

• All federal agencies under CISA’s authorities must immediately update all supported edge devices.

• In three months (May 5, 2026), federal agencies must identify those devices in production listed on the “CISA EOS Edge Device List.” These agencies must also have a mechanism in place to identify all supported and unsupported edge devices in production, regardless of CISA’s list.

• In a year (Feb 5, 2027), all devices on CISA’s list of unsupported devices should be updated or replaced by all federal agencies.

• In 18 months (August 5, 2027), all unsupported edge devices must be updated or replaced by all federal agencies, regardless if they’re on CISA’s list or not.

• In two years (Feb 5, 2028), all federal agencies must have a continuous mechanism to identify all edge devices, and ensure that only supported devices are in production.

While BOD 26-02 specifically calls out the risk of having EOS edge devices on a network, CISA states that “EOS devices should not reside anywhere on federal networks.” Here at runZero, we couldn’t agree more! But, for the purposes of BOD 26-02, “edge devices” are often, but not limited to, devices such as firewalls, switches, routers, load-balancers, proxies, reverse proxies, VPN gateways, or combinations thereof. Interestingly, security vendors products whose devices often live at the edge were the most frequently exploited devices in 2024. Unsupported devices, no matter where they exist in an organization, pose a significant risk to organizations.

We go into this in some depth in our recent report, "Undead by Design, Benchmarking end-of-life operating systems," where we concentrate specifically on operating systems and their prevalence across industry sectors, and more importantly, why unsupported systems linger for so long in production.

BOD 26-02 compliance challenges

When it comes detecting and discovering unsupported edge devices, two main challenges arise almost immediately:

1. Accurate discovery and fingerprinting of EOS devices

2. Defining the Edge

The first challenge, accurate discovery and fingerprinting of EOS devices, has been traditionally solved via manually managed Excel spreadsheets, IPAM, or not at all. That is to say, having and maintaining an accurate and up to date asset inventory has traditionally been a collection of disjointed systems, programs, or procedures, leading to an incomplete and inaccurate list of what's on the network, starting from the moment that list is produced. This spotty and laggy coverage makes it difficult to impossible to identify with accuracy anything on the network, let alone unsupported devices.

This takes us to our second challenge of defining the edge. Oftentimes, organizations think they know where their perimeter lies, but shadow IT, network misconfigurations, and wandering “bring your own devices” (BYODs) all can extend the perimeter beyond what was known. This exposure of unknown devices, supported or otherwise, represents a real risk to agencies that are often under constant attack from adversaries looking to steal, disrupt, or destroy US infrastructure. 

How runZero supports BOD 26-02

Accurately and expediently discovering assets can be a daunting task, especially if you don't know where to start. runZero can help agencies discover all of their assets, validate the edge, and identify EOL and EOS devices, before the adversaries do. With runZero, agencies can:

1. Discover all assets

Through novel unauthenticated active scanning, passive discovery, and API integrations, runZero can identify, fingerprint, and report on your entire systems risk and exposure, including aging, unmaintained, and forgotten EOS devices.

2. Identify all edge assets (supported or otherwise)

runZero can scan both internally and externally, providing agencies a comprehensive view of the internal and external attack surfaces. Utilizing native reporting, agencies can validate their edge devices, including EOS devices.

3. Native EOL asset discovery

runZero includes native alerting capabilities when EOL devices are discovered:' or 'runZero includes a native alerting capability when EOL devices are discovered:

If there are devices that runZero cannot track support for, Government off-the-shelf (GOTS) or classified devices for example, custom queries allow agencies to build and track their own inventories:

These queries can then be tracked on a simple dashboard, allowing for easy access to offending assets.

4. Goals for tracking

runZero queries can also be used to build custom Goals, so progress can be tracked toward BOD compliance.

What’s next for your BOD 26-02 strategy

runZero’s unparalleled asset discovery and fingerprinting can empower agencies to expeditiously discover and maintain an asset inventory for their entire systems. Even more immediately, runZero can help agencies accomplish the requirements of BOD 26-02 before the milestones laid out by CISA. 

Start a free trial in minutes or book a demo for a guided tour.

Some teams treat KEV like a compliance punch list: a fixed set of “things to patch,” universally urgent, universally applicable. But that isn’t what KEV is. It’s an operational signal—produced under real constraints, reflecting real exploitation, and designed to drive action in a very specific context.

Two new KEV resources, now live!

Today, we’re releasing two new resources that approach KEV the way defenders actually have to work: by reasoning under uncertainty, mixing imperfect signals, and making defensible decisions when time and coverage are limited.

KEVology: how exploits, scores, and timelines intersect on the CISA KEV

A new report by Tod Beardsley, former CISA Section Chief for the KEV, analyzing how KEV entries behave across exploits, scores, and timelines, and what actually matters in real environments.

🧪 Read the report ➜

KEV Collider

A community-first web application and dataset that lets you smash together risk and threat signals and measure what falls out—so you can explore, validate, and adapt the analysis to your own operational reality.

🚀 Launch KEV Collider ➜

The uncomfortable truth about KEV

The starting point for both resources is a simple but uncomfortable truth: the KEV is not a list of “the worst vulnerabilities ever,” and it was never meant to be treated as one. KEV is a constrained catalog shaped by explicit criteria and real-world tradeoffs. Every entry reflects observed exploitation—but not every entry carries the same urgency, impact, or relevance for every environment.

That distinction matters because most vulnerability teams aren’t operating under a single mandate or timeline. Outside of strict BOD 22-01 compliance, treating every KEV as equal quickly collapses under operational scrutiny. Teams have limited patching windows, uneven asset visibility, and competing priorities that can’t be resolved by a single score or list.

KEVology takes this problem seriously by treating KEV as data rather than doctrine. Instead of asking whether KEV entries are “important” in the abstract, the report examines how they behave in practice. We explore how commodity exploitation, scoring systems, and timelines interact over time, and where those interactions produce clarity or confusion for defenders. The goal isn’t to undermine KEV, but to make its signal more usable by everyone, inside and outside the US federal government.

Why no single metric can prioritize risk

One of the report’s core conclusions is that no single metric can do prioritization for you. CVSS describes potential impact, not likelihood. EPSS models probability, but not exposure. SSVC adds decision framing, but can’t know your environment. Even “exploit exists” is a blunt signal without context. What actually supports better decisions is the combination of signals, especially when you pay attention to when things happen, not just what happens.

That’s where our new KEV Collider tool comes in.

From analysis to experimentation

The KEV Collider is designed as a companion to the report: a place to test assumptions rather than accept conclusions. Developed and hosted by runZero, it’s a daily-updated web application built on open-source data that layers the CISA KEV catalog with the enrichment an investigator needs to distinguish between theoretical risk and real-world fire drills. Instead of prescribing priorities, it lets you explore how different signals combine and how those combinations change the story you tell about risk.

Together, KEVology and KEV Collider turn KEV analysis into a controlled and shareable experiment. They’re meant to help teams move beyond checkbox coverage and toward evidence-based reasoning, where prioritization is treated honestly and transparently, as a hypothesis about the world that must be tested, defended, and revised over time.

Start with the report. Then take it into the lab.

If you want to understand what the KEV is actually telling you, start with the report, then take the analysis into the lab with the KEV Collider. The KEV will keep evolving. The best way to keep up is to interrogate vulnerabilities with the same rigor attackers apply to exploiting them.

Want to run a holistic experiment in your own environment? runZero surfaces the asset context you need to do it. Try runZero for free today.

depthfirst has reported a vulnerability in the OpenClaw personal assistant tool. This flaw allows a remote, unauthenticated attacker one-click remote code execution via authentication token exfiltration exposed through a WebSocket. Successful exploitation could allow complete system compromise.

This vulnerability has been assigned CVE-2026-25253 and is rated high has a CVSS score of 8.8.

The following versions are affected

• OpenClaw versions up to but not including 2026.1.29

What is OpenClaw?

OpenClaw is an open-source, autonomous AI personal assistant that runs locally on user devices. It is designed to manage digital tasks by interacting with apps and websites on the user's behalf.

What is the impact?

Successful exploitation of this vulnerability would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

The OpenClaw project has released version 2026.1.29 of OpenClaw. Users are urged to update as quickly as possible.

How to find potentially vulnerable systems with runZero

From the Software inventory, use the following query to locate potentially vulnerable assets:

vendor:=OpenClaw product:=OpenClaw

Rolling out scans at a new site often comes with an uncomfortable unknown. You may have an Explorer deployed, but you still do not know what the backhaul traffic looks like or how reliable the connection really is. In distributed environments, M&A scenarios, or remote locations, these questions often go unanswered until something breaks.

Explorer-based internet speed testing helps remove that uncertainty. By measuring internet connectivity directly from deployed Explorers, runZero gives you an early signal into whether a site’s connection is usable before you rely on it for scanning, data uploads, or ongoing monitoring.

Why internet speed matters before you scan

Internet speed tests do not tell you whether scanning will impact production traffic, but they do answer an important prerequisite question: is the connection itself stable and usable. There are two common scenarios where this matters:

First, when you deploy an Explorer at a remote site, you often plan to scan from that node rather than across a VPN or WAN link. Knowing the quality of the site’s outbound connectivity helps you decide whether that approach is viable or whether you should limit or stage activity differently.

Second, poor connectivity can still impact data uploads back to the console, integration imports, and day-to-day reliability. Identifying weak or unstable links early helps avoid surprises and makes troubleshooting much easier when issues arise later.

How Explorer-based bandwidth testing works

Explorer-based bandwidth internet speed testing allows you to measure internet connectivity directly from the site where the Explorer is installed. This feature uses the well-known speedtest.net infrastructure to find the closest server in order to report bandwidth, latency, and jitter.

You can run a speed test on demand using the “Start speed test” action, which immediately starts an Explorer action that records upload speed, download speed, and latency. This is useful for quick validation during deployment or troubleshooting. Once the test completes, it will show in the table on the Explorer details page, and offer Download actions for even more details on the results of the test.

For ongoing insight, we recommend configuring recurring tests from the Explorer details page. The frequency is set in hours and defaults to zero, meaning no recurring tests run unless you explicitly enable them. We don’t recommend running tests any more frequently than hourly; since repeated speed tests can actually impact available bandwidth. Hourly tests minimize potential disruptions while still giving you detailed performance over time.

Since these tests use the well-known speedtest.net network, the Explorer does require connectivity to the main speedtest.net site as well as any regional speed test nodes. This test process works by querying https://www.speedtest.net/api/js/servers for a list of the closest servers based on the external IP of the Explorer. The Explorer then pings the full server list to find the system with the lowest latency. Finally, the test concludes by performing download and upload bandwidth tests while measuring packet loss, latency, and jitter. If your firewall or proxy blocks the speedtest.net portal or the regional test servers, this process may report an error.

You can run a speed test on demand using the ‘Start speed test’ action; this will schedule a test on the Explorer immediately, and after a minute or so, report the upload speed, download speed, jitter, and latency.

Designed to be safe and low impact

Internet speed testing is intentionally conservative. Tests only run when triggered manually or on the schedule you configure. There is no background activity by default, and no impact unless you choose to enable it. Please note that if you self-host runZero and run in Offline mode, speed tests will be disabled, since they do require internet access. Speed tests may fail if your firewall does not allow arbitrary ICMP and HTTP traffic to speedtest.net portal and the frequently rotating list of regional servers.

If an Explorer is not on a supported version, the UI clearly indicates this and guides you to upgrade directly from the Explorer details page, making it easy to get started without additional setup.

Included with your Explorers

If you already have Explorers deployed, you already have this capability, with no additional licensing or setup required.

Explorer includes built-in bandwidth testing that integrates directly into existing workflows. It gives you a simple way to understand connectivity at your sites, identify unreliable links early, and avoid learning about bandwidth problems after they start causing issues.

From the Explorer details page, you can also download detailed results for recent tests. The JSON formats include extensive metadata, such as the public IP address used and detailed statistics that are not yet surfaced in the UI.

Together, this gives teams not just a speed test result, but a verifiable, automatable record of when tests ran, where they ran, and what they observed.

You can also set column visibility, and table preferences from within the Internet Speed tests page. So, that you can make sure you are seeing what is most important to you, and how you want to view the data within the grid.

Structured speed test event in the audit log

Each completed speed test generates a structured event with metrics like latency, jitter, and throughput that can be used to trigger alerts or automation when connectivity degrades or tests fail.

Run an internet speed test you can verify

Start a free runZero trial to measure site connectivity directly from your Explorers — with full visibility and audit logs included. After the trial period, your account can be converted to our free Community Edition.

As always, we would love your feedback as you use this feature. Let us know how it fits into your deployment and site readiness workflows. Feel free to reach out using the in-product support form or contact the team via support@runzero.com.

Ivanti disclosed two remote code execution (RCE) vulnerabilities affecting certain versions of Ivanti Endpoint Manager Mobile (EPMM). These vulnerabilities, designated CVE-2026-1281 and CVE-2026-1340 have been rated critical with a CVSS score of 9.8. Both are code injection flaws that allow a remote, unauthenticated adversary to execute arbitrary code on the underlying host.

There is evidence that the vulnerability designated CVE-2026-1281 is being actively exploited in the wild.

The following versions are affected:

• Endpoint Manager Mobile versions 12.5.0.x prior to RPM 12.5.0.x
• Endpoint Manager Mobile versions 12.5.1.0 prior to RPM 12.5.1.x
• Endpoint Manager Mobile versions 12.6.0.x prior to RPM 12.6.0.x
• Endpoint Manager Mobile versions 12.6.1.0 prior to RPM 12.6.1.x
• Endpoint Manager Mobile versions 12.7.0.x prior to RPM 12.7.0.x

What is Ivanti Endpoint Manager Mobile?

Ivanti Endpoint Manager Mobile (EPMM) is an on-premises unified endpoint management platform that allows IT administrators to enforce security policies, manage application distribution, and control data access for mobile devices and laptops across an enterprise network.

What is the impact?

Successfully exploiting this vulnerability would allow an attacker to execute arbitrary code with the privileges of the vulnerable process, potentially allowing complete system takeover.

Are updates or workarounds available?

Users are encouraged to update to the latest version as quickly as possible:

• Endpoint Manager Mobile versions 12.5.0.x upgrade to version RPM 12.5.0.x
• Endpoint Manager Mobile versions 12.5.1.0 upgrade to version RPM 12.5.1.x
• Endpoint Manager Mobile versions 12.6.0.x upgrade to version RPM 12.6.0.x
• Endpoint Manager Mobile versions 12.6.1.0 upgrade to version RPM 12.6.1.x
• Endpoint Manager Mobile versions 12.7.0.x upgrade to version RPM 12.7.0.x

How to find potentially vulnerable systems with runZero

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:=Ivanti AND product:="Endpoint Manager Mobile"

May 2025: CVE-2025-4427 and CVE-2025-4428

Ivanti has disclosed multiple vulnerabilities in its Endpoint Manager Mobile (EPMM) product. These vulnerabilities, when chained together and successfully exploited, would allow a remote, unauthenticated attacker to execute arbitrary code on the vulnerable system.

These vulnerabilities, designated CVE-2025-4427 and CVE-2025-4428 have CVSS scores of 5.3 (medium) and 7.2 (high), respectively. However, in combination these vulnerabilities are significantly more critical than their individual scores may imply.

There is evidence that these vulnerabilities are being actively exploited in the wild.

The following versions are affected:

• Ivanti Endpoint Manager Mobile (EPMM) 11.x versions 11.2.0.4 and prior
• Ivanti Endpoint Manager Mobile (EPMM) 12.3.x versions 12.3.0.1 and prior
• Ivanti Endpoint Manager Mobile (EPMM) 12.4.x versions 12.4.0.1 and prior
• Ivanti Endpoint Manager Mobile (EPMM) 12.5.x versions 12.5.0.0 and prior

What is the impact?

Successfully exploiting this vulnerability would allow an attacker to execute arbitrary code with the privileges of the vulnerable process, potentially allowing complete system takeover.

Are any updates or workaround available?

Ivanti has released updates to address this vulnerability, and users are advised to update as quickly as possible.

How do I find potentially vulnerable Ivanti EPMM services with runZero?

From the Asset Inventory use the following query to locate EPMM services on your network:

product:"Ivanti Endpoint Manager Mobile"

July 2023: CVE-2023-35078

On July 24th, Ivanti announced that their Endpoint Manager Mobile (EPMM, formerly MobileIron Core) product versions 11.10 and prior contain a critical authentication bypass vulnerability. Successfully exploiting this vulnerability would allow an unauthenticated remote attacker to access users’ personally identifiable information (PII) and make changes to the vulnerable server.

There is evidence that this vulnerability is being exploited in the wild.

What is the impact?

An unauthenticated remote attacker who successfully exploited this vulnerability would be able to retrieve users’ personally identifiable information (PII) and make changes to the vulnerable server. This is due to an authentication bypass vulnerability, meaning that in some cases an attacker can bypass authentication controls.

With a CVSS score of 10.0, this vulnerability is considered critical. There is evidence that this vulnerability is being exploited in the wild and this vulnerability has been added to the CISA Known Exploited Vulnerabilities catalog.

Are updates available?

Ivanti has released a patch for this vulnerability and issued guidance for customers on how to upgrade.

How do I find potentially vulnerable Ivanti EPMM services with runZero?

EPMM can be found by navigating to the Services Inventory and using the following pre-built query to locate EPMM services on your network:

_asset.protocol:http AND protocol:http AND html.title:"Ivanti User Portal: Sign In"

Starting with runZero 3.10.10, from the Asset Inventory use the following pre-built query to locate EPMM services on your network:

product:”Ivanti Endpoint Manager Mobile”

Results from the above query should be triaged to determine if they require patching. As always, any prebuilt queries are available from your runZero console. Check out the documentation for other useful inventory queries.

Fortinet has issued an advisory detailing authentication bypass vulnerabilities in multiple Fortinet products when configured for Single Sign-On (SSO) via FortiCloud, including FortiAnalyzer, FortiManager, FortiProxy, and other products running FortiOS. Successful exploitation of these vulnerabilities could allow a remote, unauthenticated adversary who possesses a FortiCloud account and a registered device to bypass authentication and log into devices belonging to other accounts, potentially leading to full system compromise. This vulnerability, designated CVE-2026-24858, is rated critical with a base CVSS score of 9.4.

Note that there is evidence that this vulnerability is being actively exploited in the wild.

The following versions are affected:

• FortiAnalyzer 7.0 versions 7.0.0 through 7.0.15
• FortiAnalyzer 7.2 versions 7.2.0 through 7.2.11
• FortiAnalyzer 7.4 versions 7.4.0 through 7.4.9
• FortiAnalyzer 7.6 versions 7.6.0 through 7.6.5
• FortiManager 7.0 versions 7.0.0 through 7.0.15
• FortiManager 7.2 versions 7.2.0 through 7.2.11
• FortiManager 7.4 versions 7.4.0 through 7.4.9
• FortiManager 7.6 versions 7.6.0 through 7.6.5
• FortiOS 7.0 versions 7.0.0 through 7.0.18
• FortiOS 7.2 versions 7.2.0 through 7.2.12
• FortiOS 7.4 versions 7.4.0 through 7.4.10
• FortiOS 7.6 versions 7.6.0 through 7.6.5
• FortiProxy 7.0 all versions 7.0.x
• FortiProxy 7.2 all versions 7.2.x
• FortiProxy 7.4 versions 7.4.0 through 7.4.12
• FortiProxy 7.6 versions 7.6.0 through 7.6.4

What are Fortinet FortiWeb, FortiProxy, FortiSwitchManager, and FortiOS?

Fortinet FortiAnalyzer is a centralized logging and analytics solution that aggregates data from across the security fabric to provide deep visibility, real-time threat detection, and automated compliance reporting.

Fortinet FortiManager is a centralized management platform that provides a single point of control for configuring, deploying, and overseeing security policies across an entire fabric of Fortinet devices.

Fortinet FortiOS is a custom operating system common to many Fortinet products.

Fortinet FortiProxy is a high-performance secure web gateway platform.

What is the impact?

Successful exploitation of the vulnerability would allow a remote unauthenticated adversary to bypass authentication checks for vulnerable systems. This may allow complete compromise of the vulnerable systems.

Are updates or workarounds available?

Fortinet recommends upgrading affected systems to the new versions:

• FortiAnalyzer 7.0 upgrade to version 7.0.16 or later
• FortiAnalyzer 7.2 upgrade to version 7.2.12 or later
• FortiAnalyzer 7.4 upgrade to version 7.4.10 or later
• FortiAnalyzer 7.6 upgrade to version 7.6.6 or later
• FortiManager 7.0 upgrade to version 7.0.16 or later
• FortiManager 7.2 upgrade to version 7.2.13 or later
• FortiManager 7.4 upgrade to version 7.4.10 or later
• FortiManager 7.6 upgrade to version 7.6.6 or later
• FortiOS 7.0 upgrade to version 7.0.19 or later
• FortiOS 7.2 upgrade to version 7.2.13 or later
• FortiOS 7.4 upgrade to version 7.4.11 or later
• FortiOS 7.6 upgrade to version 7.6.6 or later
• FortiProxy 7.0 migrate to a fixed release
• FortiProxy 7.2 migrate to a fixed release
• FortiProxy 7.4 upgrade to version 7.4.13 or later
• FortiProxy 7.6 upgrade to version 7.6.6 or later

How to find potentially vulnerable systems with runZero

From the Asset Inventory, use the following query to locate potentially impacted assets:

os:="Fortinet FortiAnalyzer" OR hw:="Fortinet FortiManager" OR os:="Fortinet FortiProxy" OR
  (os:="Fortinet FortiOS" AND os_version:>0 AND
  ((os_version:>="7.0.0" AND os_version:<="7.0.18") OR
  (os_version:>="7.2.0" AND os_version:<="7.2.12") OR
  (os_version:>="7.4.0" AND os_version:<="7.4.10") OR
  (os_version:>="7.6.0" AND os_version:<="7.6.5")))

January 2026: CVE-2025-25249

Fortinet has issued an advisory describing a buffer overflow vulnerabilities in multiple Fortinet products, including FortiOS, FortiSASE, and FortiSwitchManager. Successful exploitation of these vulnerabilities could allow a remote, unauthenticated adversary to execute arbitrary code.This vulnerability, designated CVE-2025-25249, is rated high with a base CVSS score of 7.4.

The following versions are affected:

• FortiOS 7.6 versions 7.6.0 through 7.6.3
• FortiOS 7.4 versions 7.4.0 through 7.4.8
• FortiOS 7.2 versions 7.2.0 through 7.2.11
• FortiOS 7.0 versions 7.0.0 through 7.0.17
• FortiOS 6.4 versions 6.40 through 6.4.16
• FortiSASE 25.2 versions 25.1.a.2 through 25.2.b
• FortiProxy 7.4 versions 7.4.0 through 7.4.10
• FortiProxy 7.2 versions 7.2.0 through 7.2.14
• FortiProxy 7.0 versions 7.0.0 through 7.0.21
• FortiSwitchManager 7.2 versions 7.2.0 through 7.2.6
• FortiSwitchManager 7.0 versions 7.0.0 through 7.0.5

What are Fortinet FortiOS and FortiSwitchManager?

Fortinet FortiOS is a custom operating system common to many Fortinet products.

Fortinet FortiSwitchManager is a software suite for managing fleets of Fortinet devices.

What is the impact?

Successful exploitation of the vulnerability would allow a remote unauthenticated adversary to execute arbitrary code or commands via specifically crafted requests.

Are updates or workarounds available?

Fortinet recommends upgrading affected systems to the new versions:

• FortiOS 7.6 - Upgrade to 7.6.4 or above
• FortiOS 7.4 - Upgrade to 7.4.9 or above
• FortiOS 7.2 - Upgrade to 7.2.12 or above
• FortiOS 7.0 - Upgrade to 7.0.18 or above
• FortiSASE 25 - Upgrade to 25.2.c
• FortiSwitchManager 7.2 - Upgrade to 7.2.7 or above
• FortiSwitchManager 7.0 - Upgrade to 7.0.6 or above

Fortinet has included workaround guidance.

How to find potentially vulnerable systems with runZero

From the Asset Inventory, use the following query to locate potentially impacted assets:

os:="Fortinet FortiOS" AND
os_version:>0 AND
((os_version:>="7.6.0" AND os_version:<="7.6.3") OR
(os_version:>="7.4.0" AND os_version:<="7.4.8")  OR
(os_version:>="7.2.0" AND os_version:<="7.2.11") OR
(os_version:>="7.0.0" AND os_version:<="7.0.17") OR
(os_version:>="6.4.0" AND os_version:<="6.4.17"))

December 2025: CVE-2025-59718 and CVE-2025-59719 (Multiple)

Fortinet has issued an advisory describing authentication bypass vulnerabilities in multiple Fortinet products, including FortiWeb, FortiProxy, FortiSwitchManager, and other products running FortiOS. Successful exploitation of these vulnerabilities could allow a remote, unauthenticated adversary to bypass authentication on systems when they are configured to use Single Sign-On via FortiCloud. These vulnerabilities, designated CVE-2025-59718 and CVE-2025-59719, are rated critical with a base CVSS score of 9.1.

Note that there is evidence that this vulnerability is being actively exploited in the wild and was added to the CISA KEV list on December 16th, 2025.

The following versions are affected:

• FortiOS 7.6 versions 7.6.0 through 7.6.3
• FortiOS 7.4 versions 7.4.0 through 7.4.8
• FortiOS 7.2 versions 7.2.0 through 7.2.11
• FortiOS 7.0 versions 7.0.0 through 7.0.17
• FortiProxy 7.6 versions 7.6.0 through 7.6.3
• FortiProxy 7.4 versions 7.4.0 through 7.4.10
• FortiProxy 7.2 versions 7.2.0 through 7.2.14
• FortiProxy 7.0 versions 7.0.0 through 7.0.21
• FortiSwitchManager 7.2 versions 7.2.0 through 7.2.6
• FortiSwitchManager 7.0 versions 7.0.0 through 7.0.5
• FortiWeb 8.0 version 8.0.0
• FortiWeb 7.6 versions 7.6.0 through 7.6.4
• FortiWeb 7.4 versions 7.4.0 through 7.4.9

What are Fortinet FortiWeb, FortiProxy, FortiSwitchManager, and FortiOS?

Fortinet FortiWeb is a specialized Web Application Firewall (WAF) that protects web applications and APIs from known and unknown threats by inspecting HTTP traffic and enforcing security policies to block attacks.

Fortinet FortiProxy is a high-performance secure web gateway platform.

Fortinet FortiSwitchManager is a software suite for managing fleets of Fortinet devices.

Fortinet FortiOS is a custom operating system common to many Fortinet products.

What is the impact?

Successful exploitation of the vulnerability would allow a remote unauthenticated adversary to bypass authentication checks for vulnerable systems. This may allow complete compromise of the vulnerable systems.

Are updates or workarounds available?

Fortinet recommends upgrading affected systems to the new versions:

• FortiOS 7.6 - Upgrade to 7.6.4 or above
• FortiOS 7.4 - Upgrade to 7.4.9 or above
• FortiOS 7.2 - Upgrade to 7.2.12 or above
• FortiOS 7.0 - Upgrade to 7.0.18 or above
• FortiProxy 7.6 - Upgrade to 7.6.4 or above
• FortiProxy 7.4 - Upgrade to 7.4.11 or above
• FortiProxy 7.2 - Upgrade to 7.2.15 or above
• FortiProxy 7.0 - Upgrade to 7.0.22 or above
• FortiSwitchManager 7.2 - Upgrade to 7.2.7 or above
• FortiSwitchManager 7.0 - Upgrade to 7.0.6 or above
• FortiWeb 8.0 - 8.0.1 or above
• FortiWeb 7.6 - Upgrade to 7.6.5 or above
• FortiWeb 7.4 - Upgrade to 7.4.10 or above

As a temporary workaround, disabling Single Sign-On via FortiCloud may mitigate this vulnerability.

How to find potentially vulnerable systems with runZero

From the Asset Inventory, use the following query to locate potentially impacted assets:

product:"Fortinet FortiWeb" OR
    (os:="Fortinet FortiOS" AND
    os_version:>0 AND
    ((os_version:>="7.6.0" AND os_version:<="7.6.3") OR
    (os_version:>="7.4.0" AND os_version:<="7.4.8") OR
    (os_version:>="7.2.0" AND os_version:<="7.2.11") OR
    (os_version:>="7.0.0" AND os_version:<="7.0.17")))

October 2025: CVE-2025-49201, CVE-2025-49201

In October 2025, Fortinet disclosed vulnerabilities in certain versions of their FortiSwitch Manager and FortiPAM and products.

August 2025: CVE-2025-52970 (FortiWeb)

Fortinet has issued an advisory for a vulnerability affecting certain versions of their FortiWeb product where the software improperly handles session cookie parameters, resulting in an authentication bypass vulnerability. To exploit this flaw, a remote, unauthenticated adversary must possess specific non-public information about the device and a target user. Successful exploitation allows the adversary to send a specially crafted request and log in as any existing user on the device. The vulnerability, designated CVE-2025-52970, is rated high with a base CVSS score of 7.7.

The following versions are affected

• FortiWeb 7.0 versions 7.0.0 through 7.0.10
• FortiWeb 7.2 versions 7.2.0 through 7.2.10
• FortiWeb 7.4 versions 7.4.0 through 7.4.7
• FortiWeb 7.6 versions 7.6.0 through 7.6.3

What is the impact?

Successful exploitation of the vulnerability would allow a remote unauthenticated adversary to gain administrative access to the system.

Are updates or workarounds available?

Upgrade affected systems to the new versions

• FortiWeb 7.0 upgrade to version 7.0.11 or later
• FortiWeb 7.2 upgrade to version 7.2.11 or later
• FortiWeb 7.4 upgrade to version 7.4.8 or later
• FortiWeb 7.6 upgrade to version 7.6.4 or later

How to find potentially vulnerable systems with runZero

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:=Fortinet AND product:=FortiWeb

August 2025: CVE-2025-25256 (FortiSIEM)

Fortinet has issued an advisory for a vulnerability affecting certain versions of their FortiSIEM product where the software improperly neutralizes special elements used in an OS command, resulting in an OS command injection vulnerability that allows a remote, unauthenticated adversary to execute unauthorized code or commands via crafted CLI requests. The vulnerability, designated CVE-2025-25256, is rated critical with a base CVSS score of 9.8.

There is evidence that this vulnerability is being actively exploited in the wild.

The following versions are affected

• FortiSIEM 5.4 all versions
• FortiSIEM 6.1 all versions
• FortiSIEM 6.2 all versions
• FortiSIEM 6.3 all versions
• FortiSIEM 6.4 all versions
• FortiSIEM 6.5 all versions
• FortiSIEM 6.6 all versions
• FortiSIEM 6.7 versions 6.7.0 through 6.7.9
• FortiSIEM 7.0 versions 7.0.0 through 7.0.3
• FortiSIEM 7.1 versions 7.1.0 through 7.1.7
• FortiSIEM 7.2 versions 7.2.0 through 7.2.5
• FortiSIEM 7.3 versions 7.3.0 through 7.3.1

What is the impact?

Successful exploitation of the vulnerability would allow a remote unauthenticated adversary to execute arbitrary commands on the remote system, potentially including operating system commands with the privileges of the vulnerable process.

Are updates or workarounds available?

Upgrade affected systems to the new versions

• FortiSIEM 5.4 migrate to a fixed release
• FortiSIEM 6.1 migrate to a fixed release
• FortiSIEM 6.2 migrate to a fixed release
• FortiSIEM 6.3 migrate to a fixed release
• FortiSIEM 6.4 migrate to a fixed release
• FortiSIEM 6.5 migrate to a fixed release
• FortiSIEM 6.6 migrate to a fixed release
• FortiSIEM 6.7 upgrade to version 6.7.10 or later
• FortiSIEM 7.0 upgrade to version 7.0.4 or later
• FortiSIEM 7.1 upgrade to version 7.1.8 or later
• FortiSIEM 7.2 upgrade to version 7.2.6 or later
• FortiSIEM 7.3 upgrade to version 7.3.2 or later

How to find potentially vulnerable systems with runZero

From the Software Inventory, use the following query to locate potentially impacted assets:

vendor:="Fortinet" product:="FortiSIEM"

May 2025: (CVE-2025-32756)

Fortinet has issued an advisory for a vulnerability affecting their FortiVoice, FortiMail, FortiNDR, FortiRecorder and FortiCamera products. Note that there is evidence that this vulnerability is actively being exploited in the wild.

The vulnerability, designated CVE-2025-32756, is rated critical with a base CVSS score of 9.8. Successfully exploiting this vulnerability would allow a remote, unauthenticated attacker to execute arbitrary code.

What is the impact?

For affected product versions, a remote unauthenticated attacker may execute arbitrary code or commands. Fortinet has included indicators-of-compromise (IoCs) within the advisory to help determine whether a system has been compromised.

Are updates or workarounds available?

In addition to disabling, or restricting access to the HTTP/HTTPS administrative interface, Fortinet recommends upgrading the following versions of affected products:

• FortiCamera 2.1.0 through 2.1.3 to be upgraded to 2.1.4 or later
• FortiCamera 1.1 and 2.0 to be migrated to a fixed release
• FortiMail 7.6.0 through 7.6.2 to be upgraded to 7.6.3 or later
• FortiMail 7.4.0 through 7.4.4 to be upgraded to 7.4.5 or later
• FortiMail 7.2.0 through 7.2.7 to be upgraded to 7.2.8 or later
• FortiMail 7.0.0 through 7.0.8 to be upgraded to 7.0.9 or later
• FortiNDR 7.6.0 to be upgraded to 7.6.1 or later
• FortiNDR 7.4.0 through 7.4.7 to be upgraded to 7.4.8 or later
• FortiNDR 7.2.0 through 7.2.4 to be upgraded to 7.2.5 or later
• FortiNDR 7.1 to be migrated to a fixed release
• FortiNDR 7.0.0 through 7.0.6 to be upgraded to 7.0.7 or later
• FortiNDR 1.1 through 1.5 to be migrated to a fixed release
• FortiRecorder 7.2.0 through 7.2.3 to be upgraded to 7.2.4 or later
• FortiRecorder 7.0.0 through 7.0.5 to be upgraded to 7.0.6 or later
• FortiRecorder 6.4.0 through 6.4.5 to be upgraded to 6.4.6 or later
• FortiVoice 7.2.0 to be upgraded to 7.2.1 or above
• FortiVoice 7.0.0 through 7.0.6 to be upgraded to 7.0.7 or later
• FortiVoice 6.4.0 through 6.4.10 to be upgraded to 6.4.11 or later

How to find potentially vulnerable systems with runZero

From the Asset Inventory, use the following query to locate systems running potentially vulnerable software:

hw:="Fortinet FortiRecorder" OR hw:="Fortinet FortiNDR" OR hw:="Fortinet FortiMail" OR (hw:"Fortinet" AND type:"SIP Gateway")

How to find potentially vulnerable FortiCamera systems with runZero

From the Service Inventory, use the following query to locate systems running potentially vulnerable software:

hw:"Fortinet" AND _asset.protocol:http AND protocol:http AND (((has:http.head.wwwAuthenticate OR has:last.http.head.wwwAuthenticate) AND http.head.wwwAuthenticate:FortiCamera) OR (has:tls.subject AND tls.subject:FortiCamera))

January 2025: (CVE-2024-55591, CVE-2023-37936)

Fortinet issued an advisory for a vulnerability affecting their FortiOS and FortiProxy products that is actively being exploited in the wild.

• CVE-2024-55591 detailed in FG-IR-24-535 is rated critical with a CVSS score of 9.6 and may allow unauthenticated attacker to gain administrator privileges.

Fortinet also issued an advisory for their FortiSwitch product.

• CVE-2023-37936 detailed in FG-IR-23-260 is rated critical with a CVSS score of 9.6 and may allow unauthenticated attacker to execute arbitrary code.

What is the impact?

For affected versions of FortiOS and FortiProxy vulnerable to CVE-2024-55591, a remote attacker may gain administrator privileges bypassing authentication. Fortinet included IoCs within the advisory.

Due to the use of a hard-coded cryptographic key in vulnerable versions of the FortiSwitch product, an unauthenticated attacker with the key could remotely perform arbitrary code execution. 

Are updates or workarounds available?

In addition to disabling, or restricting access to the HTTP/HTTP administrative interface, Fortinet recommends upgrading the following versions of affected products:

CVE-2024-55591

• FortiOS 7.0.0 through 7.0.16 to be upgraded to 7.0.17 or later
• FortiProxy 7.2.0 through 7.2.12 to be upgraded to 7.2.13 or later
• FortiProxy 7.0.0 through 7.0.19 to be upgraded to 7.0.20 or later

CVE-2023-37936

• FortiSwitch 7.4.0  to be upgraded to 7.4.1 or later
• FortiSwitch 7.2.0 through 7.2.5 to be upgrade to 7.2.6 or later
• FortiSwitch 7.0.0 through 7.0.7 to be upgraded to 7.0.8 or later 
• FortiSwitch 6.4.0 through 6.4.13 to be upgraded to 6.4.14 or later
• FortiSwitch 6.2.0 through 6.2.7 to be upgraded to 6.2.8 or later
• FortiSwicth 6.0.0 through 6.0.7 should be migrated to a fixed release

How to find potentially vulnerable systems with runZero

From the Asset Inventory, use the following query to locate systems running potentially vulnerable software:

os:"FortiOS" OR hw:"FortiSwitch" OR hw:"FortiProxy"

December 2024: (CVE-2023-34990)

Fortinet issued advisories for their FortiWLM product.

• CVE-2023-34990 detailed in FG-IR-23-144 was rated critical with a CVSS score of 9.6 and may have allowed an unauthenticated attacker to read sensitive files.

What was the impact?

An unauthenticated attacker may have been able to manipulate paths through the FortiWLM application and perform a path traversal in order to gain access to sensitive files outside the application root directory on the host machine.

Are updates or workarounds available?

Fortinet recommended upgrading the following versions:

• FortiWLM 8.6.0 through 8.6.5 to be upgraded to 8.6.6 or above
• FortiWLM 8.5.0 through 8.5.4 to be upgrade to 8.5.5 or above

How to find potentially vulnerable systems with runZero

From the Service Inventory, use the following query to locate systems running potentially vulnerable software:

html.title:FortiWLM

October 2024: (CVE-2023-50176, CVE-2024-23666)

Fortinet issued advisories for its FortiAnalyzer, FortiAnalyzer-BigData, FortiManager, and FortiOS products.

• CVE-2023-50176 detailed in FG-IR-23-475 was rated high with a CVSS score of 7.1, and may have allowed an unauthenticated attacker to hijack a user session.
• CVE-2024-23666 detailed in FG-IR-23-396 was rated high with a CVSS score of 7.1 and may have allowed an authenticated, read-only user the ability to execute "sensitive operations".

What was the impact?

CVE-2024-23666, which affected FortiAnalyzer and FortiManager products, required that an attacker (or malicious user) was authenticated against the system. A read-only user could potentially execute sensitive operations through crafted requests, bypassing client-side enforcement through the web interface. CVE-2023-50176, which affected the SSLVPN component of FortiOS, was a session fixation vulnerability that allowed an unauthenticated attacker the ability to hijack an authenticated user's session via a "phishing SAML authentication link".

Are updates or workarounds available?

The vendor released patches for all affected products. They recommended following the upgrade path using their upgrade tool.

How to find potentially vulnerable systems with runZero

From the Asset Inventory, use the following query to locate systems running potentially vulnerable software:

hw:FortiManager OR hw:FortiAnalyzer OR os:FortiOS

March 2024

On March 12th, 2024, Fortinet disclosed several vulnerabilities in their FortiOS, FortiProxy, and FortiClient products:

• FG-IR-23-328 – a buffer overflow vulnerability in the handling of form-based authentication in the FortiOS and FortiProxy captive portals, allowing remote, unauthenticated attackers to execute arbitrary code. This vulnerability has been assigned CVEs CVE-2023-42789 and CVE-2023-42790. These vulnerabilities have a CVSS score of 9.3, indicating that they are critical.

• FG-IR-24-007 – a SQL injection vulnerability in the FortiClient Enterprise Management Server. This vulnerability has been designated CVE-2023-48788, and has been given a CVSS score of 9.8 (critical).

• FG-IR-23-390 – a log injection vulnerability in the FortiClient Enterprise Management Server. This vulnerability has been assigned CVE-2023-47534 and a CVSS score of 7.7 (high).

• FG-IR-23-103 – a remote code execution vulnerability in the FortiManager product. This vulnerability has been designated CVE-2023-36554 with a CVSS score of 7.7 (high). Note that the vulnerable subsystem is not installed by default.

• FG-IR-23-013 – an information disclosure vulnerability in the FortiGuard SSL-VPN product. This vulnerability has been designated CVE-2024-23112 and given a CVSS score of 7.2 (high).

How to find FortiOS, FortiProxy or FortiClient operating systems

From the Asset Inventory, use the following query to locate assets running the FortiOS or FortiProxy operating systems, which may be vulnerable:

os:"FortiOS" OR os:"FortiProxy"

Additionally, from the Services Inventory, use the following query to locate potentially vulnerable systems:

html.title:="FortiClient Endpoint Management Server"

February 2024: (CVE-2024-21762)

On February 8th, 2024, Fortinet disclosed a serious vulnerability in their FortiOS operating system, used by multiple Fortinet products.

The issue, CVE-2024-21762, allowed attackers to execute arbitrary code on vulnerable devices. The vendor has indicated that this is a critical vulnerability. The vendor reports that there are indications that this vulnerability may be actively exploited in the wild. Upon successful exploitation of these vulnerabilities, attackers could execute arbitrary code on the vulnerable system.

Fortinet released an update to mitigate this issue and all users were urged to update immediately. Additionally, the vendor indicated that disabling the SSL-VPN functionality of the device would mitigate the issue.

How to find FortiOS devices

From the Asset Inventory, use the following query to locate assets running the FortiOS operating system which may potentially be vulnerable:

os:"FortiOS" AND tcp:443

October 2022: (CVE-2022-40684)

News surfaced in October 2022 of a critical authentication bypass vulnerability present in the web administration interface of some Fortinet products. Successful exploitation of this vulnerability (tracked as CVE-2022-40684) via crafted HTTP and HTTPS requests could provide remote attackers with admin-level command execution on vulnerable FortiOS devices including FortiGate firewalls, FortiProxy web proxies, and FortiSwitchManager assets.

With a CVSS critical score of 9.6, attackers running admin-level commands on compromised assets may have had the ability to persist presence, explore connected internal networks, and exfiltrate data. At the time Fortinet was aware of at least one exploit of this vulnerability in the wild, and Bleeping Computer offered a Shodan search showing more than 140k publicly accessible FortiGate devices potentially running vulnerable FortiOS. Additionally, security researchers with Horizon3.ai planned on publishing an exploit PoC. For admins wanting to check if a FortiOS/FortiProxy/FortiSwitchManager asset had been exploited, Fortinet provides an indicator of compromise (see the “Exploitation Status” section).

Fortinet called out the vulnerable FortiOS, FortiProxy, and FortiSwitchManager versions in their advisory and had made updates available for affected products. Admins were advised to ensure that affected models were updated to the latest version as soon as possible. If updates could not be completed in the near term, Fortinet provided some mitigation steps (see the “Workaround” section) that could be taken to secure vulnerable assets.

How to find FortiOS, FortiProxy, and FortiSwitchManager assets

From the Asset Inventory, runZero users entered the following pre-built query to locate FortiOS, FortiProxy, and FortiSwitchManager assets:

os:FortiOS or product:FortiProxy or product:FortiSwitchManager

Cisco has reported a vulnerability in their Cisco Unified Communications Manager, Cisco Unified Communications Manager Session Management Edition, Cisco Unified Communications Manager IM & Presence Service, Cisco Unity Connection, and Cisco Dedicated Webex Calling Dedicated Instance products. These are products used to manage telecommunications, voice, video, and telepresence across various devices.

These products contain a vulnerability that would allow a remote, unauthenticated attacker to execute arbitrary commands on the underlying operating system of the device. This could be used to gain complete control over the vulnerable system.

This vulnerability has been assigned CVE-2026-20045 and has a CVSS score of 8.2 (high). Note that while the CVSS score indicates a high ranking, the vendor advisory indicates that this is a critical vulnerability.

The following versions are affected

• Versions 12.5, 14.x, and 15.x of the above products are confirmed vulnerable. Older versions may still be vulnerable.

What are these products?

These products are used to manage telecommunications, voice, video, and telepresence across various devices.

What is the impact?

Successful exploitation of this vulnerability would allow an adversary to execute arbitrary commands on a vulnerable host.

Are updates or workarounds available?

No workarounds are available but Cisco has released patches for vulnerable systems. For users of versions 12.5 or earlier, users are advised they must upgrade to a fixed version. For newer versions, apply the appropriate patches as indicated in the vendor's security advisory.

How to find potentially vulnerable systems with runZero

From the Software inventory, use the following query to locate potentially vulnerable assets:

vendor:=Cisco AND product:="Unified Communications Manager"

What follows is what we’re expecting to see more of in 2026, from OT exposure and exploit noise to vulnerability decision-making, automation risks, and where AI actually, genuinely helps defenders. Taken together, they point to a 2026 shaped less by breakthroughs, and more by how well organizations understand their own changing environments.

As OT exposure increases, ransomware will follow

OT environments are increasingly being managed through IT and cloud platforms for practical reasons: easier management, remote access, and operational efficiency. But that shift means more OT systems are now either directly exposed to the internet or sitting just one hop away from it.

In 2026, we predict ransomware will increasingly target OT and edge systems. Not because attackers have developed new techniques, but because these systems have become much more reachable.

What makes this especially challenging is that many OT environments were never designed with this level of connectivity in mind, and organisations often lack a clear, current understanding of how these systems are exposed.

Attackers scale noise, not capability

Attackers won’t suddenly become more capable in 2026, but they will become much louder. AI is already being used to generate exploit code at scale, and the result is a flood of low-quality output rather than a wave of consistently effective new attacks.

Every headline vulnerability now attracts instant, AI-generated proof-of-concept exploits, often published to GitHub without testing or validation. Most don’t work. Some barely compile. But they still demand attention, forcing defenders to waste time sorting through dozens of broken PoCs to find the handful that are actually relevant.

We expect this dynamic to intensify in 2026. AI gives attackers scale, not precision, and that scale creates noise that bleeds directly into defender workflows. The real cost shows up in time and focus, not breach statistics. Teams that can quickly determine whether a vulnerability or exploit applies to their environment will cope. Teams that can’t will spend 2026 chasing ghosts.

The real vuln problem is actionability, not volume

In 2026, we predict vulnerability management will hinge less on counting CVEs and more on deciding which ones deserve attention at all. Teams that treat every new disclosure as equally urgent will struggle. The bottleneck won’t be finding vulnerabilities: it will be determining which ones matter in a specific environment, and which can safely wait.

To date, there’s no evidence CVE quality is collapsing under the weight of AI. In 2025, around 900 CVEs were rejected, of which roughly 800 were rejected before they were ever published. Only about 100 were published and later withdrawn. That doesn’t point to a system overwhelmed by bad AI output.

What has changed is how difficult it’s become to decide what’s actionable. CVE issuance is now spread across hundreds of CNAs, not concentrated in a single authority, and vulnerability reports arrive with widely varying levels of clarity and usefulness. Some maintainers have already started rejecting AI-generated reports outright because of hallucinations and low signal. Interpretation is the key challenge.

AI helps defenders where it supports triage

Despite the increase in noise, defenders aren’t starting from a position of weakness. AI is already proving useful in one specific area: triage. For years, security teams have been overwhelmed by alerts, vulnerability feeds, and signals competing for attention. LLMs are well suited to classification and prioritization, even when they’re imperfect, because misclassification in triage doesn’t mean something disappears: it just moves lower in the queue. (As an aside, this does contribute to the “low-priority is no-priority” binary problem, but that’s not new in vuln management.)

We expect this to become normalized in 2026. AI won’t (and certainly shouldn’t) replace analysts or make autonomous security decisions, but it will increasingly be used to sort, group, and contextualize work before a human ever looks at it. Teams that use AI to reduce alert fatigue and focus attention will cope better with rising noise, while teams that expect it to think or reason on their behalf won’t.

Automation creates new operational failures

As more security and operational tasks are automated, new classes of mistakes will appear. Not because the technology is malicious, but because it’s being asked to act with limited context. When AI agents are given permissions and autonomy without a clear model of what “normal” behavior looks like, errors can propagate quickly.

At some point in 2026, the incident won’t start with a human clicking a phishing link, but with an AI assistant doing it on that human’s behalf. Or when one assistant convinces another to act on bad information: effectively one AI assistant phishing another.

Automation can remove friction, but it can also remove pauses and checks. Without clear boundaries and visibility into what automated systems are doing, mistakes travel faster than people can intervene.

A new AI-created vulnerability class emerges

2026 may be the year a genuinely new class of software vulnerability appears; one that isn’t just an evolution of existing bug types. This won’t come from AI writing obviously broken code, but from AI producing solutions that work, are adopted, and spread before anyone fully understands how or why they’re risky. The issue won’t be that the code fails; it’s that it will succeed in ways people don’t reason about naturally.

The underlying concern is that models don’t think like programmers. They don’t reason in the same abstractions, assumptions, or constraints, and that difference matters. When AI-generated patterns are reused widely — because they solve real problems efficiently — flaws can propagate at scale before they’re recognized as vulnerabilities at all.

Our prediction isn’t that this will happen someday in the distant future. It’s that 2026 is when the industry will first have to confront vulnerabilities that exist specifically because of how AI systems reason, not because of familiar programming mistakes.

For the full discussion of these — complete with context, caveats, and detours — plus a look back on 2025's highs and lows, watch to the latest runZero Hour.

Cyera has reported a vulnerability in the n8n workflow automation tool. This flaw allows a remote, unauthenticated attacker to execute arbitrary code on the vulnerable system. Successful exploitation could allow complete system compromise.

This vulnerability has been assigned CVE-2026-21858 and is rated highly critical has a CVSS score of 10.0.

The following versions are affected

• n8n versions 1.65.0 up to but not including 1.121.0

What is n8n?

n8n is an AI-centric workflow automation tool.

What is the impact?

Successful exploitation of this vulnerability would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

n8n.io has released version 1.121.0 of n8n. Users are urged to update as quickly as possible.

How to find potentially vulnerable systems with runZero

From the Services inventory, use the following query to locate potentially vulnerable assets:

_asset.protocol:="http" AND protocol:="http" AND html.title:="n8n.io%"

To get to the point, it occurred to me that I didn’t have an immediate understanding of how often CVEs are disputed, or rejected, in the first place. How big of a problem is this dispute and rejection confusion, really? That’s kind of a gap in my own understanding of the program, so since we’re talking about CVE disputes and rejections and all these sad outcomes for CVEs, let’s find out together how often this all happens!

First off, with over 300,000 CVE records currently published, it’s always a bit of a trick to count subsets of CVE records, especially when you’re dealing with CVEs that were rejected, and thus, deleted out of the history. CVE records don’t come with an easy and obvious history of changes – what you get today from a CVE record stands by itself, atomically. But, with just a little shell scripting magic and the power of GitHub, I think I have a pretty decent mechanism to keep on top of these stats, though it takes a few minutes to walk a git history.

Here’s my goofball shell script output, which depends on zsh, as I am a civilized gentleman on a MacBook for most of my computing. A run of this against a recent git checkout of CVEProject/cvelistV5 can shed some light on what actually goes on in CVE-land:

[2026-01-07 10:31:13] Completed audit:
  [*] Total CVE records:    40480
  [*] Rejected CVE records: 1648
  [*] Year:                 2025
    1648 cveaudit-rejected.txt
     120 cveaudit-disputed-today.txt
      85 cveaudit-rejected-after-published.txt
      18 cveaudit-rejected-after-disputed.txt
    1545 cveaudit-rejected-unpublished.txt
    3416 total

Some kind of interesting observations shake out here. First, CVE records are very rarely rejected these days. The CVE Program doesn't just swing, swing, swing the rejection hammer at every disagreement; out of the 40,000 CVE records created with a “2025” label, it looks like only 85 were rejected after they were first published. Most (about 96%) were caught and rejected before they ever saw the light of day, and that’s typically due to internal housekeeping – a CNA reserved a CVE, found out it was a duplicate, or not a bug after all, or some other internal process. No dramatic public fight or anything.

Even more interesting, of those CVEs that were published and subsequently labelled as disputed, for whatever reason, only 18 total (not 18%) were ultimately rejected. The comfortable majority (about 85%) live on, with the ignoble scarlet letter of a disputed tag.

Just in case you were thinking that 2025 was an outlier, it is, but not for the reasons you think. I get similar results for 2023. Kind of surprisingly, 2024 was the true outlier, since 2025 is a fair bit down from last year.

  [*] Total CVE records:    38912
  [*] Rejected CVE records: 737
  [*] Year:                 2024
     737 cveaudit-rejected.txt
     105 cveaudit-disputed-today.txt
     108 cveaudit-rejected-after-published.txt
      82 cveaudit-rejected-after-disputed.txt
     547 cveaudit-rejected-unpublished.txt
    1579 total

  [*] Total CVE records:    31103
  [*] Rejected CVE records: 603
  [*] Year:                 2023
     603 cveaudit-rejected.txt
     126 cveaudit-disputed-today.txt
      69 cveaudit-rejected-after-published.txt
      17 cveaudit-rejected-after-disputed.txt
     517 cveaudit-rejected-unpublished.txt
    1332 total

In all three years, the vast majority of rejected CVEs were never published to begin with. This lines up with the aforementioned blog from the CVE Council of Roots – the disputed tag is clearly not being treated as a death sentence for CVE records, but merely a signal that “hey, people disagree about this CVE record, and that’s okay.”

The surprising part, really, is how rarely disputed status even comes up. This could be explained a couple of ways. Maybe the dispute process is really, really high friction, so most people don’t bother unless they’re really annoyed by a CVE’s existence. Or, maybe there’s a nefarious conspiracy among the CNAs to squash dispute reports before they ever reach published CVEs, like some kind of Star Chamber of CVE truth. On the third hand, maybe most CVEs are basically okay, and there isn’t a need to over-engineer a dispute process when disputes are both rare, and meant to signal mild-to-severe disagreement over a CVE’s content.

What should you do with disputed CVEs? Well, since they’re so rarely disputed, they’re naturally going to be that much more interesting. After all, everyone secretly loves a liiiiitle bit of drama at work. You could study these all in the space of a few days, in depth, and hopefully come away with a better understanding of why they’re in dispute. If you are in a position where you need to justify to your manager why you are, or aren’t, addressing a particular CVE, and it’s disputed, you probably want to get a pretty good handle on what people are disagreeing on with that bug. But, since there aren’t hundreds and hundreds of these things, you can usually get caught up pretty quickly with just a little reference-spelunking. Ask the issuing CNA, or the original reporter of the vulnerability, and they’re likely to be eager to spill the tea.

The moral of the story, though, is that while CVEs are generally useful for describing known, documented vulnerabilities, they are not the end-all, be-all of vulnerability management. There’s even a tiny percentage that aren’t themselves clear on if they’re even a vulnerability or not. As always, if you want to get a beyond-CVEs view of your enterprise’s overall exposure, in context, give our free trial a whirl, why don’t you? It’s 2026, a brand new year, and a fine time to consider a more whole-network, whole-exposure approach to vulnerability management that will actually help you not get hacked rather than just merely check the compliance box.

HP Enterprise has reported a vulnerability in their OneView product. This flaw allows a remote, unauthenticated attacker to execute arbitrary code on the vulnerable system. Successful exploitation could allow complete system compromise.

This vulnerability has been assigned CVE-2025-37164 and is rated highly critical has a CVSS score of 10.0.

There is evidence that this vulnerability is being actively exploited in the wild.

The following versions are affected

• All versions of HPE OneView 10.20 and prior

What is HPE?

HPE OneView is a comprehensive IT infrastructure management application.

What is the impact?

Successful exploitation of this vulnerability would allow an adversary to execute arbitrary code on the vulnerable host, potentially leading to complete system compromise.

Are updates or workarounds available?

HPE has released hotfix HPE_OV_CVE_37164_Z7550-98077 and has advised all users to apply this hotfix. Note that this hotfix does not apply to versions of HPE OneView 5.20, which may remain vulnerable. This hotfix must be reapplied after an appliance upgrade from HPE OneView version 6.60.xx to 7.00.00, including any HPE Synergy Composer reimage.

How to find potentially vulnerable systems with runZero

From the Software inventory, use the following query to locate potentially vulnerable assets:

(vendor:="HP" AND product:="Oneview") OR (vendor:="HPE" AND product:="OneView")