We already explained what requirements the Cyber Resilience Act imposes as of September 11, 2026, in a separate post on the implementation status of the CRA reporting obligation. This post answers the other half of the question: how the implementation was carried out at Greenbone itself.

One clarification up front, because it is decisive for how transferable this is: we did not implement all of these measures from scratch. Much of it was already established practice at Greenbone and, for the CRA, only needed to be documented, sharpened, or turned into a binding process. Anyone facing the same task today will probably find more substance already in-house than expected.

Requirement: A Process for Vulnerabilities and Incidents

The CRA does not ask for a reporting button, but for a resilient process behind it. Alongside our process for handling incidents, we have therefore implemented a Coordinated Vulnerability Disclosure process. It regulates, in detail, what happens once a vulnerability becomes known, including the responsibilities involved. It comes with a checklist that can be worked through step by step. We track security incidents in our own Jira project, so that every case has a ticket with a full history.

The importance of thinking in terms of a process shows up in one place in particular: the 24-hour clock in Article 14 starts running from the moment of becoming aware, and the Commission spelled out exactly what that means in its guidelines on the application of the CRA (C(2026) 5252), adopted in July 2026. The standard is a “sufficient degree of certainty,” referencing recital 31 of Implementing Regulation (EU) 2024/2690 and EDPB Guidelines 9/2022 (paras. 211–214). Without a defined triage step, this point cannot be dated in an actual emergency, and without a date the deadline cannot be demonstrably met. It should be noted that this guideline is explicitly non-binding (para. 8); it is an interpretive aid, not a legal basis.

Two deadlines should be tracked separately in the process, because they run differently: the final report for a vulnerability is due 14 days after the fix is made available, while the one for a severe security incident is due one month after the 72-hour notification (para. 215). Anyone who tracks both clocks in a single field will end up reporting late in one of the two cases.

One point that eases the burden, and is often overlooked in the current debate: vulnerabilities that were already known before September 11, 2026, do not create a retroactive reporting obligation (para. 217). The existing backlog therefore does not need to be reported after the fact.

Requirement: Pass on Vulnerabilities in Third-Party Components

If a flaw in our products originates in a third-party artifact, we notify that artifact’s provider so it gets fixed there. If we implement a fix ourselves, we make it available upstream.

This matches section 9.2.1 of the Commission guidelines on Article 13(6): anyone integrating a third-party component must report vulnerabilities to the party maintaining it, unless that party is already aware, and should share fixes in a machine-readable and license-compatible form wherever possible. Also clarified: the reporting obligation itself applies to actively exploited vulnerabilities in one’s own product, not to every unexploited flaw in a third-party component (para. 218).

Requirement: Reachable Notification for Those Affected

For actively exploited vulnerabilities and severe security incidents that can affect the security of our products, we publish advisories in CSAF format at the well-known path, apart from any exceptions under TLP:WHITE. For severe vulnerabilities that originate in our own code, we request and publish a CVE.

Why machine-readable? Because an advisory that exists only as a web page creates manual work for the recipient. Anyone who wants to know which roles in the CSAF ecosystem carry which obligations can find the breakdown in our post on CSAF 2.0 stakeholders and roles.

Important for setting expectations: the obligation under Article 14(8) to inform users is designed to be risk-based and proportionate, not a blanket obligation to publicly disclose every case (paras. 219–221). What needs to be published depends on the individual case, not on an automatism. Our exception to TLP:WHITE exists precisely for that purpose.

What Only a Scanner Vendor Can Do

For severe vulnerabilities in our products, we additionally build a vulnerability test, so that OPENVAS SCAN detects and reports the vulnerability. This building block is explicitly not meant to be replicated: it assumes you are a vulnerability scanner vendor yourself. For our customers, it means they don’t have to infer whether their own installation is affected from an advisory — they can measure it.

Requirement: Respond, Not Just Report

Depending on the severity of a flaw, we build an emergency release and make it available to customers. After a vulnerability has been handled, a post-mortem analysis follows.

Requirement: Being Reachable for Reports From Outside

So that people who discover a vulnerability can reach us, the Greenbone website has a page on reporting vulnerabilities in products, as well as a security.txt compliant with RFC 9116.

A tip from practice that costs nothing and saves a lot: test your processes, so you don’t only find out during an actual emergency that something doesn’t work the way it was meant to.

What’s still open for us is testing a notification to ENISA. As described in the previous post, the platform doesn’t yet exist in its final form. We can prepare for this point, but we can’t close it out yet.

Requirement: Knowing Your Own Supply Chain

Another part of our preparation for September 11, 2026, is that we generate SBOMs of our products automatically as part of the build process. This is where OPENVAS SECURITY INTELLIGENCE comes in, which we use to scan the SBOMs for vulnerabilities. Thanks to the daily updated meta feed, vulnerabilities in the components we use can be addressed early, so that exploitation in the wild never gets a chance to happen in the first place.

It’s also worth regularly checking your suppliers’ advisories, so you can update to fixed versions early. More and more vendors are publishing their advisories in CSAF format; that’s also the method preferred by the BSI, as laid out in BSI Technical Guideline TR-03191 and in the BSI’s recommendation on the use of CSAF. Here too, it’s worth using OPENVAS SECURITY INTELLIGENCE, which lets you download and analyze CSAF advisories on a regular basis, including access-restricted ones, for example every night or even every hour.

Checklist: Where Do You Stand on the CRA Reporting Obligation?

Self-check: where do you stand?

• A Coordinated Vulnerability Disclosure process with clear responsibilities is in place
• Vulnerabilities in third-party components are passed on to the party maintaining them
• Affected parties are informed via machine-readable advisories (e.g. CSAF)
• There is a defined process for emergency releases and post-mortem analyses
• External parties can easily report vulnerabilities (contact page, security.txt)
• SBOMs are generated automatically and monitored for vulnerabilities

What’s Transferable From This to You

