The so-called Vulnpocalypse is now in full force. This August 2026 threat report only scratches the surface of new high-risk vulnerabilities that emerged in August 2026. To see how Greenbone’s industry leading vulnerability detection can benefit your IT security operations, visit our SecInfo portal and view our complete coverage portfolio.

August reinforced a now too familiar pattern: high-impact vulnerabilities in common enterprise software offerings are moving rapidly from disclosure to exploitation. The following sections highlight the vulnerabilities and related attack campaigns that demand immediate attention.

Microsoft: New Actively Exploited CVEs, Espionage, Ransomware, and PoCs

Microsoft’s August 2026 patch release was another large disclosure. Of 457 new CVEs, 36 were assigned a critical-severity CVSS score. 80 were assigned an EPSS score above the 50th percentile and 16 above the 80th percentile. Microsoft designated 34 of the CVEs as “Exploitation More Likely“. Earlier in August, the Greenbone blog covered an espionage campaign leveraging CVE-2026-68820 (CVSS 7.0, EPSS ≥ 93rd pctl), which affects the Windows Ancillary Function Driver for WinSock.

The newly disclosed CVE-2026-33824, which affects the Windows IKE Extension was added to CISA’s KEV list, along with CVE-2026-55040, affecting SharePoint, which was first disclosed in July. In addition to these new CVEs, and older vulnerability, CVE-2019-1068, affecting Microsoft SQL Server was also added to CISA’s KEV list. CISA also added ransomware distinctions to CVE-2026-45659, a deserialization flaw [CWE-502] affecting Microsoft SharePoint Server, and CVE-2025-60710, a Windows link-following flaw [CWE-59] allowing privilege escalation [1][2].

Microsoft’s battle with zero-day disclosures from third-party security researchers also continued into August 2026 [1][2][3]. Additional high-risk threats to Microsoft environments that emerged in August 2026 include:

• CVE-2026-54121 (CVSS 8.8, EPSS ≥ 77th pctl): Dubbed “Certighost”, the flaw is caused by improper authorization [CWE-285] in Active Directory Certificate Services (AD CS). An authenticated attacker can obtain a certificate from AD CS and then elevate privileges via Kerberos. Detailed technical analysis [4][5] and a PoC exploit [6] are publicly available, increasing the risk of attacks.
• CVE-2026-70329 (CVSS 8.8, EPSS ≥ 50th pctl): An integer overflow [CWE-190] in Microsoft Office Outlook allows an attacker to execute code over a network via social engineering; the victim must open a malicious Office file.
• CVE-2026-42897 (CVSS 6.1, EPSS ≥ 99th pctl): An Outlook Web Access (OWA) XSS flaw was used to target government, telecommunications, financial, hospitality, and aerospace organizations [7]. Opening a malicious email in OWA was sufficient to execute attacker-controlled JavaScript. Attackers deployed OWAReaper, a browser-resident JavaScript implant to steal credentials and OAuth tokens, maintain persistent access to the victim’s computer, execute arbitrary commands, and exfiltrate data over HTTPS and DNS tunneling.

The four additional high-risk Microsoft CVEs from August 2026, each shown with its CVSS severity band and EPSS exploitation-probability score

CVE-2026-68820

CVSS 7.0 · High EPSS 6.2% (93rd)

Affects the Windows Ancillary Function Driver for WinSock; exploited in an espionage campaign combining social engineering with this Windows privilege-escalation flaw.

CVE-2026-54121

CVSS 8.8 · High EPSS 1.8% (77th)

Dubbed “Certighost” — an improper authorization [CWE-285] flaw in Active Directory Certificate Services (AD CS) lets an authenticated attacker obtain a certificate and elevate privileges via Kerberos.

CVE-2026-70329

CVSS 8.8 · High EPSS 0.7% (50th)

An integer overflow [CWE-190] in Microsoft Office Outlook lets an attacker execute code via a malicious Office file opened through social engineering.

CVE-2026-42897

CVSS 6.1 · Medium EPSS 71.2% (99th)

An Outlook Web Access XSS flaw let attackers execute JavaScript via a single malicious email, deploying the OWAReaper implant to steal credentials and OAuth tokens.

