For the first time, attackers are exploiting unpatched vulnerabilities more often than they’re stealing credentials. According to Verizon’s 2026 Data Breach Investigations Report, vulnerability exploitation now accounts for 31% of breaches, ahead of credential theft at 13%. And the gap is moving in the wrong direction for defenders: the median time to fully patch a vulnerability climbed to 43 days, up from 32 the year before, while organizations patched only 26% of the vulnerabilities on CISA’s Known Exploited Vulnerabilities list, down from 38% in 2024 (we broke down what’s driving this shift here).

Scanners aren’t the bottleneck here. Finding a vulnerability and actually fixing it have turned into two separate problems, and the second one is losing ground.

Detection was never the hard part

Greenbone’s OPENVAS has spent nearly two decades getting good at the first half: scanning a network, identifying what’s exposed, and scoring how dangerous it is. Elmar Geese, Greenbone’s CEO, likes to compare it to a swarm of robots checking every door and window in a house. They’re fast and thorough, and when they find a broken lock, they sound the alarm.

But an alarm only matters if someone acts on it. In most organizations, that’s where things stall. A scan result lands in a report, or an inbox, or a spreadsheet nobody opens until the next audit. Someone has to read it, work out what it actually means for their specific systems, decide who owns the fix, and turn that into a tracked piece of work with a deadline. That step requires security expertise that not every IT team has sitting around, and it’s exactly where things get lost: severity gets misjudged, tickets get duplicated or never created, ownership gets argued over after the fact instead of decided up front.

This is the part of vulnerability management that doesn’t show up in scanner marketing, but it’s where most of the real delay lives.

What the integration actually changes

KIX CEO Rico Barth puts it simply: the partnership closes the gap “between the detection and the resolution of vulnerabilities.” That gap is where a security finding used to need a translator. Now it doesn’t.

KIX, the open-source ITSM platform, and Greenbone have built a direct line between the two halves of the problem. When OPENVAS flags a vulnerability, it doesn’t generate a report and stop there. It opens a ticket in KIX automatically: classified as a security incident, tied to the specific device or software it affects, and sent to the team that owns that asset. The fix-it workflow, with deadlines, reminders, and escalations, starts the moment the vulnerability is confirmed, not whenever someone gets around to reading the scan output.

It also means an IT admin opening a ticket isn’t starting from zero. The asset, the affected system, who needs to be told, and how this fits into everything else currently open are all sitting right there. Nobody has to cross-reference three different tools to figure out what’s actually going on.

The bonus nobody asked for: finding the stuff you didn’t know you had

There’s a side effect that turns out to matter almost as much as the ticketing itself. OPENVAS scans more than the systems IT already knows about. It finds the laptop a department bought without asking IT, or the server someone spun up two years ago and forgot about. That inventory now flows straight into KIX’s asset database.

Shadow IT is usually framed as a policy problem. In practice, it’s a visibility problem that gets worse as networks grow. Greenbone customers are routinely surprised by what shows up the first time their environment gets properly scanned. Folding that discovery into the same system that already handles tickets and ownership means an unknown device gets absorbed into the normal IT process right away, instead of sitting in its own blind spot.

Why this matters more given who’s actually doing the work

IT and security teams are stretched thin almost everywhere, and the manual interpretation step in vulnerability management has always assumed there’s enough specialized staff to do it well. That assumption is getting shakier every year. Take away the step where a human has to manually triage, classify, and route every finding, and smaller or generalist IT teams no longer need to borrow security expertise they didn’t have in-house just to keep up.

It also helps with something that eats more time than it should: proving you did the work. Documentation, deadlines, and resolution history land automatically in KIX, which makes audits against frameworks like NIS-2, ISO 27001, or BSI-Grundschutz considerably less painful, since the evidence trail already exists instead of getting reconstructed after the fact.

Try it where it counts

If your team is running OPENVAS and KIX separately today, or evaluating either one, this integration is worth a closer look specifically because it removes a step rather than adding one. Get in touch with us to see how the handoff from scan to fix works in your own environment, and what it would take to set up. And if you’re not scanning with OPENVAS yet, OPENVAS BASIC is a reasonable place to start before connecting the rest.

Effective vulnerability management does not begin and end with scanning. To be effective, vulnerability management requires a solid understanding of both scanner technology and your IT infrastructure. Operationally, vulnerability management depends on having reliable and repeatable processes, well-defined ownership, integration with day-to-day IT operations, and strategic governance.