The effort for September 11, 2026, is distributed unevenly. The reporting channels themselves — security.txt, contact page, CSAF path — are manageable in terms of effort. The process behind them, with responsibilities, a checklist and documented triage, takes longer to build and is what decides whether a 24-hour deadline is actually achievable. And the supply chain needs automation, because a manually maintained component list is out of date the moment it’s finished.

For the last two points, our SBOM scanning and supplier advisories come together in OPENVAS SECURITY INTELLIGENCE: one analysis in one place, instead of tracking feeds, spreadsheets and advisory pages separately.

If you want to hold your own implementation up against these points, there are two ways forward from here. Our overview of the Cyber Resilience Act summarizes requirements, deadlines and who’s affected, in case you’d like to work through the topic yourself first. And if one or more points from the checklist above are still open for you — whether that’s the CVD process, machine-readable advisories or automated SBOMs — talk to us directly about it.

 

Two weeks before Article 14 reporting becomes mandatory, the infrastructure behind it is still under construction. The Commission’s guidance is approved but not yet formally in force. The reporting platform is in testing, not live. Not one harmonised standard has a citation in the Official Journal.

Each of those gaps puts more weight on the one control that’s fully in your hands regardless of what Brussels, ENISA, or the standards bodies do next: knowing what’s actually running in your environment, and whether it’s being exploited. That’s what OPENVAS is built to answer.

The Commission’s guidance is out

On 27 July 2026, the European Commission approved its first formal guidance on applying the CRA: Communication C(2026) 5252 final, with a full Annex covering scope, free and open-source software, substantial modifications, support periods, and reporting obligations. Article 26 of the Regulation requires exactly this: guidance aimed squarely at helping microenterprises and SMEs comply, and the Annex delivers, with 67 worked examples.

Formal adoption follows once every EU-language version is ready. Here’s the Commission’s own language on that point: the guidance “will be formally adopted by the Commission at a later date, when all language versions are available. It is only from that moment that it will apply.” The content is locked in. The paperwork catches up.

Classification depends on your product’s actual core functionality, not its name or its marketing copy. The FOSS carve-outs work the way the draft guidance signalled earlier this year. We’ve covered the open-source provisions in detail in a separate post, since what counts as a “steward” and what that role obligates you to do deserves its own treatment.

The guidance existing removes any excuse for treating CRA compliance as theoretical. The Commission has said, in writing, what the rules mean, on a timeline that runs alongside the Regulation’s own staged applicability: Chapter IV since 11 June 2026, Article 14 reporting from 11 September 2026, full application from 11 December 2027.

The reporting platform is still being tested

Article 14 reporting obligations become legally binding on 11 September 2026, two weeks from now. ENISA’s Single Reporting Platform is scheduled to be operational by that date, ENISA’s own wording, not necessarily before it. The European Commission’s reporting-obligations page confirms functional and security testing are under way right now. ENISA will publish the platform’s dedicated URL once it’s ready, not before.

Onboarding guidance for registering as an “Assigned Representative” has been rolling out since 31 July, with updates continuing into late August. CSIRT validation of your registered representative runs in parallel with reporting, not as a gate. Cross-border information sharing between CSIRTs is automatic once a report lands. ENISA’s own advice is to register when you have an actual notification to file, not before.

A platform scheduled to be operational by the day it becomes mandatory, still in testing two weeks out, leaves little to no buffer for onboarding friction. Read the registration steps now. Know the notification process before you ever need to run it under a 24-hour clock.

The standards manufacturers were counting on aren’t published yet

As of late August 2026, no CRA harmonised standard has a reference in the Official Journal, for any product category. The underlying mandate is clear: standardisation request M/606, 41 standards across horizontal and vertical categories, accepted by CEN, CENELEC and ETSI under Commission Implementing Decision C(2025) 618 final of 3 February 2025.

The original deadlines split into three tracks. Type A, the framework principles that don’t carry presumption of conformity on their own, and the vulnerability-handling half of Type B were due 30 August 2026. Type C, the vertical, product-specific standards for Annex III and IV categories, was due 30 October 2026. A third date sits further out: 30 October 2027, for the other half of Type B, the cross-product standard meant to concretise the 13 essential requirements in Annex I, Part 1, the one most manufacturers outside Annex III and IV would actually rely on for presumption of conformity. That date comes from the CRA Expert Group’s own planning, as described by a member of the CRA Expert Group. It has not appeared in a published Commission decision.

The Commission published a draft amendment to the 2026 deadlines in early July 2026, pushing the Type A, vulnerability-handling, and Type C dates back roughly two months: 31 October 2026 and 31 December 2026. Whether the 2027 date for the other half of Type B shifts too is not confirmed either way. That amendment has not been formally adopted, and it is not yet in the Official Journal (draft Implementing Decision; CRA Evidence).

On the ground: 17 ETSI vertical drafts are under public enquiry, with comment periods closing between mid-September and mid-November. CEN and CENELEC’s horizontal standards are still in development.

For manufacturers of “important” class I products (VPNs, password managers, browsers, and similar categories) planning to self-assess against a published harmonised standard, there is nothing to point to yet, and the standard most of them would actually reach for, the cross-product Type B standard covering all 13 Annex I essential requirements, is not due until 2027 regardless of how the 2026 delay resolves.

Chapter IV opened the door for member states to formally designate conformity assessment bodies on 11 June 2026. The Commission’s own target for sufficient notified-body capacity is December 2026, and it describes that target explicitly as best-efforts, not a guarantee. Designation started three months ago. Build your assessment timeline around that.

The standards shortcut is delayed. The notified-body route is a system still ramping up. Plan for both.

Neither gap has to freeze your own preparation. The documentation, risk assessment, and vulnerability management work that any self-assessment or third-party audit will eventually check doesn’t wait on either route opening. OPENVAS builds that groundwork now: a daily-updated feed, CVSS-based prioritisation, and exportable, timestamped scan history, the same evidence trail a notified body or a future harmonised standard will expect to see.