Greenbone’s OPENVAS ENTERPRISE FEED includes regular vulnerability detection across many Microsoft products, including all the CVEs referenced above.

New Cisco Risks: Critical Flaws, Public PoCs, and New Attacks

Cisco disclosed several high-risk vulnerability clusters in August 2026 spanning its firewall, network-management, endpoint-security, server-management, and workload-security products. The vendor chose to group the new vulnerabilities by Common Weakness Enumeration (CWE) class and release multiple flaws under a single CVE identifier. This practice was officially discouraged recently by the CVE program.

Greenbone’s OPENVAS ENTERPRISE FEED provides regular detection checks for vulnerabilities in Cisco products. Here are some of the most significant risks affecting Cisco products from August 2026:

CVE-2026-20349: Secure Firewall ASA/FTD: Actively Exploited for DoS

CVSS 8.6 · HighEPSS 2.2% (81st)Actively exploitedIn CISA KEV

CVE-2026-20349 (CVSS 8.6, EPSS ≥ 81st pctl) affects the Remote Access SSL VPN service in Cisco Secure Firewall Adaptive Security Appliance (ASA) and Secure Firewall Threat Defense (FTD). An unauthenticated remote attacker can use a crafted HTTP request to cause a denial-of-service (DoS) condition on affected devices. Exploitation requires the IKEv2 Remote Access VPN with client services, SSL VPN, or, on FTD, Zero Trust Network Access to be enabled.

The CVE has been added to CISA’s KEV, indicating active exploitation. According to Cisco, there are no workarounds, making available hotfixes the primary remediation. See the official advisory for more information.

Integrated Management Controller: Authenticated Root-Level RCE Has Public Exploit

CVSS 8.8 · HighEPSS 5.7% (93rd)No known exploitationPublic PoC

CVE-2026-20200 (CVSS 8.8, EPSS ≥ 93rd pctl) is an argument-injection vulnerability in the web interface of Cisco Integrated Management Controller (IMC). A low-privilege attacker can manipulate parameters used when IMC retrieves an SSH public key, inject additional curl arguments, and ultimately execute arbitrary commands with root privileges.

Several technical explanations [1][2] and a PoC exploit toolkit are publicly available [3]. The PoC supports arbitrary file upload and download, and reverse-shell command execution. Active exploitation has not been reported. The risk is also amplified because IMC operates below the host OS and can interact with firmware, BIOS, and Secure Boot.

No workarounds are available. See the official advisory for more information, including a full list of affected products.

Seven ClamAV Flaws: CVE-2026-20337 Has a Public Exploit

Seven ClamAV parsing flaws affect Secure Endpoint Connector and can allow unauthenticated remote attackers to submit malicious ZIP, PESpin, GPT, PDF, Mach-O, or XAR content to crash the ClamAV process. Cisco rates the impact higher on Windows because ClamAV executes in a privileged security context, while Linux and macOS connectors run it with lower privileges. Most importantly, Cisco PSIRT confirms the existance of public PoC exploit code for CVE-2026-20337 and CVE-2026-20338. No active exploitation has been reported.

Catalyst SD-WAN: Multiple Critical Vulnerability Groups

Cisco has addressed five CVE groups affecting Catalyst SD-WAN in all configurations. CVE-2026-20303 and CVE-2026-20304 (both rated CVSS 9.9) cover improper input validation [CWE-20] and improper access control [CWE-284] vulnerabilities, respectively. CVE-2026-20310 (CVSS 9.1) covers improper link resolution flaws [CWE-59]. CVE-2026-20312 (CVSS 8.8) and CVE-2026-20313 (CVSS 7.7) cover cleartext storage of sensitive information [CWE-312] and improper input-quantity validation [CWE-1284].

The five Cisco Catalyst SD-WAN CVE groups from August 2026, each shown with its CVSS severity band and EPSS exploitation-probability score

CVE-2026-20303

CVSS 9.9 · Critical EPSS 0.3% (25th)

Improper input validation [CWE-20] in Cisco Catalyst SD-WAN.

CVE-2026-20304

CVSS 9.9 · Critical EPSS 0.3% (20th)