Every organization exists at a different stage of VM maturity. Some are just beginning to introduce vulnerability scanning. Others have established operational processes but lack structured prioritization, remediation tracking, or business alignment. The most mature organizations treat vulnerability management as an essential security control for mitigating exposure to emerging threats and reducing overall business risk.

A vulnerability management maturity model provides a structured way to assess the current state of your organization’s program. It helps security, IT, and business stakeholders understand where their security posture stands today, identifies “blockers” limiting progress, and defines next steps toward a more effective and sustainable vulnerability management process.

In this article, we will review a structured model for defining VM maturity. The model defines 5 levels of maturity and explains how to identify where your organization sits within the model. It also describes the limitations that each level imposes on resilient operational cyber security.

Understanding the 5 Stages of Vulnerability Management Maturity

Vulnerability management maturity can be divided into five levels. Each level reflects a different stage of discipline, operational capability, organizational involvement, and governance maturity. Organizations typically progress from basic technical scanning toward a risk-driven security program that is integrated into IT operations and continuously improved based on measurable KPI outcomes.

Stage 1 – Ad-hoc

At the Ad-hoc stage, vulnerability management is typically a brand new activity to an organization, or being performed inconsistently. Scanning is not formally scheduled, and there are no documented security processes. The organization may have a scanning tool installed, but scan coverage is unmeasured and results are not systematically used to drive remediation.

The informal mindset at this stage is often: “We’ll scan it somehow.” While this attitude and raw effort may provide some initial visibility, it does not constitute a reliable vulnerability management program.

The Limitations of an Ad-hoc / Initial Security Program

The main limitation at this stage is the absence of structure. Without a complete asset inventory, an organization doesn’t know if critical systems are being scanned. Without a defined scope or schedule, scanning activity remains an afterthought. Without clear ownership, discovered vulnerabilities may not be communicated to the correct teams for remediation.

Common limitations include:

• No complete asset inventory
• No defined scan scope or schedule
• No ownership or responsibilities
• No reporting or KPIs
• No structured remediation process

Stage 2 – Repeatable / Operational

At the Repeatable / Operational stage, vulnerability scanning is more consistent. Regular scans are performed, basic operational stability exists, and the organization has initial visibility into vulnerabilities across part of its environment. This level represents an important transition from informal activity to repeatable execution. An organization now reliably performs scans on a recurring basis, and some responsibilities for the vulnerability management program have been assigned, such as administrator or technical owner.

An organization may be scanning systems regularly, but it has not yet established a fully managed process for auditing, prioritizing, tracking, and remediating vulnerabilities.

The Limitations of a Repeatable / Operational Security Program

This Repeatable / Operational stage is still primarily technical. The main limitation at this stage is that vulnerability data is not yet effectively managed through a structured lifecycle. Organizations know where vulnerabilities exist, but lack a formal process for deciding which issues matter most, who should fix them, and by when. Governance is limited to basic reporting, without KPI-driven management or formal performance targets.

Common limitations include:

• No structured prioritization
• No defined remediation SLAs
• Limited tracking of remediation
• Weak cross-team collaboration

Stage 3 – Defined / Managed

At the Defined / Managed stage, vulnerability management becomes structured and measurable. An organization has established processes for identifying, prioritizing, remediating, and tracking vulnerabilities. Responsibilities are clearly assigned across relevant stakeholders, including IT and security teams. This level marks the point where vulnerability management becomes a managed operational process rather than a scanning activity.

An organization at this stage uses KPIs to measure performance, applies risk-based prioritization, and follows well-defined remediation workflows. Scan coverage is verified, and authenticated scanning is in place for defense in depth.

A Level 3 program can answer important management questions: Which vulnerabilities are most important? Who owns remediation? How long does remediation take? Are teams meeting defined targets? Where are recurring issues appearing?

The Limitations of a Defined / Managed Security Program

A program at this level is structured but not automated or deeply integrated. Processes are documented and measurable, but execution still depends largely on manual coordination. Integration of scanning infrastructure with IT operations, ticketing, patch management, or change management is non-existent or incomplete.

Common limitations include:

• Limited automation
• Weak integration into IT processes
• Limited business alignment

Stage 4 – Integrated / Controlled

At the Integrated / Controlled stage, vulnerability management is firmly integrated into IT operations. The program is no longer managed as a separate security activity; it is integrated into the operational systems and workflows that control infrastructure, applications, patching, change management, incident response, and service management.