What this means for you

None of the above is a reason to wait. It’s the opposite. The parts of the CRA that depend on the Commission, ENISA, or the European standards bodies are still in motion. The parts that depend on you, knowing what’s in your product estate, detecting active exploitation, producing a dated evidence trail on demand, are entirely in your hands today.

The Commission’s guidance defines “becoming aware,” the trigger for your 24-hour reporting clock, precisely: a manufacturer is deemed aware once, after assessing a suspicious event, it reaches a reasonable degree of certainty that a vulnerability is being actively exploited. That standard is explicitly modeled on the GDPR’s breach-notification threshold. You reach that certainty through active monitoring. There’s no retroactive reporting duty for vulnerabilities you already knew about before 11 September.

Raise this with whoever owns budget: continuous vulnerability management is the one part of this compliance picture fully within your control today. It’s what turns “we think we’re fine” into a dated evidence trail a regulator or notified body can actually check. OPENVAS delivers exactly that: scheduled scanning against a daily-updated feed, CVSS-based prioritisation, and exportable, timestamped reports that stand on their own, independent of any government platform’s launch schedule.

There’s a faster layer on top of that baseline, too. OPENVAS SECURITY INTELLIGENCE ingests CSAF advisories from trusted sources, vendors and national security bodies, for exactly the products in your estate, and correlates them against your software inventory to flag which advisories actually apply to you. When a 24-hour reporting clock starts, that’s the difference between checking a dozen vendor advisory pages by hand and having the analysis already sitting in one place.

Summary

The Commission’s guidance is approved in substance and will formally apply once translation is complete. The reporting platform manufacturers are supposed to use is still in testing, two weeks before it becomes mandatory. The harmonised standards that were meant to give manufacturers a self-assessment shortcut aren’t in the Official Journal yet, and neither the delay nor the notified-body capacity picture is fully settled. None of that changes what’s due on 11 September, or what “becoming aware” requires of you starting that day.

OPENVAS gives you the part of this you don’t have to wait on: a daily-updated vulnerability feed, CVSS-based prioritisation, and exportable, timestamped scan reports that document your detection posture regardless of what the regulatory infrastructure looks like on day one.

Read the full guide: The Complete Guide to the EU Cyber Resilience Act — all requirements, timelines, and penalties in one place.

 

When Wiz recently published its roundup of the Best Vulnerability Management Tools for 2026, something caught our attention, but didn’t surprise us: OPENVAS received a top spot and a great review. Wiz describes OPENVAS as the “open-source equivalent” to commercial vulnerability scanners. The review calls OPENVAS “the most comprehensive coverage available in a single platform”. We’ll take the compliment! But there are still a few points we would like to contest because they don’t quite capture the full Greenbone story.

What Wiz Reviewed

Wiz reviewed Greenbone’s free community edition of OPENVAS SCAN, which is appropriate for a review of open-source software (OSS) tools. However, the community edition comes with the limits of a free tier. OPENVAS is also available as an end-to-end enterprise product. Let’s review the differences:

	Community Edition	Enterprise Products
Setup	Installed from containers, Linux packages, or source code	Pre-configured and optimized virtual and hardware appliances
Detection feed	Selected consumer and OSS security checks	Extended list of OSS such as additional Linux distributions and Cisco, Microsoft, SAP, Fortinet, Citrix, and many more enterprise software products
Compliance	IT-Grundschutz	IT-Grundschutz, CIS Benchmarks, BSI-TR technical guidelines, and additional policy sets such as Post-Quantum Cryptographic policy scans
Update cadence	Regular updates	Daily updates
Service and support	Volunteer members of the Greenbone community forum	Guaranteed service and support response times with a Service Level Agreement (SLA), plus Professional Services

Open Source and Enterprise: Greenbone Is “Best of Both Worlds”

One of Greenbone’s biggest advantages is that organizations do not have to choose between open-source transparency and enterprise-grade deployment. Greenbone offers both sides of the equation: the transparency and flexibility associated with open-source software and purpose-built enterprise solutions designed for operational security environments. The openness matters. Source-code transparency provides visibility into the OPENVAS SCAN technology. This visibility simplifies security auditing and independent security testing.

The Greenbone ecosystem includes multiple community edition deployment options. Users can run the Community Containers, install natively on Kali Linux, or build components directly from source. But community deployments are only a small part of the Greenbone product offering. Greenbone provides optimized enterprise solutions for organizations that need commercially supported vulnerability management products. Our product line includes enterprise virtual appliances and dedicated hardware appliances.

You Don’t Need to Run Nmap Separately

Wiz correctly highlights Nmap as a robust discovery tool, noting that security practitioners rely on the tool for port scanning. But users don’t need to feed Nmap results into our scanner. Nmap scanning is already integrated into OPENVAS SCAN. Our scan workflow performs robust port discovery before vulnerability assessment.

OPENVAS SCAN includes configurable options for port detection that security teams can tune according to the requirements of the target environment. There is no need to stitch together separate service-discovery and vulnerability detection operations.

More Control Means a More Sophisticated Configuration

In addition to saying that OPENVAS has a “user-friendly console for intuitive control”, Wiz also claims that OPENVAS demands a steep learning curve. There may be some truth to that observation. On the flip side, OPENVAS SCAN is a sophisticated security platform with flexible features. Vulnerability management itself is sophisticated. Giving security teams more options for scan control inevitably introduces more flexibility than a scanner built around a simplified workflow.

OPENVAS SCAN provides granular scan controls and flexible options for configuring targets, scanning behavior, schedules, credentials, results, and operational workflows. For organizations that want automation or integration with virtually any other IT platform, the Greenbone Management Protocol (GMP) and Open Scanner Protocol (OSP) APIs enable extensive programmatic control over OPENVAS SCAN.

Yes, mastering a flexible security platform requires some learning. However, the payoff is that defenders can leverage versatility across very different operational contexts.