Improper access control [CWE-284] in Cisco Catalyst SD-WAN.

CVE-2026-20310

CVSS 9.1 · Critical EPSS 0.4% (34th)

Improper link resolution [CWE-59] in Cisco Catalyst SD-WAN.

CVE-2026-20312

CVSS 8.8 · High EPSS 0.3% (18th)

Cleartext storage of sensitive information [CWE-312] in Cisco Catalyst SD-WAN.

CVE-2026-20313

CVSS 7.7 · High EPSS 0.3% (19th)

Improper input-quantity validation [CWE-1284] in Cisco Catalyst SD-WAN.

No detailed technical information or PoC exploits are publicly available. No active exploitation has been reported. No workarounds are available. See the official advisory for more information.

CVE-2026-20272: Unauthenticated Injection in IOS XE

CVSS 9.8 · CriticalEPSS 0.4% (34th)No known exploitation

Cisco published seven vulnerability groups that affect IOS XE running in autonomous or controller mode in all configurations. The standout is CVE-2026-20272 (CVSS 9.8), a group caused by improper neutralization of special elements [CWE-74] that contains at least one unauthenticated, network-exploitable item. No detailed technical information or PoC exploits are publicly available. No active exploitation has been reported. No workarounds are available. See the official advisory for more information.

CVE-2026-72898: CVSS 10 Flaw in Metabase Actively Exploited

CVSS 10 · CriticalEPSS 82.3% (100th)Actively exploitedIn CISA KEVPublic PoC

CVE-2026-72898 (CVSS 10, EPSS = 100th pctl) is an SQL injection flaw [CWE-89] that allows an unauthenticated remote attacker to inject arbitrary SQL commands via the /reset_password endpoint. Exploitation allows administrator access to the connected Metabase instance. CVE-2026-72898 has been added to CISA’s KEV list. Several detailed technical analyses [1][2][3] and PoC exploits [4][5][6] are publicly available. Security firm VeraniX identified 15 victims by August 10th. However, the list has likely grown significantly.

Greenbone’s OPENVAS ENTERPRISE FEED includes a remote banner check for CVE-2026-72898 and other CVEs included in the recent patch to Metabase. The vendor advises blocking access to the /api/session/reset_password endpoint as a temporary mitigation until upgrading is possible. A table showing affected versions is included below, and users should urgently upgrade to a patched version.

Edition	Release Branch	Affected Versions	Patched Version
Metabase OSS	0.58.x	Prior to 0.58.24	0.58.24 or later
Metabase OSS	0.59.x	Prior to 0.59.21	0.59.21 or later
Metabase OSS	0.60.x	Prior to 0.60.17	0.60.17 or later
Metabase OSS	0.61.x	Prior to 0.61.11	0.61.11 or later
Metabase OSS	0.62.x	Prior to 0.62.9	0.62.9 or later
Metabase OSS	0.63.x	Prior to 0.63.5	0.63.5 or later
Metabase Enterprise	1.58.x	Prior to 1.58.24	1.58.24 or later
Metabase Enterprise	1.59.x	Prior to 1.59.21	1.59.21 or later
Metabase Enterprise	1.60.x	Prior to 1.60.17	1.60.17 or later
Metabase Enterprise	1.61.x	Prior to 1.61.11	1.61.11 or later
Metabase Enterprise	1.62.x	Prior to 1.62.9	1.62.9 or later
Metabase Enterprise	1.63.x	Prior to 1.63.5	1.63.5 or later

CVE-2026-60004: Gitea Actively Exploited Again

CVSS 9.8 · CriticalEPSS 86.8% (100th)Actively exploitedIn CISA KEVPublic PoC

In July, our blog reported active exploitation of Gitea. Since then, CVE-2026-60004 (CVSS 9.8, EPSS ≥ 100th pctl) has been disclosed and added to CISA’s KEV list. The new flaw affects Gitea before version 1.27.1. Exploitation allows RCE via the diffpatch API during Git hook installation. Gitea and a third party have published PoC exploits [1][2], increasing the risk.