Processes at this stage are automated and scalable. Vulnerability findings can be converted into tickets, assigned to the correct owners, tracked through remediation, and measured against defined targets. Integrations with ITSM, SIEM, patch management, and related operational systems enable end-to-end visibility and control. Overall, an organization can manage vulnerability remediation with more consistency, accountability, and operational efficiency.

The Limitations of an Integrated / Controlled Security Program

The main limitation at this stage is a lack of strategic optimization. An organization has strong processes and integrations, but isn’t using vulnerability management data for feedback into long-term strategic planning, investment planning, or continuous optimization.

Common limitations include:

• Limited strategic steering
• Optimization potential not fully leveraged

Stage 5 – Optimized / Strategic

At the Optimized / Strategic stage, vulnerability management is risk-driven, continuously improving, and strategically aligned with business objectives. An organization not only treats vulnerabilities as technical defects; it evaluates them in the context of business risk, asset criticality, threat exposure, operational impact, and security strategy.

Continuous improvement is embedded into programs at this level. Metrics, remediation data, recurring vulnerability patterns, exception handling, and risk decisions are used to refine the vulnerability management process over time. Vulnerability management becomes part of a broader security governance and risk management capability.

The Limitations of an Optimized / Strategic Security Program

There are typically no major structural gaps at this maturity level. The program is stable, integrated, governed, and strategically aligned. Remaining limitations are considered optimization opportunities rather than foundational weaknesses.

Common optimization areas may include:

• Refining risk models
• Improving automation accuracy
• Enhancing business context
• Reducing remediation friction
• Improving predictive and trend-based analysis

Summary

Vulnerability management maturity is about much more than whether an organization owns a scanning tool and how often scans are conducted. As organizations progress from Ad-hoc maturity to an Optimized / Strategic vulnerability management program, the process evolves from a technical one into a strategic security capability.

At its core, VM maturity is defined by how consistently an organization can identify vulnerabilities, prioritize them based on risk, assign ownership, track remediation, measure performance, and improve the process over time. An immature program provides occasional visibility, but cannot reliably guarantee that risk is reduced to an acceptable level. A highly mature program connects technology, process, organization, and governance into a controlled lifecycle.

Once an organization understands its existing maturity level, it can plan practical next steps. Asset coverage will improve, standards and process will be well understood by stakeholders, and well-defined ownership and SLAs will ensure reliable and effective results. The overall result is a strategic reduction in business risk.

Exploitation of vulnerabilities has now emerged as the most common way that attackers gain initial access into an organization’s environment, which underlines the ongoing importance of getting the basics right.

• Verizon 2026 Data Breach Investigation Report [1]

More CVEs, Less Time

The industrialization of vulnerability exploitation is not new; the process-driven approach to vulnerability weaponization long predates LLMs. But increasingly, sophisticated cyber security skills are available to anyone with a laptop. Anthropic’s first official impact report for Mythos has been released [1][2]. The results indicate that, despite not yet achieving perfection, the impact will be felt by software vendors and defenders.

In April and May 2026, major software vendors [3][4][5], security intelligence providers [6][7][8], and cyber security news outlets [9] acknowledged Mythos’ impact on vulnerability disclosures. Security researchers from Mozilla claim it is “difficult to overstate how much this dynamic changed for us over a few short months”. Cisco noted the lack of downstream support for disclosing the upcoming deluge of new issues. Combined with the DBIR quote at the top of this blog post, the takeaway is clear. Defenders need to double down on continuous vulnerability management and audit patching performance to reduce critical risk exposure.

Cisco Publishes Two CVSS 10 Flaws — Catalyst SD-WAN Actively Exploited

Two new maximum-severity flaws were disclosed for Cisco products in May 2026. CVE-2026-20182, affecting Cisco Catalyst SD-WAN, is considered actively exploited; CISA has added the flaw to its KEV list and updated guidance on attacks targeting Catalyst SD-WAN. Six other CVEs in Catalyst SD-WAN were also added to CISA KEV in 2026. The other new max-severity flaw from May 2026 is CVE-2026-20223 affecting Cisco Secure Workload.

National CERT alerts were widely issued for both CVE-2026-20182 [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18] and CVE-2026-20223 [19][20][21][22][23][24][25][26][27][28][29]. Details on both CVEs are included below:

• CVE-2026-20182 (CVSS 10, EPSS >= 99th pctl): A vulnerability in the peering authentication of Cisco Catalyst SD-WAN Controller and Cisco Catalyst SD-WAN Manager allows an unauthenticated, remote attacker to bypass authentication [CWE-287] to log in as an internal administrative user. Using the hijacked account, an attacker can access NETCONF and manipulate network configurations for the SD-WAN fabric. The flaw is exploitable via HTTP requests to the affected system. See Cisco’s official advisory for more information.
• CVE-2026-20223 (CVSS 10): Missing authentication [CWE-306] in the REST APIs of Cisco Secure Workload allows an unauthenticated remote attacker to access site resources with Site Admin Attackers can use crafted HTTP API requests to read sensitive information and make configuration changes across tenant boundaries. See Cisco’s official advisory for more information.

Cisco states there are no workarounds for either vulnerability. Patches must be applied for full mitigation. OPENVAS ENTERPRISE FEED includes detection for CVE-2026-20182 and CVE-2026-20223, and detection for other CVEs for Cisco products published in May 2026.

February 2026 Flaw in Trend Micro Apex One Now Actively Exploited

CVE-2026-34926, affecting Trend Micro Apex One 2019, has now been reported as actively exploited and has been added to CISA’s KEV list. Trend Micro issued a Critical Patch [KA-0022458] for the CVE in February 2026, along with two other critical-severity flaws. The patch also increased protection against CVE-2025-54948 (CVSS 9.8) and CVE-2025-54987 (CVSS 9.8), which were both added to CISA’s KEV list in mid-2025 [1][2]. On March 3rd 2026, the vendor issued updates for CVE-2025-71210  (CVSS 9.8) and CVE-2025-71211 (CVSS 9.8) [3][4] noting that they allow unauthenticated remote attackers to execute arbitrary code on affected installations.

Actively exploited CVE-2026-34926 (CVSS 6.7) is a directory traversal vulnerability [CWE-23] in the Apex One 2019 on-premise server and Server and Agent builds below 17079, Apex One as a Service SaaS, and Trend Vision One Endpoint for Windows. The flaw allows an attacker to modify a key table on the server to inject malicious code and deploy it to agents. The attacker must have access to the Apex One Server with Windows administrative credentials but authentication to Apex One itself is not required.

Greenbone’s OPENVAS ENTERPRISE FEED includes regular Windows detection for Trend Micro security advisories and added detection for KA-0022458 CVEs the day after they were issued in February 2026.

Living on the Edge: Emerging Threats to Perimeter IT Devices

According to Verizon’s 2026 DBIR report, exploitation of vulnerabilities has become the most common way attackers gain initial access into an organization’s environment. The findings underline the importance of detecting vulnerable software and applying patches. On that note, here are some of the high-risk threats to perimeter IT systems that emerged in May 2026.

Palo Alto Networks PAN-OS Actively Exploited

CVE-2026-0300 (CVSS 9.8, EPSS >= 95th pctl) is a new buffer overflow vulnerability [CWE-787] in the User-ID Authentication Portal (aka Captive Portal) service of Palo Alto Networks PAN-OS software. The flaw is actively exploited and has been added to CISA’s KEV list. PAN-OS versions 10.2 through 12.1.x are affected, and vulnerable devices include the PA-Series and VM-Series firewalls.

The vulnerability allows an unauthenticated attacker to execute arbitrary code on affected devices with root privileges. Risk is greatly reduced by restricting access to only trusted internal IP addresses. Numerous national CERT agencies have issued alerts for CVE-2026-0300 indicating high global risk [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18]. CISA and Siemens also issued alerts for Siemens RUGGEDCOM APE1808 (Application Processing Engine) devices at risk from CVE-2026-0300 [19][20].

Another flaw, CVE-2026-0257 (CVSS 7.8), affecting PAN-OS GlobalProtect deployments, was also added to CISA’s KEV list after observed exploitation. Palo Alto has rated the CVE with the Highest urgency rating. CVE-2026-0257 is an authentication bypass vulnerability in the GlobalProtect portal and gateway that can allow an unauthenticated attacker to bypass security restrictions and establish an unauthorized VPN connection.

The OPENVAS ENTERPRISE FEED includes package-level detection for both CVE-2026-0300 and CVE-2026-0257 [21][22] and includes an extensive family of vulnerability tests for PAN-OS vulnerabilities.

Ivanti EPMM: Three Critical-Severity and One Actively Exploited

Ivanti released a security advisory in May 2026, describing new CVEs impacting its Endpoint Manager (EPMM) product. Three critical-severity flaws allow unauthenticated remote attackers to trigger arbitrary functions on the EPMM appliance, impersonate registered Sentry hosts, obtain valid CA-signed client certificates, or enroll a device from a restricted set of unenrolled devices. CISA has added a separate high-severity flaw from the Ivanti’s advisory, CVE-2026-6973, to its KEV list. Details on the highest-risk flaws are included below:

• CVE-2026-6973 (CVSS 7.2, EPSS >= 91st pctl): Improper input validation [CWE-20] allows a remote authenticated user with administrative access to achieve remote code execution (RCE). CISA has added CVE-2026-6973 to its KEV list.
• CVE-2026-5788 (CVSS 9.8): Improper access control [CWE-284] allows an unauthenticated remote attacker to invoke arbitrary methods.
• CVE-2026-5787 (CVSS 9.1): Improper certificate validation [CWE-295] allows an unauthenticated remote attacker to impersonate registered Sentry hosts and obtain valid CA-signed client certificates.
• CVE-2026-7821 (CVSS 9.1): Improper certificate validation [CWE-295] allows an unauthenticated remote attacker to enroll a device belonging to a restricted set of unenrolled devices. Exploitation can lead to information disclosure about an EPMM appliance and impact on the integrity of the newly enrolled device identity.

The flaws affect EPMM before versions 12.6.1.1, 12.7.0.1, and 12.8.0.1. No technical details or PoC exploits are publicly available for any of the CVEs. Ivanti EPMM has been battered by cyber attacks  in recent years, appearing eight times on CISA’s KEV list — twice associated with ransomware attacks. Greenbone provides broad vulnerability detection for Ivanti products, allowing defenders to detect and mitigate emerging threats.

Multiple Fortinet Products Hit with Critical Vulnerabilities

Fortinet published multiple security advisories in May 2026, affecting FortiSandbox, FortiOS, FortiAP, FortiAnalyzer, FortiManager, and FortiAuthenticator. The disclosures include two critical flaws: CVE-2026-26083 in FortiSandbox and CVE-2026-44277 in FortiAuthenticator. Both vulnerabilities are remotely exploitable and can allow unauthorized code or command execution, presenting strong risk signals for exposed appliance interfaces. There is no evidence that either CVE is actively exploited or that detailed technical descriptions or PoC exploits are publicly available.

• CVE-2026-26083 (CVSS 9.8): Missing authorization [CWE-862] in the FortiSandbox GUI allows RCE for a remote, unauthenticated attacker via crafted HTTP requests. The vulnerability requires no privileges and no user interaction, and successful exploitation can have a high impact on confidentiality, integrity, and availability. Affected versions include FortiSandbox 5.0 and 4.4; FortiSandbox Cloud 24, 23, and 5.0; and FortiSandbox PaaS 23.4, 23.3, 23.1, 22.2, 22.1, 21.4, 21.3, 5.0, and 4.4. Several national CERT alerts have been issued for CVE-2026-26083 [1][2][3][4][5][6][7][8][9].
• CVE-2026-44277 (CVSS 9.8): Improper access control [CWE-284] in FortiAuthenticator allows an unauthenticated attacker to execute unauthorized code or commands via crafted requests. FortiAuthenticator Cloud is not impacted. Affected versions include FortiAuthenticator 8.0.2, 8.0.0, 6.6.0 through 6.6.8, and 6.5.0 through 6.5.6. Multiple national CERT alerts have been issued for CVE-2026-44277 [10][11][12][13][14][15][16][17].

Organizations should apply vendor patches as soon as possible. OPENVAS ENTERPRISE FEED includes detection coverage for the flaws mentioned above [18][19] and a dedicated detection family for Fortinet vulnerabilities.

New SQL Injection in Drupal Core with PostgreSQL Actively Exploited

CVE-2026-9082 (CVSS 9.8) is a new actively exploited [1][2][3], unauthenticated SQL injection vulnerability [CWE-89] that affects the Drupal open-source content management system (CMS). Exploitation could allow privilege escalation and RCE on an affected server via malicious HTTP requests. Drupal supports multiple back-end database servers. Drupal’s official advisory states that CVE-2026-9082 only affects instances using PostgreSQL. The vendor further estimated 5% of installations use PostgreSQL.

A full technical description with PoC exploit code and at least one additional PoC is available for CVE-2026-9082, increasing the risk. Multiple national CERT agencies have issued alerts [4][5][6][7][8][9][10][11][12][13]. Drupal core versions 8.x through 11.3.x are affected, and fixes are available in versions 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10, 10.4.10, and via manual patches for versions 9.5 and Drupal 8.9. The OPENVAS ENTERPRISE FEED includes detection for both Windows and Linux installations [14][15].