Prioritization Goes Beyond Finding CVEs

Finding vulnerabilities is only the first part of vulnerability management. Wiz correctly states that prioritization requires more context than raw severity alone. OPENVAS SCAN already provides important prioritization data, including CVSS severity information, EPSS exploit-probability scores, and CISA Known Exploited Vulnerabilities (KEV) status, helping defenders move from “What vulnerabilities exist?” toward “Which vulnerabilities deserve attention first?” And more risk prioritization tools are on the way!

Without giving away the details just yet, Greenbone will soon be announcing new risk-management capabilities designed to give defenders even better tools to understand, organize, and prioritize vulnerability risk.

Industry Leading Coverage and a Growing List of Scanning Tools

Wiz claims that OPENVAS has “limited coverage, scanning only basic endpoints and networks”. However, Greenbone’s subscription-based detection feed, the OPENVAS ENTERPRISE FEED, provides industry-leading vulnerability detection. Meanwhile, the OPENVAS COMMUNITY FEED provides extensive security coverage for Linux environments and many other widely deployed open-source applications and software stacks.

OPENVAS SCAN is not simply performing a network-surface sweep of a few endpoints. Authenticated scanning delves deep into user space to detect vulnerabilities that cannot be identified from the outside. Containers must also be checked for vulnerabilities in the same way as other IT assets. OPENVAS SCAN can perform container image scans to audit a single container image, multiple container images, or a complete registry.

Since its founding in 2009, Greenbone AG has continuously maintained and advanced the Open Vulnerability Assessment System, better known as OpenVAS. As a result, the two names have become closely linked: mention Greenbone, and OpenVAS is often the first thing that comes to mind. Formerly known as the Greenbone Vulnerability Manager (GVM), OPENVAS SCAN has continued to evolve as well. Important feature upgrades include agent-based and hybrid scanning to complement the traditional agentless authenticated scanning model, container image scanning. Also, a new generation of risk-management capabilities are almost ready to hit the center stage. Greenbone’s product line is also expanding with OPENVAS SECURITY INTELLIGENCE, a new enterprise tool for centralized management, risk analysis, and remediation prioritization across distributed OPENVAS SCAN environments.

Yes, Windows and Linux, but So Much More!

Wiz also claims that OPENVAS is “primarily optimized for Linux and Windows operating systems.” But, that description overlooks how flexible Greenbone deployment actually is. OPENVAS SCAN can be deployed across a range of virtualization environments including, Oracle VirtualBox for macOS and type-1 hypervisors such as VMware ESXi, Proxmox Virtual Environment and Nutanix AHV.

Our supported hypervisor options include:

• Microsoft Hyper-V, version 8.0 or higher
• VMware vSphere Hypervisor (ESXi), version 7.0 or higher
• VMware Workstation Pro, version 17.0 or higher
• Oracle VirtualBox, version 7.0 or higher
• Huawei FusionCompute, version 8.0
• Proxmox Virtual Environment (VE), version 8.0 or higher
• Nutanix AHV, version 6.8 or higher

Already running Proxmox VE or Nutanix AHV? See how OPENVAS SCAN covers your hypervisor.

A Concluding Thanks to Wiz!

Even Wiz loves Greenbone! Here at Greenbone, we appreciate being listed among the leading vulnerability-management technologies for 2026. The Wiz review recognizes what many of our customers and users already know: OPENVAS is the pinnacle of industry-leading, open-source vulnerability-management platforms. We are also happy to help clarify a few parts of that picture.

Let’s be clear: Greenbone’s open-source transparency goes hand-in-hand with top-notch enterprise deployment. Vulnerability management extends far beyond default scan configurations and push-button scans. Sure, OPENVAS SCAN has these. But powerful configuration options should not be mistaken for unnecessary complexity. Greenbone’s existing risk-prioritization tools support defenders with core risk metrics after vulnerabilities have been discovered.

Be on the lookout for several new features that will extend the number of options that defenders have for prioritized risk-driven vulnerability management and exposure management! Contact Greenbone’s sales team to discuss how enterprise-grade compliance scanning with OPENVAS SCAN can best support your organization’s regulatory and security governance requirements.

 

Broadcom published VMSA-2026-0006 on July 29th, 2026, to address five vulnerabilities affecting VMware ESX, VMware vCenter Server, VMware Workstation, and VMware Fusion. The highest-risk issues are CVE-2026-59309 (CVSS 9.8) and CVE-2026-59310 (CVSS 9.8) affecting VMware vCenter Server. Both can be exploited by an unauthenticated attacker with network access to achieve remote code execution (RCE).

Technical details for CVE-2026-59310 and CVE-2026-59309 were published immediately after their disclosure, but no proof-of-concept exploits are publicly available. On August 11th, Defused Cyber reported probing for CVE-2026-59309. QUIRSO GmbH reports that in-the-wild exploitation of CVE-2026-59309 and CVE-2026-59310 is already underway [1][2][3]. Neither CVE is on CISA’s Known Exploited Vulnerabilities (KEV) list. Numerous national CERT agencies have issued alerts [4][5][6][7][8][9][10][11][12][13][14][15][16][17][18].

The VMSA-2026-0006 advisory also disclosed three additional flaws. CVE-2026-47876 (CVSS 9.3) is an out-of-bounds write flaw affecting the ESX VMXNET3 network adapter. Exploitation can allow a guest administrator to execute code on the host. The other two flaws are CVE-2026-41703 (CVSS 7.6) affecting VMware ESX, Workstation, and Fusion, and CVE-2026-41709 (CVSS 2.7) affecting ESX.

A Risk Assessment of VMware vCenter and ESX Vulnerabilities in VMSA-2026-0006

Technical details for CVE-2026-59310 and CVE-2026-59309 affecting VMware vCenter Server were published immediately after their disclosure, but no proof-of-concept exploits are publicly available. Both CVEs can be exploited remotely by an attacker without authentication. Public reporting indicates that in-the-wild exploitation of both CVEs is already underway [1][2][3].