The OPENVAS ENTERPRISE FEED includes a remote banner check for CVE-2026-60004. Users should upgrade to Gitea version 1.27.1 immediately.

CVE-2026-73570: New Actively Exploited Zimbra Flaw

CVSS 8.9 · HighEPSS 32.4% (98th)Actively exploitedIn CISA KEV

CVE-2026-73570 (CVSS 8.9, EPSS ≥ 98th pctl), affecting Zimbra Collaboration Suite (ZCS) was published in mid-August and quickly added to CISA’s KEV list. In total, nine security issues were patched in the ZCS version 10.1.20 release. The root cause is improper sanitization of untrusted input during SNMP notification processing. Exploitation of CVE-2026-73570 allows an unauthenticated attacker to achieve RCE as the ZCS process via specially crafted SMTP requests when the optional zimbra-snmp package is installed and SNMP notifications are enabled.

The OPENVAS ENTERPRISE FEED includes a remote banner check that covers all recent security issues affecting ZCS. Users should upgrade to version 10.1.20 as soon as possible.

CVE-2026-34486: Apache Tomcat Actively Exploited

CVSS 7.5 · HighEPSS 98.6% (100th)Actively exploitedIn CISA KEVPublic PoC

CVE-2026-34486 (CVSS 7.5, EPSS = 100th pctl), disclosed in April, was added to CISA’s KEV list in early-August. Detailed technical analysis [1] and proof of concept exploit kits are publicly available [2][3], further increasing the risk of ongoing attacks.

The root cause is missing encryption of sensitive data [CWE-311], allowing the bypass of the EncryptInterceptor component of the Tribes clustering subsystem. EncryptInterceptor is used to encrypt and decrypt cluster communications between Tomcat nodes using a pre-shared key. CVE-2026-34486 was introduced by a flawed patch for CVE-2026-29146 and allows cluster traffic to bypass encryption, leaving inter-node communications in plaintext.

This issue affects Apache Tomcat versions 11.0.20, 10.1.53, 9.0.116. Tomcat users should upgrade to version 11.0.21, 10.1.54, or 9.0.117. The OPENVAS ENTERPRISE FEED includes numerous detection checks for CVE-2026-34486 across Linux distributions, general detection tests covering Tomcat servers for Windows and Linux, and other products that package Tomcat including: various Oracle and Dell products, Atlassian Jira, Apache OFBiz, IBM Storage Protect Plus.

CVE-2026-9198: IBM Langflow Actively Exploited

CVSS 9.8 · CriticalEPSS 57.0% (99th)Actively exploitedIn CISA KEVPublic PoC

CVE-2026-9198 (CVSS 9.8, EPSS ≥ 99th pctl) allows unauthenticated attackers to chain the /api/v1/auto_login and /api/v1/validate/code API endpoints to achieve RCE on default Langflow deployments. An attacker can chain these two flaws to obtain a SUPERUSER token and then submit malicious Python code to be executed. Exploitation can result in a complete compromise of the host.

20 CVEs were patched in total; six exploitable without authentication. However, only CVE-2026-9198 has been added to CISA’s KEV list so far. A public PoC exploit is available, further increasing the risk of ongoing exploit campaigns. Langflow has appeared five times on the CISA KEV list in 2026. The flaw affects Langflow 1.0.0 through 1.10.0. Greenbone’s OPENVAS ENTERPRISE FEED includes a remote banner version check to detect affected instances. Users should upgrade to Langflow version 1.10.1 or later immediately.

CVE-2026-66384: JFrog Artifactory Actively Exploited

CVSS 5.3 · MediumEPSS 0.6% (45th)Actively exploitedIn CISA KEV

CVE-2026-66384 (CVSS 5.3) allows an authenticated attacker to write data outside the intended Docker cache path in affected JFrog Artifactory versions. The root cause is improper pathname restriction [CWE-22]. The flaw is being actively exploited and was added to CISA’s KEV catalog.

An OpenAI research agent successfully exploited the flaw during an internal evaluation, poisoning Artifactory’s cache with attacker-controlled content. The poisoned image created a potential path to arbitrary command execution if it were later pulled and run. The poisoned image did not make it into the wild based on OpenAI’s investigation, which includes a full technical description for CVE-2026-66384. CIRCL.lu’s Vulnerability Lookup public threat intelligence platform indicates that a PoC exploit may be available on a public Telegram channel.