vm2 Project Erupts with Critical Severity Vulnerabilities

Thirteen critical-severity vulnerabilities were disclosed affecting the vm2 project in May 2026. The vm2 project is a Node.js sandboxing library mainly used to execute untrusted or user-supplied JavaScript in an isolated environment. The group of CVEs included several maximum-severity CVSS 10 flaws. Collectively, the vulnerabilities undermine vm2’s core security boundary: isolating untrusted JavaScript from the underlying Node.js host environment. Successful exploitation can allow sandbox escape and arbitrary code or operating system command execution in the context of the host process.

Affected vm2 versions vary by CVE, spanning multiple release lines. Some of the earlier issues were fixed in 3.10.5, 3.11.0, 3.11.1, or 3.11.2, while later CVEs affected versions through 3.11.3 and were patched in 3.11.4. Users should upgrade to 3.11.5 or later. The OPENVAS ENTERPRISE FEED includes package-level detection for all new CVEs impacting the vm2 project.

Multiple Critical Flaws in Apache Software Products

In May 2026, the Apache Software Foundation published 18 critical-severity CVEs and an additional 28 high-severity flaws. Greenbone’s OPENVAS ENTERPRISE FEED includes detection for all Apache software flaws mentioned in this section, and many more. The most critical new CVEs are briefly described below:

One Critical and Several High Severity Flaws in HTTP Server

CVE-2026-28780 (CVSS 9.8) and CVE-2026-23918 (CVSS 8.8, EPSS >= 0.77th pctl) affect Apache HTTP Server 2.4.66 and earlier and specific 2.4.66 configurations. Both CVEs are memory-safety issues. CVE-2026-28780 is a heap-based buffer overflow [CWE-122] in mod_proxy_ajp; exploitation requires Apache HTTP Server to connect through mod_proxy_ajp to a malicious AJP server.

CVE-2026-23918 is a “double free” vulnerability [CWE-415] affecting the HTTP/2 implementation. When a program calls free() twice with the same argument, data structures may become corrupted, potentially allowing reading or modification of unexpected memory addresses. The flaw can be triggered during an early stream reset and can cause denial of service (DoS), with possible RCE depending on runtime conditions. Apache recommends upgrading to Apache HTTP Server 2.4.67, which fixes both issues.

Two New Critical Flaws in Apache MINA

CVE-2026-42778 (CVSS 9.8) and CVE-2026-42779 (CVSS 9.8) are critical deserialization vulnerabilities in Apache MINA that can expose affected applications to unauthenticated RCE when they use Apache MINA to deserialize Java classes supplied by a client. Both flaws affect Apache MINA 2.1.x and 2.2.x branches and stem from incomplete or unapplied fixes for earlier deserialization issues.

Three Critical Flaws in Apache OFBiz

CVE-2026-45434 (CVSS 9.8), CVE-2026-41919 (CVSS 9.1), and CVE-2026-31986 (CVSS 9.1) affect Apache OFBiz versions before 24.09.06 and can expose affected ERP deployments to authentication bypass, unauthorized access, or code execution, depending on configuration and attack path. CVE-2026-45434 is the highest-risk issue. The flaw is caused by improper authentication in password-change logic that can lead to unauthenticated RCE.

Three Critical Flaws in Apache Tomcat

CVE-2026-43512 (CVSS 9.8), CVE-2026-41293 (CVSS 9.8), and CVE-2026-43515 (CVSS 9.1) affect Apache Tomcat. Collectively, the flaws can expose vulnerable deployments to authentication bypass or authorization failures depending on configuration. CVE-2026-43512 affects deployments using DIGEST authentication and allows an unknown user to be authenticated with a specific invalid password condition.

CVE-2026-41293 stems from improper validation of HTTP/2 request headers, allowing malformed or unexpected header values to trigger unsafe downstream behavior. CVE-2026-43515 is an improper authorization flaw involving overlapping HTTP method constraints that can allow unauthorized access to protected resources. Users should upgrade to fixed Tomcat versions, including 11.0.22, 10.1.55, or 9.0.118 where applicable.

Two Critical Flaws in Apache Camel

CVE-2026-47323 (CVSS 9.8) is a critical-severity message header injection and request forwarding vulnerability affecting the Apache Camel integration framework. The flaw allows an unauthenticated attacker to inject Camel-internal headers (e.g. CamelExecCommandExecutable and CamelFileName) via HTTP requests to CXF-RS or CXF-SOAP endpoints.