VMware vCenter Server poses high risk because it provides centralized management of virtualized hosts and virtual machines from a single console. In practical terms, a compromise of VMware vCenter Server can affect a management layer for critical virtual machine hosts and workloads.

The ESX issues present a different but still important risk profile. CVE-2026-47876 requires local administrative control inside a guest VM that uses the VMXNET3 adapter. However, the consequence is high—host-level code execution. CVE-2026-41703 requires VM deployment privileges and can cause information disclosure or trigger a Denial of Service (DoS) condition in the host process. CVE-2026-41709 is low severity, but it weakens audit visibility by allowing certain administrator actions to bypass logging.

CVE-2026-59309: Actively Exploited vCenter Authentication Bypass

CVSS 9.8 · CriticalActively exploited

An attacker with network access to VMware vCenter Server can bypass authentication and gain unauthorized access to the system. The root cause is incorrect implementation of an authentication algorithm [CWE-303]. The flaw affects the VMware Directory Service.

CVE-2026-59310: Actively Exploited vCenter Directory Traversal RCE

CVSS 9.8 · CriticalActively exploited

A directory traversal flaw in the VMware vCenter Server Syslog component allows an unauthenticated remote attacker to execute arbitrary code. The root cause is improper limitation of a pathname to a restricted directory [CWE-22].

Other CVEs Disclosed in VMSA-2026-0006

The VMSA-2026-0006 advisory also disclosed three additional, lower-severity flaws affecting VMware ESX, Workstation, and Fusion:

The three additional CVEs disclosed in VMSA-2026-0006, each shown with its CVSS severity band and EPSS exploitation-probability score

CVE-2026-47876

CVSS 9.3 · Critical EPSS 0.281% (20th)

A critical out-of-bounds memory write condition [CWE-787] in the VMware ESX VMXNET3 virtual network adapter. Exploitation allows an attacker with local admin privileges on a VM to execute code on the ESX host. The flaw only affects guest VMs using the default VMXNET3 adapter. Other network adapters are not reported to be affected by CVE-2026-47876.

CVE-2026-41703

CVSS 7.6 · High EPSS 0.556% (44th)

An out-of-bounds read flaw [CWE-125] that allows information disclosure or DoS of the host process. Exploitation requires VM deployment privileges. CVE-2026-41703 affects VMware ESX as well as VMware Workstation and Fusion. Broadcom reports that the impact on VMware Workstation and VMware Fusion is restricted to information disclosure.

CVE-2026-41709

CVSS 2.7 · Low EPSS 0.382% (31st)

A low-severity issue in VMware ESX causes certain operations not to be logged [CWE-778].

Mitigation for CVEs Disclosed in VMSA-2026-0006

Organizations should map their installed versions to the affected and fixed releases in Broadcom’s VMSA-2026-0006 advisory and apply the vendor-provided updates. No workarounds are available for any of the CVEs.

CVE-2026-59309 and CVE-2026-59310 are the most urgent because both are exploitable to an unauthenticated attacker with network access to an affected VMware vCenter instance. CVE-2026-47876 should be prioritized where VMware ESX guest VMs use the VMXNET3 adapter because exploitation allows virtual machine escape and code execution on the ESX host. CVE-2026-41703 should have increased priority for VMware ESX instances that manage critical operations since it can be exploited to trigger DoS conditions. The VMware ESX flaw CVE-2026-41709 should be patched where audit completeness is important.

Summary

Broadcom’s VMSA-2026-0006 bundles five VMware vulnerabilities across VMware vCenter Server, VMware ESX, VMware Workstation, and VMware Fusion. The highest-risk exposure is concentrated in CVE-2026-59310 and CVE-2026-59309. Both are critical-severity and actively exploited flaws affecting VMware vCenter Server [1][2][3].

Greenbone’s OPENVAS ENTERPRISE FEED addresses CVE-2026-59309 and CVE-2026-59310 with a remote banner version check for VMware vCenter Server. It also includes VMware ESXi package-level detection for CVE-2026-41703 [1], CVE-2026-47876 [2], and CVE-2026-41709 [3]. For defenders seeking to detect and protect, a trial copy of OPENVAS SCAN includes a free two-week trial of the OPENVAS ENTERPRISE FEED. Greenbone’s cyber security products are a surefire way to gain the deepest insight into where software vulnerabilities exist across your organization’s infrastructure.

 

Plenty of new risks to enterprise IT defenders emerged in July 2026. Earlier this month, our blog covered emerging issues such as active exploitation of WordPress Core [2], Adobe ColdFusion [3] and Check Point SmartConsole [4]; new critical-severity flaws in Cisco products [5], BeyondTrust RS and PRA [6], and Citrix NetScaler ADC and Gateway [7]; and a flood of Linux CVEs that include new active exploitation [8][9]. In this blog post, we will briefly examine the so-called “vulnpocalypse“ and cover the highest-risk software vulnerabilities that have not already been covered on our blog.

For defenders seeking to detect and protect, a trial copy of OPENVAS SCAN includes a free two-week trial of the OPENVAS ENTERPRISE FEED. Greenbone’s cyber security products are a surefire way to gain the deepest insight into where software vulnerabilities exist across your organization’s infrastructure.

For those embroiled in the AI cyber security hype cycle, waves of AI vulnerability reports are swamping inboxes. Even defenders focused simply on patching and protecting their IT infrastructure have been inundated by unusually voluminous vulnerability disclosures affecting widely deployed software [1][2][3][4]. Are we waiting for the dust to settle, or will the storm gain even more momentum?

It’s prudent to ask: Is the so-called “vulnpocalypse” making an everlasting dent in the number of software bugs that defenders need to fear going forward? Or is the IT industry merely scratching the surface of accumulated technical debt? Again, only time will reveal the true level of exposure. Finally, as CISA points out in its new security guidance for Open Source Software, trust should be a key driver when selecting and deploying enterprise software.