JFrog Artifactory versions 7.146.0 through 7.146.34 and 7.161.0 through 7.161.15 are affected. The OPENVAS ENTERPRISE FEED includes a remote banner check, allowing users to identify affected instances.

CVE-2026-71362: Local Privilege Escalation Flaw in Adobe Commerce/Magento

CVSS 9.1 · CriticalEPSS 25.1% (98th)Public PoC

CVE-2026-71362 (CVSS 9.1, EPSS ≥ 98th pctl) is an incorrect authorization vulnerability [CWE-863] that allows privilege escalation and elevated access to sensitive resources on Adobe Commerce/Magento instances. A low-privilege authenticated attacker with a registered customer account can take over any other customer account using only the user id field. A proof-of-concept exploit is publicly available. Adobe’s APSB26-92 advisory disclosed seven new CVEs in total; five rated critical severity. Affected products and versions are shown below.

Affected Product	Affected Versions	Fixed Versions
Adobe Commerce	2.4.9-2026-jul and earlier 2.4.8-2026-jul and earlier 2.4.7-2026-jul and earlier 2.4.6-2026-jul and earlier 2.4.5-2026-jul and earlier 2.4.4-2026-jul and earlier	2.4.9-2026-aug 2.4.8-2026-aug 2.4.7-2026-aug 2.4.6-2026-aug 2.4.5-2026-aug 2.4.4-2026-aug
Adobe Commerce B2B	1.5.3-2026-jul and earlier 1.5.2-2026-jul and earlier 1.4.2-2026-jul and earlier 1.3.4-2026-jul and earlier 1.3.3-2026-jul and earlier	1.5.3-2026-aug 1.5.2-2026-aug 1.4.2-2026-aug 1.3.4-2026-aug 1.3.3-2026-aug
Magento Open Source	2.4.9-2026-jul and earlier 2.4.8-2026-jul and earlier 2.4.7-2026-jul and earlier 2.4.6-2026-jul and earlier	2.4.9-2026-aug 2.4.8-2026-aug 2.4.7-2026-aug 2.4.6-2026-aug

The OPENVAS ENTERPRISE FEED detects all CVEs in Adobe’s APSB26-92 advisory with a remote banner check. See the vendor’s release notes for more information [1][2][3][4].

CVE-2026-17106 (aka CopyEscape): PoC Available for Container-to-Host Arbitrary File in moby/go-archive

CVSS 7.1 · HighEPSS 0.3% (25th)No known exploitationPublic PoC

CVE-2026-17106 (CVSS 7.1, EPSS 25th pctl), dubbed CopyEscape, allows a malicious container to escape isolation and achieve root code execution on a Docker host. The root cause is a combination of a path traversal flaw [CWE-35] and improper symlink resolution [CWE-59]. Exploitation allows a trojanized container to overwrite arbitrary host files, including root-owned binaries such as /usr/bin/runc on the Docker host via tar extraction during docker cp. Although no active exploitation has been confirmed, multiple detailed technical write-ups [1][2][3][4] and functional public PoC exploits [1][2][3] are available.

CVE-2026-17106 affects the moby/go-archive tar extraction routines in the following Docker products:

Affected Product	Affected Versions	Fixed Version
moby/go-archive	< 0.3.0	0.3.0
Docker Engine	< 29.7.0	29.7.0
Docker CLI	< 29.7.0	29.7.0
Docker Desktop	< 4.86.0	4.86.0
Docker Compose	< 5.4.0	5.4.0
Docker Sandboxes	< 0.38.0	0.38.0

The OPENVAS ENTERPRISE FEED includes a registry detection for Docker Desktop for Windows, a remote banner check for Docker Engine, and Linux package detection for specific distributions as security advisories are issued.

CVE-2026-53413: Zoom Forfeits Remote Code Execution to Any Meeting Attendee

CVSS 8.3 · HighEPSS 5.6% (92nd)No known exploitation