Langflow Actively Exploited and Five Additional Critical-Severity Flaws in 2026

Langflow is a popular Python-based open-source platform for low-code building and deploying AI applications, agents, and workflows. IBM reports that tens of thousands of developers use it for generative-AI development. In May 2026, CVE-2025-34291 (CVSS 8.8) affecting Langflow was reported as actively exploited and added to CISA’s KEV list. Five additional critical-severity CVEs affecting Langflow have been disclosed since the start of 2026.

• CVE-2025-34291 (CVSS 8.8, EPSS >= 97th pctl): A chained vulnerability caused by permissive cross-origin behavior [CWE-346] and leading to flawed session/token handling can enable account takeover and RCE when a user interacts with a malicious webpage. The victim needs to be authenticated while visiting an attacker-controlled webpage that makes credentialed cross-origin requests to Langflow because of the permissive CORS and cookie configuration.
• CVE-2026-33017 (CVSS 9.8): An unauthenticated RCE flaw in the public temporary flow-build endpoint, where attacker-supplied flow data can be processed as executable Python code without adequate sandboxing.
• CVE-2026-21445 (CVSS 9.1): Missing authentication [CWE-306] on some critical API endpoints allows unauthenticated attackers to access sensitive user data, conversation or transaction records, and perform destructive operations such as message deletion.
• CVE-2026-33309 (CVSS 9.9): A bypass of an earlier filename-control patch in the LocalStorageService layer allows arbitrary file write behavior [CWE-22] through the v2 API, potentially leading to RCE.
• CVE-2026-27966 (CVSS 9.8): The CSV Agent node exposed sensitive Python REPL functionality, allowing attackers to execute arbitrary Python or operating system commands via prompt injection.
• CVE-2026-42048 (CVSS 9.6): A path traversal flaw [CWE-22] in the Knowledge Bases API allows an authenticated attacker to delete arbitrary directories on the server by supplying unsafe knowledge base names. The flaw is due to concatenating user-supplied names into filesystem paths without proper boundary validation.

Summary

Mythos and other AI coding models are having an obvious impact on the number of new vulnerabilities disclosed in key enterprise software. The same technology also enables attackers to develop exploits easier and faster.

Defenders should implement continuous vulnerability management and audit performance to reduce risk exposure with OPENVAS SCAN and the OPENVAS ENTERPRISE FEED for industry-leading vulnerability coverage. Greenbone produces thousands of new vulnerability tests per month to detect flaws in enterprise software applications, IT networking products, major OSs and browsers, Linux packages, productivity tools, agentic AI tooling, and more. Defenders seeking to detect and protect can try Greenbone’s entry-level OPENVAS BASIC for free, including a two-week trial of the ENTERPRISE FEED.

NIST Significantly Reduces Independent CVSS Scoring in the NVD

For years, the routine has been the same. A new vulnerability appears, the security team checks the NVD, looks at the CVSS score, and decides: patch now or wait. A single number, produced by a U.S. federal agency, has become the pace-setter for millions of systems worldwide.

That pace-setter is now stepping back.

NIST has announced that it will significantly reduce its routine CVSS scoring activities for the National Vulnerability Database (NVD). The backlog of unprocessed entries has been growing since February 2024—from around 13,000 in June 2024 to over 27,000 by the end of 2025—amid a rising number of reported vulnerabilities and a stagnant budget.

What remains when NIST is no longer providing oversight is the CVSS score assigned by the software vendor itself.

NIST steps aside

The structural problem behind the headline

Within the security community, it is no secret that vendors tend to rate the severity of their own vulnerabilities conservatively. Until now, NIST has balanced this conflict of interest through an independent second assessment. That independence is now disappearing, and for teams that have relied on NVD CVSS scores as their primary source of prioritization, this represents a significant shift.

For Greenbone users, however, nothing changes operationally. Not because the news is irrelevant, but because the NIST NVD has never been Greenbone’s only source of vulnerability intelligence.

A broad international database rather than a single source of truth

For years, Greenbone’s approach has been built on a broad, international foundation of data sources. Vulnerability information is gathered from a diverse portfolio including official databases, vendor advisories, national authorities, European initiatives such as the European Vulnerability Database (EUVD), and the global security community. Each source is evaluated, weighted, and cross-referenced.

The value of this diversity becomes particularly clear in situations like the current one: when a single source becomes unavailable or loses quality, the overall picture for Greenbone users remains largely unchanged. This is not a reaction to a crisis—it has been an architectural principle since day one.