CVE-2026-6875: ServiceNow AI Platform Actively Exploited

CVE-2026-6875 (CVSS 7.6, EPSS ≥ 98th pctl) allows an unauthenticated attacker to achieve remote code execution (RCE) by escaping the server-side script sandbox in the ServiceNow AI Platform if the assessment_thanks.do endpoint is reachable. The unauthenticated assessment_thanks.do endpoint passes the attacker-controlled sysparm_assessable_type parameter into the GlideRecord.addQuery() function. Values prefixed with javascript: are evaluated in ServiceNow’s Rhino script sandbox. Attackers can leverage the gs.include() function and shared global JavaScript objects to escape the sandbox boundary.

Exploitation allows full compromise of a ServiceNow instance and connected proxy servers. In-the-wild exploitation has been reported. Although CVE-2026-6875 is not on CISA’s KEV list, two previous ServiceNow CVEs were added in 2024. A public proof-of-concept exploit and detailed technical analysis are available, increasing the risk of cyber attacks. Several national CERT agencies have issued alerts for CVE-2026-6875 [1][2][3][4][5].

No workaround mitigations are described by the vendor. However, a Cloud Security Alliance (CSA) report refers to standard mitigation measures: restricting network access via firewall rules, or using web application firewall (WAF) to block exploitation attempts. Self-hosted ServiceNow users must upgrade to Australia Patch 2; Yokohama Patch 12 Hot Fix 1b or Patch 13; Zurich Patch 7b or Patch 9; or Brazil EA or GA. Patched releases remove the vulnerable behavior and introduce a sandbox-hardening feature named Guarded Script. ServiceNow also recommends reviewing logs for suspicious unauthenticated script execution or access to the assessment_thanks.do endpoint.

Greenbone’s OPENVAS ENTERPRISE FEED includes a remote banner check to identify ServiceNow instances affected by CVE-2026-6875.

Emerging Risks to Microsoft Products: More Active Exploitation

Microsoft products faced renewed exploitation pressure in July, led by actively exploited SharePoint flaws. A public PoC for an Exchange Server vulnerability adds further urgency for defenders.

CISA Warns of Microsoft SharePoint Exploit Campaigns

An out-of-band Microsoft security advisory in July 2026 disclosed 37 unique CVEs affecting SharePoint, with impacts such as RCE, privilege escalation, spoofing, and information disclosure. In July, CISA also warned that threat actors are leveraging several CVEs in Microsoft SharePoint Server Subscription Edition, 2019, and 2016 to gain unauthorized access and achieve RCE. Post-exploitation activity includes stealing IIS machine keys, abusing ASP.NET view state deserialization, and deploying malware.

The highest-risk SharePoint CVEs published in July 2026 are:

• CVE-2026-58644 (CVSS 9.8, EPSS ≥ 91st pctl): A remote attacker authenticated as a Site Owner or higher privilege level can execute arbitrary code on a Microsoft SharePoint Server. The flaw is caused by deserialization of untrusted data [CWE-502]. CVE-2026-58644 is considered actively exploited in the wild and was added to CISA’s KEV catalog two days after disclosure. Neither a public PoC exploit nor a full technical analysis is yet available for CVE-2026-58644.
• CVE-2026-50522 (CVSS 9.8, EPSS ≥ 99th pctl): Allows an unauthorized attacker to execute code over a network. The root cause is deserialization of untrusted data [CWE-502]. CVE-2026-50522 has been added to CISA’s KEV list.
• CVE-2026-56164 (CVSS 9.8, EPSS 97th pctl): Allows an unauthorized attacker to elevate privileges over a network. The root cause is missing authentication for a critical function [CWE-306]. Neither CISA or Microsoft have reported active exploitation. Detailed technical descriptions or PoC exploits are not publicly available.
• CVE-2026-55040 (CVSS 9.1, EPSS ≥ 69th pctl): Weak authentication [CWE-1390] allows an unauthorized attacker to bypass a security feature over a network. Neither CISA or Microsoft have reported active exploitation. Detailed technical descriptions or PoC exploits are not publicly available.

CISA’s alert on new attacks targeting SharePoint provides additional recommendations for defenders. These include shortening patching cycles, enabling Antimalware Scan Interface (AMSI) for each SharePoint site, restricting SharePoint Central Administration, farm and database communications to only required systems, avoiding exposure of SharePoint Servers to the public internet, and more. Organizations should patch promptly because exposed SharePoint servers remain attractive enterprise targets. Greenbone’s OPENVAS ENTERPRISE FEED includes regular vulnerability detection across many Microsoft products, including all the CVEs referenced above.

CVE-2026-45504: Public PoC Exploit for Microsoft Exchange Server 2019

CVE-2026-45504 (CVSS 8.8) allows authenticated, low-privileged users to read arbitrary files from on-premises Microsoft Exchange Server 2019. The CVE is classified as a Server-Side Request Forgery (SSRF) flaw [CWE-918]. The root cause is missing URL scheme validation in the OneDrive and WOPI integration. Using a malicious Exchange Web Services (EWS) reference attachment and WOPI response, an attacker can force Exchange to process a malicious file URI. Exploitation allows an attacker to bypass appended OAuth parameters and gain access to configuration files, credentials, and other sensitive local data.

No active exploitation, ransomware use, or associated campaigns have been reported. However, a detailed technical analysis and PoC exploit code are publicly available, increasing the risk. Several national CERT agencies have issued alerts for CVE-2026-45504 [1][2][3][4][5][6][7][8]. For defenders seeking to detect and protect, the OPENVAS ENTERPRISE FEED includes:

• A remote version check for Microsoft Exchange Server 2016, Server 2019, and Subscription Edition (SE)
• An executable version check for Microsoft Exchange Server 2016 Cumulative Update 23
• Executable version checks for Microsoft Exchange Server 2019 Cumulative Update 14 and 15 [1][2]