CVE-2026-53413 (CVSS 8.3, EPSS ≥ 92nd pctl) allows an attacker participating in a Zoom meeting to achieve RCE on all meeting participants across all native clients without any user interaction. Exploitation allows code execution with the Zoom application’s permissions. A demonstrated macOS technical write-up demonstrates calling execvp() from the compromised zoom.us process, replacing that process with Safari.

Although no active exploitation has been reported, CVE-2026-53413 has an elevated EPSS score indicating high risk of future exploitation. If weaponized, the flaw creates a social engineering risk, allowing attackers to impersonate potential customers or other business communications to execute arbitrary code on the victim’s computer. Users should verify their Zoom patch level and configure all Zoom clients for “Fast” automatic-updates. The OPENVAS ENTERPRISE FEED includes package-level detection for Windows, Linux, and macOS [1][2][3].

CVE-2023-49105: Three-Year-Old ownCloud Flaw Actively Exploited

CVSS 9.8 · CriticalEPSS 43.2% (99th)Actively exploitedIn CISA KEVPublic PoC

CVE-2023-49105 (CVSS 9.8, EPSS ≥ 99th pctl), affecting ownCloud, was published in late-2023 and added to CISA’s KEV list in August. A Philippine nuclear naval contractor is the only publicly identified victim so far. Several detailed technical write-ups [1][2] and PoC exploits [3][4] have been available for CVE-2023-49105 since late 2023.

ownCloud is an open-source file synchronization, sharing, and collaboration platform. The product is similar to Dropbox or Google Drive and popular for self-hosted file sharing when data sovereignty is important.

The flaw is caused by pre-signed URLs being accepted even when no signing key is configured for the owner of a file. Exploitation requires the attacker to possess an existing username for which no signing key is configured. Successful exploitation allows an attacker to access, modify, or delete any file without other forms of authentication.

CVE-2023-49105 affects ownCloud versions 10.6.0 and later, before 10.13.1. The OPENVAS ENTERPRISE FEED has included a remote banner check for CVE-2023-49105 since its disclosure in November 2023.

Other Notable Emerging Threats from August 2026

Here are some other notable high-risk IT security threats that emerged in August 2026.

TrueConf Actively Exploited Again to Deliver PhantomCore Malware

CVE-2026-72529 (CVSS 9.8, EPSS ≥ 73rd pctl) and CVE-2026-72530 (CVSS 9.0, EPSS ≥ 77th pctl) affecting TrueConf Server can be chained to execute arbitrary scripts, escape the isolated execution environment, and achieve host-level RCE. Exploitation does not require authentication. CISA added both flaws to its KEV catalog in August [3][4]. CVE-2026-3502 was also added to CISA’s KEV list in April 2026, indicating a persistent threat to the conferencing platform’s users.

The two chained TrueConf Server CVEs from August 2026, each shown with its CVSS severity band and EPSS exploitation-probability score

CVE-2026-72529

CVSS 9.8 · Critical EPSS 1.6% (73rd)

Can be chained with CVE-2026-72530 to execute arbitrary scripts, escape the isolated execution environment, and achieve host-level RCE in TrueConf Server.

CVE-2026-72530

CVSS 9.0 · Critical EPSS 1.8% (77th)

Chainable with CVE-2026-72529 for host-level RCE in TrueConf Server; exploited by the Head Mare APT to deploy PhantomCore malware.

In the most recent attacks, Kaspersky observed the Head Mare APT exploiting the chain against Russian organizations to deploy a web shell, compromise TrueConf Server databases, and install malicious versions of TrueConf client installers. The trojanized installers delivered PhantomCore malware to conference participants. The vendor advises users to upgrade to version 5.5.2 or later.

PaperCut NG/MF Actively Exploited for Unauthenticated RCE

CVE-2026-81578 (CVSS 9.8) and CVE-2026-82078 (CVSS 9.1) affecting PaperCut NG/MF can be chained for unauthenticated RCE. The attack chain involves first modifying the system configuration and then abusing unsafe dynamic class loading to execute arbitrary Java bytecode. PaperCut confirmed active exploitation of its customers. Post-exploitation activity included deployment of SimpleHelp and AnyDesk remote-access software.