Are vendor-assigned scores inherently unreliable? The honest answer is no, not necessarily. Vendors that provide structured and transparent vulnerability information contribute valuable data—and Greenbone uses that information directly. The challenge lies in the structural incentive to downplay one’s own weaknesses and in the lack of independence when a single source becomes the sole authority.

The EuVD: European Sovereignty as a Constructive Response

The current NIST situation also highlights a broader dependency issue: Europe has relied for too long on a single U.S. institution for vulnerability assessment. The European Vulnerability Database (EUVD), operated by ENISA, represents the right response—sovereign, European, and independent of U.S. budget decisions.

Greenbone has actively integrated the EUVD from the beginning because any reliable new source naturally belongs in a diversified vulnerability intelligence ecosystem.

For security teams, the key question is therefore not whether NIST will recover.

The real question is how resilient your vulnerability assessment process remains when one source disappears—and whether you already know the answer today.

Defenders deploying Ubuntu will be pleased to know that Greenbone’s OPENVAS SCAN now includes detection for Ubuntu 26.04 LTS security notices via the OPENVAS ENTERPRISE FEED and COMMUNITY FEED. Ubuntu 26.04 LTS, aka “Resolute Raccoon”, is a long-term support (LTS) version of Ubuntu that was released on April 23rd, 2026. LTS releases receive standard security updates and critical bug fixes for five years, meaning Ubuntu 26.04 LTS will be supported until April 2031. Support for Ubuntu 26.04 LTS extends OPENVAS SCAN’s existing detection capabilities for Ubuntu security advisories going back to Ubuntu 5.10.

Greenbone’s OPENVAS SCAN has industry-leading detection for many popular Linux distributions via authenticated Local Security Checks (LSC). Authenticated LSCs provide reliable detection because they analyze endpoint systems from within, build an asset inventory, uncover package-level software vulnerabilities, and identify other security misconfigurations.

Defenders seeking to detect and protect can try Greenbone’s OPENVAS BASIC for free, including a two-week trial of the OPENVAS ENTERPRISE FEED.

Ubuntu 26.04 LTS Support

Operating system (OS) security updates are critical for maintaining a strong enterprise security posture. A single flaw may give an attacker the initial access needed to execute a costly cyber attack. OS vulnerabilities impact all aspects of IT infrastructure, including on-premises and cloud assets, fleets of staff workstations, development environments, container hosts, virtualization platforms, and edge infrastructure. New regulations and compliance requirements are also demanding greater accountability and placing heavier burdens on IT security teams. Defenders need improved visibility into emerging security risks to effectively prioritize remediation.

Support for Ubuntu 26.04 LTS Security Notices Is Here!

Canonical publishes Ubuntu Security Notices (USNs) when security issues are fixed in official Ubuntu packages. A typical USN identifies the affected package, affected Ubuntu releases, associated CVE IDs, vulnerability impacts, and the package updates required for remediation.

Organizations deploying Ubuntu 26.04 LTS can now use Greenbone’s OPENVAS SCAN to detect Ubuntu 26.04 security notices in both the OPENVAS ENTERPRISE FEED and COMMUNITY FEED.

• Visit the official site for Ubuntu Security Notices
• View all OPENVAS SCAN vulnerability tests for Ubuntu 26.04 LTS

Summary

Linux systems form the backbone of many enterprise environments, supporting critical infrastructure, cloud platforms, staff workstations, development systems, container hosts, and production workloads. Maintaining Linux security requires consistent visibility into vulnerabilities and timely patch management. Effective OS-level vulnerability management reduces exposure to exploitation, supports regulatory compliance, and helps organizations maintain a resilient security posture.

Organizations deploying Ubuntu 26.04 LTS can now use Greenbone’s OPENVAS SCAN to detect Ubuntu security notices via the OPENVAS ENTERPRISE FEED and COMMUNITY FEED. Ubuntu 26.04 detection joins other popular Linux operating systems supported in both the OPENVAS ENTERPRISE FEED and COMMUNITY FEED, including Fedora, Debian, Suse, OpenSuse, Huawei EulerOS, OpenEuler, and Mageia. Greenbone’s OPENVAS ENTERPRISE FEED supports additional Linux distributions, including Amazon Linux, Oracle Linux, AlmaLinux OS, FortiOS, and many more.

Defenders can try Greenbone’s OPENVAS BASIC for free, including a two-week trial of the OPENVAS ENTERPRISE FEED.