Living on the Edge: Emerging Threats to Perimeter Security

Vulnerabilities in network perimeter devices are particularly high risk because they are exposed to attack by arbitrary remote attackers. According to the latest Verizon DBIR 2026 report, exploiting publicly exposed software vulnerabilities is now the most common vector for initial access globally. Here are some of the most critical emerging threats to perimeter devices in July 2026.

SonicWall SMA 1000 Appliances Actively Exploited

CVE-2026-15409 and CVE-2026-15410 were both published on July 14th, 2026, and added to CISA’s KEV list on the same day [1][2]. The CVEs affect SonicWall Secure Mobile Access (SMA) 1000 Series models 6210, 7210, and 8200v. According to a forensic report, exploitation of the flaws began well before their disclosure. Full technical analysis [3][4] and PoC exploits [5][6] are available for CVE-2026-15409. Numerous national CERT agencies have issued alerts globally [7][8][9][10][11][12][13][14][15][16][17][18][19][20]. SonicWall SMA 1000 is on CISA’s KEV list 17 times, 10 entries associated with ransomware attacks, indicating high risk.

The SMA 1000 Series functions as an enterprise secure-access gateway that combines SSL VPN and Zero Trust controls to connect remote users to internal, cloud-hosted, and hybrid applications. Details on each new actively exploited CVE are included below:

• CVE-2026-15409 (CVSS 10, EPSS = 100th pctl): A maximum-severity flaw that allows unauthenticated attackers to execute Server-Side Request Forgery (SSRF) [CWE-918] attacks via the Work Place interface. The root cause is a vulnerable /wsproxy endpoint that processes User-Agent and bmID values to establish WebSocket tunnels to services accessible only through the appliance’s loopback interface.
• CVE-2026-15410 (CVSS 7.2, EPSS ≥ 99th pctl): Allows authenticated administrators to inject code into the Appliance Management Console to execute arbitrary OS commands [CWE-94] with root-level privileges. The root cause is a flawed hotfix-removal workflow that allows path traversal [CWE-35] to execute an attacker-supplied shell script as root.

Chaining the two flaws provides unauthenticated, root-level control of an affected SMA 1000 appliance as described below:

• Initial access: An unauthenticated attacker exploits CVE-2026-15409 in the /wsproxy WebSocket proxy by supplying a crafted host parameter, forcing the appliance to connect to local-only services such as the internal Erlang process on port 1050.
• Privilege escalation: The attacker then exploits CVE-2026-15410 by sending a path-traversal payload to rollbackConfirm.action, causing the hotfix-removal workflow to execute an attacker-provided shell script as root before rebooting.

After gaining root, the attackers deployed custom malware for code execution and covert tunneling, installed web shells for remote access, and added persistence mechanisms to maintain root access. Malicious Java components were injected into a legitimate SonicWall process to evade routine monitoring, and packet-capture tooling was used to collect LDAP credentials and expand access to internal directory services [21].

No workarounds are described by the vendor. SonicWall strongly recommends immediately installing the applicable platform hotfix and investigating for signs of compromise. Greenbone’s OPENVAS ENTERPRISE FEED includes a remote banner version check to detect both CVEs and an active check specific to CVE-2026-15409.

CVE-2026-20316: Cisco Secure Firewall Management Center (FMC) Actively Exploited

CVE-2026-20316 (CVSS 5.3) allows an unauthenticated, remote attacker to log in to an affected device as a low-privileged user via hardcoded user credentials [CWE-259]. The flaw affects the web interface of Cisco Secure Firewall Management Center (FMC) Software. Several cyber security experts expressed shock that hardcoded credentials remain in Cisco products.

CVE-2026-20316 is being actively exploited and was added to CISA’s KEV list the same day it was disclosed. The nominal CVSS score of 5.3 understates the operational risk. Cisco has assigned CVE-2026-20316 a Security Impact Rating (SIR) of High and specifically warns that the flaw can be combined with other FMC vulnerabilities to elevate privileges on unpatched devices. Several national CERT agencies have issued alerts for CVE-2026-20316 [1][2][3][4][5].

Cisco Secure FMC versions 7.0, 7.2, 7.4, 7.6, 7.7, and 10.0 are affected. Cisco has released hotfix patches for affected products. If patches cannot be applied, risk can be reduced by preventing public internet access to the FMC management interface. The OPENVAS ENTERPRISE FEED includes a remote banner check, allowing defenders to identify vulnerable devices.

New High-Risk Flaws Affecting Palo Alto Networks PAN-OS

Palo Alto Networks has released patches for 13 new CVEs. Eleven of the CVEs affect PAN-OS and various components that run on the operating system. The most critical new CVEs from Palo Alto Networks’ July 2026 disclosures are:

• CVE-2026-0284 (CVSS 9.9): An XML injection vulnerability in the Large Scale VPN (LSVPN) functionality of PAN-OS enables an unauthenticated attacker with network access to inject malicious XML content. Exploitation allows information disclosure or corruption of internal LSVPN satellite data.
• CVE-2026-0288 (CVSS 7.5): Multiple buffer overflow vulnerabilities in the User-ID Terminal Server Agent (TSA) component of PAN-OS allows an unauthenticated attacker with network access to cause a Denial of Service (DoS) condition or potentially execute arbitrary code by sending specially crafted network traffic. The security risk posed by this issue is minimized when the User-ID Terminal Server Agent connectivity is restricted to only trusted internal IP addresses

There are no reports of active exploitation for the new CVEs. However, organizations should promptly apply the latest updates and restrict access to sensitive services, particularly the User-ID Terminal Server Agent. See Palo Alto Networks’ security advisory page for affected versions and patches. Greenbone’s OPENVAS ENTERPRISE FEED includes authenticated scan detection for all of Palo Alto Networks’ new CVEs that impact PAN-OS and its components.

Two New Flaws Affecting Gitea Include Exploitation Attempts