The two chained PaperCut NG/MF CVEs from August 2026, each shown with its CVSS severity band and EPSS exploitation-probability score

CVE-2026-81578

CVSS 9.8 · Critical EPSS 0.8% (53rd)

Chainable with CVE-2026-82078 for unauthenticated RCE in PaperCut NG/MF via unsafe dynamic class loading; actively exploited to deploy SimpleHelp and AnyDesk.

CVE-2026-82078

CVSS 9.1 · Critical EPSS 0.9% (58th)

Chainable with CVE-2026-81578 for unauthenticated RCE in PaperCut NG/MF.

CISA added both flaws to its KEV catalog [1][2]. A public Metasploit module is available, as well as a detailed technical write-up, and public PoC exploits [3][4]. The OPENVAS ENTERPRISE FEED includes a remote banner check, allowing users to identify affected instances. At least three successive security patches have been issued to remediate the CVEs, so users should check the vendor’s official advisory for the latest information.

Critical Flaws in Veeam ONE and Service Provider Console

Critical-severity flaws were disclosed for both Veeam ONE via KB4892 and Veeam Provider Console (VSPC) in KB4893. The flaws affecting Veeam ONE impact all version 13 builds through 13.0.2.6723, resolved in Veeam ONE 13.1 (build 13.1.0.7034) or Veeam ONE 13.0.2 Patch 1 (build 13.0.2.7159). All flaws in VSPC affect all version 9 builds through 9.2.1.33875, resolved in Veeam Service Provider Console 9.3 (build 9.3.0.35057). The highest-risk CVEs are:

• CVE-2026-64633 (CVSS 10) in Veeam ONE: Allows remote, unauthenticated code execution on the agent host
• CVE-2026-58073 (CVSS 9.5) in Veeam Service Provider Console: Allows an unauthenticated attacker to impersonate a managed agent and obtain that agent’s credentials

The two highest-risk Veeam ONE and Service Provider Console CVEs from August 2026, each shown with its CVSS severity band and EPSS exploitation-probability score

CVE-2026-64633

CVSS 10 · Critical EPSS 0.5% (38th)

Allows remote, unauthenticated code execution on the agent host in Veeam ONE.

CVE-2026-58073

CVSS 9.5 · Critical EPSS 0.3% (24th)

Allows an unauthenticated attacker to impersonate a managed agent and obtain that agent’s credentials in Veeam Service Provider Console.

VSPC serves as a centralized management and monitoring platform for customer data-protection environments. Because it sits in a privileged, centralized management position and provides remote access across multiple customer backup environments, a breach could serve as a pivot point into managed infrastructure and have severe consequences. Veeam ONE presents lower risk than VSPC because it is primarily a monitoring, reporting, and analytics platform. However, a breach could expose sensitive backup-infrastructure data and credentials, and potentially provide a foothold for further intrusion.

The OPENVAS ENTERPRISE FEED includes remote banner checks for KB4892 affecting Veeam ONE [1][2] and KB4893 affecting VSPC [3].

CVE-2026-10053: Package Registry Path Traversal Enables Authenticated RCE in GitLab CE/EE

CVSS 8.8 · HighEPSS 0.8% (53rd)No known exploitationPublic PoC

CVE-2026-10053 (CVSS 8.8, EPSS ≥ 53rd pctl) allows a low-privileged authenticated attacker to achieve RCE in GitLab CE/EE via a path traversal flaw in the package registry. A public PoC lab is available, but active exploitation has not been reported. The issue follows reports of CVE-2026-19478 being actively exploited earlier in August. The OPENVAS ENTERPRISE FEED provides a remote banner check for CVE-2026-10053 and regular detection for GitLab flaws including the actively exploited CVE-2026-19478. GitLab patched the issue in versions 19.0.6, 19.1.4, and 19.2.2.

Summary

August 2026 delivered another heavy wave of high-risk vulnerabilities, including actively exploited flaws, public PoCs, CVSS 10 issues, and vulnerabilities tied to ransomware and espionage. The month’s disclosures reinforce the need to prioritize internet-facing and privileged enterprise systems for rapid remediation.

 

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.