Two new Gitea vulnerabilities present elevated risk among nine newly disclosed flaws. Of these, Sysdig has reported in-the-wild exploitation attempts targeting CVE-2026-20896.

Here are the details for both emerging high-risk CVEs:

• CVE-2026-20896 (CVSS 9.8): Unauthenticated remote attackers can bypass reverse-proxy authentication [CWE-284] to access repositories and secrets. Gitea’s official Docker image uses an app.ini template that hard-codes a wildcard allowlist (REVERSE_PROXY_TRUSTED_PROXIES=* ). Exploitation requires only access to the Gitea port and a valid username. CVE-2026-20896 is reportedly being actively exploited against internet-accessible instances. Several PoC exploits have been published [1][2][3]. Gitea’s official Docker images before version 1.26.3 are affected.
• CVE-2026-27771 (CVSS 8.2): Unauthenticated remote attackers can pull private container images. The root cause is a broken authorization design [CWE-862] in which anonymous JSON Web Tokens (JWTs) are accepted by ungated registry read endpoints, while package visibility was never bound to repository privacy. Exploitation may allow disclosure of credentials, API keys, TLS certificates, production configurations, and compiled source code. A detailed technical analysis [4] and PoC exploit code [5] are available. Gitea’s built-in OCI container registry before version 1.26.2 are affected.

An estimated ~31,000 Gitea instances are publicly exposed globally. The OPENVAS ENTERPRISE FEED includes a remote banner check and a remote application check for CVE-2026-20896 [6][7], as well as a separate remote banner check and an active check to identify Gitea instances affected by CVE-2026-27771 [8][9].

CVE-2026-63077: Critical Flaw Affecting JetBrains TeamCity On-Premises

CVE-2026-63077 (CVSS 9.8, EPSS ≥ 47th pctl) allows unauthenticated RCE against all previous versions of TeamCity On-Premises. The root cause is deserialization of untrusted data [CWE-502] in the agent polling protocol. Successful exploitation allows an attacker to execute commands with the privileges of the TeamCity server process. A compromise could expose stored credentials, alter build artifacts, and compromise downstream CI/CD pipelines.

No active exploitation, public PoC, or full exploit-level technical disclosure had been reported for CVE-2026-63077 as of August 1st, 2026. However, TeamCity has been added to CISA’s KEV list three times, each entry associated with ransomware attacks. Greenbone’s OPENVAS ENTERPRISE FEED includes a remote banner version check to identify unpatched versions of TeamCity On-Premises. Organizations should update to version 2025.11.7 or 2026.1.3, or enable the automatic updates option within TeamCity. For organizations unable to upgrade, a security patch is available.

CVE-2026-14266: 7-Zip Flaw Allows Remote Code Execution

CVE-2026-14266 (CVSS 7.0) is a newly disclosed flaw affecting 7-Zip versions before 26.02. The flaw allows remote attackers to execute arbitrary code. The root cause is incorrect writable-space tracking in the XZ decoder, which can lead to a heap-based buffer overflow [CWE-122]. Each decoder invocation is incorrectly given the full output-buffer size, causing decoders to overestimate the remaining writable space after partial output. Exploitation requires a target to open a malicious XZ archive. The impact is code execution with the current user’s privileges.

There are no reports of active exploitation. However, a detailed technical write-up with a PoC exploit generator is publicly available. The existence of public PoC exploit generator, even in the early stages of development, means that low-skilled attackers may soon be able to leverage CVE-2026-14266 for real-world attacks. In fact, 7-Zip flaws are known to be used in social engineering cyber attacks [1][2].

Germany’s BSI and Italy’s ACN national CERT agencies have issued alerts for CVE-2026-14266 [3][4]. Users should upgrade to 7-Zip version 26.02 or later. The OPENVAS ENTERPRISE FEED includes a Windows registry check to identify systems with 7-Zip installed. CVE-2026-14266 also impacts embedded 7-Zip components in third-party products. Greenbone will continue to add Linux package detection checks and other application-specific checks as downstream vendors issue security advisories.

CVE-2026-53412: Unauthenticated Remote Account Takeover Affecting Zoom Workplace

Zoom’s July 2026 security advisories disclose new flaws affecting Zoom Workplace and other core Zoom applications. The primary risk is CVE-2026-53412, which enables unauthenticated remote account takeover without user interaction and is described as having low attack complexity. No active exploitation has been reported, and no detailed technical analysis, or PoC exploits are publicly available.

• CVE-2026-53412 (CVSS 9.8): Allows an unauthenticated remote attacker to take over accounts through improper input validation. CVE-2026-53412 affects Zoom Workplace for Windows before 7.0.0 and Zoom Workplace VDI Client for Windows before the applicable fixed versions.
• CVE-2026-53410 (CVSS 7.0): Allows an authenticated local attacker to escalate privileges through a Time-of-Check to Time-of-Use (TOCTOU) race condition in the installation or removal processes of multiple Zoom Windows products. Affected products include Zoom Workplace, VDI Client, VDI Plugin, Zoom Rooms, and Remote Control for Zoom Contact Center for Windows.

Greenbone’s OPENVAS ENTERPRISE FEED includes registry checks to identify installations of Zoom Workplace for Windows that are vulnerable to CVE-2026-53412 [1] or CVE-2026-53410[2].

Summary

Emerging cyber security risks in July 2026 show attackers exploiting high-impact flaws across enterprise platforms, perimeter devices, development tools, and widely used applications. Amid the so-called “vulnpocalypse“ pressure, security teams should maintain high visibility and increase patch cadence with a priority given to exposed systems. Defense-in-depth becomes critical when attackers gain initial access.

For defenders seeking to detect and protect, a trial copy of OPENVAS SCAN includes a free two-week trial of the OPENVAS ENTERPRISE FEED. Greenbone’s cyber security products are a surefire way to gain the deepest insight into where software vulnerabilities exist across your organization’s infrastructure.