CVE-2026-85706 (CVSS 10, EPSS 96th pctl), published on September 12th, 2026, is a critical path traversal flaw in the GitLab CE/EE repository Commits API and Repository Files API. Exploitation can allow an unauthenticated attacker to read arbitrary files from the GitLab server on affected self-managed instances. However, the unauthenticated exploit path requires at least one anonymously readable project with repository access enabled.
The flaw was added to CISA’s Known Exploited Vulnerabilities (KEV) catalog on September 11th. Security firm watchTowr reported probes against its honeypot network. Several detailed technical analyses for CVE-2026-85706 are available, which also provide proof-of-concept (PoC) exploit code [1][2][3][4][5], further increasing the risk of ongoing attacks. Numerous national CERT alerts have been issued for CVE-2026-85706 [6][7][8][9][10][11][12][13][14][15][16][17][18].
CVE-2026-85706 was patched in a single coordinated release alongside 17 other CVEs, with one other rated critical severity. Updates for self-managed GitLab installations are available in versions 19.1.8, 19.2.6, and 19.3.2, and defenders should apply the updates as soon as possible.
A Risk Assessment of CVE-2026-85706 in GitLab CE/EE
GitLab is a widely deployed DevOps platform used for source code management, CI/CD pipelines, and application security workflows. CVE-2026-85706 is considered actively exploited and has been added to CISA’s KEV list. Several detailed technical analyses with PoC exploit code are available [1][2][3][4][5].
Instances often hold sensitive resources such as source code, credentials, and CI/CD configuration data. A remotely exploitable, unauthenticated file-read vulnerability represents critically high risk to development and software release operations. A breach may also enable supply-chain attacks, unauthorized access to cloud resources, or lateral movement within the victim’s network.
Examples include configuration and secret files such as gitlab.yml, secrets.yml, gitlab-secrets.json, and database.yml. Other potential exposures include SSH private keys, .pem certificate files, .env files, SMTP, or LDAP credentials and more. If the instance secret key base is disclosed, attackers may be able to forge sessions and tokens and decrypt stored CI/CD variables and multi-factor authentication (MFA) responses. Source code and other valuable intellectual property represent other potential data-theft risks.
Technical Details for CVE-2026-85706 in GitLab CE/EE
CVE-2026-85706 (CVSS 10, EPSS ≥ 96th pctl) is a path traversal flaw [CWE-22] combined with missing authentication [CWE-306] enforcement. GitLab’s patch notes say the flaw affects the repository Commits API. However, independent analyses have also demonstrated the same vulnerable behavior in the Repository Files API, via POST and PUT operations [1].
Exploitation allows arbitrary file reads from the GitLab server rather than direct remote code execution (RCE). Exploitation also requires at least one anonymously readable project with repository access enabled. The arbitrary-file-read primitive executes with the permissions of the GitLab service context, generally the git user.
Exploitation Path and Potential Follow-On Impact
Exploitation can leverage a single unauthenticated POST request. Multiple working PoCs target the Content-Type: application/x-www-form-urlencoded HTTP header.
The malicious request must bypass the project’s authorize_read_code! check. Therefore, the attacker must identify an anonymously readable project whose repository is accessible, normally a public project.
Out of scope files are specified via specially crafted values for the metadata.path or file.path. Exploits can leverage route and parameter encoding techniques such as trailing-slash and percent-encoding.
A vulnerable GitLab server reads the attacker-selected file and returns the contents via an error-handling path that reflects the file data in an HTTP 400 response body.
Theft of credentials can support broader compromise, potentially leading to lateral movement within the victim’s network.
CVE-2026-85706: Affected Versions and Mitigation
Detection Coverage
Greenbone’s OPENVAS ENTERPRISE FEED added a remote banner check for CVE-2026-85706 soon after its disclosure. The ENTERPRISE FEED also includes regular detection for GitLab vulnerabilities.
CVE-2026-85706 was patched in a single release alongside 17 other CVEs, with one other rated as Critical severity. See GitLab’s release notes for affected versions of each CVE. GitLab said GitLab-managed infrastructure, including GitLab.com and GitLab Dedicated, has already been patched.
For the actively exploited CVE-2026-85706, affected versions are: 18.7 prior to 19.1.8, 19.2 prior to 19.2.6, and 19.3 prior to 19.3.2. There is no patch for 18.x or 19.0.x releases; users must move to at least 19.1.8. No workaround mitigations have been proposed by GitLab. However, reasonable temporary mitigations include removing GitLab from public Internet exposure, restricting connectivity to only trusted IP addresses, and using a web-application firewall (WAF) to specifically filter traffic targeting the Commits API and Repository Files API.
Given its actively exploited status and the operational risk of a GitLab breach, users running affected self-managed versions should accelerate patching and validation.
Product
Affected versions
Fixed versions
Self-managed GitLab CE/EE installations
18.7 before 19.1.8
19.1.8
19.2 before 19.2.6
19.2.6
19.3 before 19.3.2
19.3.2
Summary
CVE-2026-85706, published on September 12th, 2026, is a critical GitLab CE/EE path traversal flaw allowing unauthenticated attackers to read arbitrary files from affected self-managed servers. Exploitation represents a high degree of risk to software-producing organizations and downstream supply chains. Risk is elevated by the flaw’s actively exploited status, numerous public technical analyses, and PoC exploit code.
CVE-2026-82329, CVE-2026-42018, and CVE-2026-42016, all affecting JFrog Artifactory, were added to CISA’s Known Actively Exploited (KEV) in September 2026 [1][2][3]. Artifactory acts as a central repository for software build artifacts, binaries, packages, containers, files, releases, and increasingly AI/ML artifacts. A compromise of Artifactory could allow an attacker to steal sensitive artifacts and credentials, tamper with or replace trusted packages and container images, and use the repository to distribute malicious code throughout downstream build and deployment pipelines. Numerous national CERT advisories have been issued for the actively exploited CVEs [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15].
Risk Assessment of Recent Attacks Targeting JFrog Artifactory
JFrog Artifactory first appeared in CISA’s KEV catalog in August 2026. The Greenbone blog covered the only other KEV CVE affecting JFrog Artifactory in the August Threat Report: The Vulnpocalypse Hits Full Force. The new attacks represent an increased focus on Artifactory and they are likely supported by AI-enabled exploit development.
On September 1st, watchTowr reported active exploitation of CVE-2026-82329, followed by Fastly on September 3rd. An attack campaign that chains CVE-2026-42018 and CVE-2026-42016 to target self-hosted instances was reported by Wiz Research. Combined, the attack trajectory for CVE-2026-42018 and CVE-2026-42016 allow a malicious, unauthenticated HTTP request to return an admin-scoped access token. Wiz also observed in-the-wild exploitation of CVE-2026-82329.
Several detailed technical analyses with proof-of-concept (PoC) exploit instructions are available online [1][2][3], and PoC exploit toolkits are available on GitHub [4][5], increasing the risk of additional attack campaigns.
Technical Summary of Actively Exploited JFrog Artifactory CVEs
The new actively exploited flaws are described below:
The three actively exploited JFrog Artifactory CVEs, each shown with its CVSS severity band and EPSS exploitation-probability score
An authentication weakness [CWE-287] allows an unauthenticated attacker with network access to obtain administrative privileges. The flaw is exploitable in the product’s default configuration. The flaw was disclosed on August 28th and the OPENVAS ENTERPRISE FEED added a remote banner check soon after the CVEs disclosure.
An incorrect authorization vulnerability [CWE-863] allows privilege escalation. The root cause is a validation check that verifies a token’s signature and issuer, but not its scope. CVE-2026-42016 was published in late July 2026 and the OPENVAS ENTERPRISE FEED added a remote banner check soon after its disclosure.
An improper authentication vulnerability [CWE-287] returns an anonymous-user token to an unauthenticated caller even if anonymous access is disabled. Exploitation can expose sensitive resources to an attacker. CVE-2026-42018 was published on August 12th, 2026 and the OPENVAS ENTERPRISE FEED added a remote banner check since its disclosure.
Mitigation for Actively Exploited JFrog Artifactory CVEs
The affected versions for each new actively exploited CVE are shown below:
CVE
Affected Versions
Fixed Version
CVE-2026-82329
7.161.0 before 7.161.20
7.146.0 before 7.146.38
7.133.0 before 7.133.29
7.125.0 before 7.125.20
7.117.0 before 7.117.28
7.111.4 before 7.111.21
7.161.20
7.146.38
7.133.29
7.125.20
7.117.28
7.111.21
CVE-2026-42018
< 7.111.20
7.117.0 before 7.117.27
7.125.0 before 7.125.19
7.133.0 before 7.133.28
7.146.0 before 7.146.8
7.111.20
7.117.27
7.125.19
7.133.28
7.146.8
CVE-2026-42016
< 7.133.11
7.133.11
JFrog only supports minor versions of self-managed Artifactory for 18 months after their release date. Self-managed minor versions 7.111.x are due to reach end of life (EOL) in October 2026. Full lists of fixed versions are available above and also in each OPENVAS SCAN detection result, and in the vendor’s security advisories. Users should carefully consider their exposure and upgrade to the latest 7.x version with an adequate support lifecycle.
If immediate upgrading is not possible, JFrog advises workaround mitigation of CVE-2026-82329 by configuring a strong, randomly generated additionalJoinKeys value under shared.security in the system.yaml file (or via JF_SHARED_SECURITY_ADDITIONALJOINKEYS for containerized/Helm deployments) and restarting the Access service to ensure that only trusted join keys are accepted for service registration. The vendor does not provide any workaround mitigations for CVE-2026-42018 or CVE-2026-42016.
Summary
Three JFrog Artifactory vulnerabilities have been added to CISA’s KEV catalog in September following confirmed active exploitation. The flaws create significant risk to software supply chains and downstream build environments. Public technical analyses and exploit tools further increase exposure. Organizations should identify affected Artifactory instances, upgrade to supported fixed releases, and apply JFrog’s documented workaround for CVE-2026-82329 where immediate patching is not possible.
https://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.png00Joseph Leehttps://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.pngJoseph Lee2026-09-15 15:01:532026-09-15 15:01:53Three New JFrog Artifactory CVEs Actively Exploited in the Wild
On September 29th, 2026, CISA released an ICS Advisory to address CVE-2026-84411 (CVSS 9.3, EPSS ≥ 60th pctl). The root cause is an integer underflow [CWE-191] the RouterOS web management service’s HTTP request handling. Exploitation allows unauthenticated RCE or DoS conditions. CVE-2026-84411 is not considered actively exploited and has not been added to CISA’s KEV list. However, several national CERT alerts have been issued [1][2][3][4][5][6][7]. Users should upgrade to RouterOS to version 7.24 or later. At the time of disclosure, the OPENVAS ENTERPRISE FEED added a remote banner check for CVE-2026-84411.
According to CERT Polska, active exploitation of MikroTik RouterOS has been underway since at least September 2nd, 2026. The chain leverages CVE-2026-67276 (CVSS 9.2) and CVE-2026-86060 (CVSS 9.2) against devices whose SSH service is reachable from public networks. A successful breach yields full control of the targeted system. MikroTik has published fixes for the flaws in versions 7.25 beta 3, 7.24.2, 7.23.4, and 6.49.21. The same release cycle also patched CVE-2026-67277, CVE-2026-67278, CVE-2026-67279, and CVE-2026-67281, although they were not included in the vendor’s advisory.
Two of the six vulnerabilities, CVE-2026-67277 and CVE-2026-86060, were added to CISA’s Known Exploited Vulnerabilities (KEV) list [1][2]. Although CERT Polska reports exploitation of CVE-2026-67276, it was not added to CISA’s KEV catalog. A technical analysis of the patched code is also available online [3]. Numerous national CERT agencies have issued alerts for the recent flaws affecting MikroTik RouterOS [4][5][6][7][8][9][10][11][12][13][14]. Users should update immediately to a patched version.
A Risk Assessment of Attacks Targeting MikroTik RouterOS
RouterOS is MikroTik’s Linux-based network operating system for routers, switches, and wireless devices. The platform also includes built-in routing, firewall, VPN, wireless management, network monitoring, and other core networking functions. Exposure of RouterOS administrative services presents especially high-risk because a compromise could affect the network layer of an entire network segment or organization.
The disclosed exploit path, dubbed “MikroTrick”, allows unauthorized initial access via exposed SSH service. The vendor states that SSH should not be accessible on untrusted networks. Furthermore, the default RouterOS configuration blocks SSH from the WAN interface. If enabled and accessible on a local network, the vulnerable SSH service could also allow an attacker with network access, such as an insider attacker, to move laterally to a high-value target.
There is a discrepancy between CERT Polska’s observations and the CVEs that have been added to CISA’s KEV list. Fixes for all known vulnerabilities are available in RouterOS versions 7.25 beta 3, 7.24.2, 7.23.4, and 6.49.21. The availability of a public technical analysis for the RouterOS patch and a public exploit (PoC) toolkit for CVE-2026-67276 increases the risk of wider attack campaigns. CIRCL.lu’s Vulnerability Lookup indicates that discussion about a PoC for CVE-2026-86060 is taking place on Telegram [3]. This increases the risk that additional threat groups will weaponize the full MikroTik exploit chain.
The Technical Details for September 2026 MikroTik RouterOS Flaws
Here is a brief technical description for all new CVEs affecting MikroTik RouterOS:
The MikroTrick Attack Chain:
CVE-2026-67276 and CVE-2026-86060, the two vulnerabilities chained together in the MikroTrick exploit, each shown with its CVSS severity band and EPSS exploitation-probability score
An SSH authentication bypass in RouterOS allows login without a user’s private key. Exploitation grants an attacker the target account’s privileges. The root cause is incomplete RSA public-key verification [CWE-347] in the RouterOS SSH service. The flaw exists because the server checks the key type and modulus, but not the exponent. CVE-2026-67276 is considered actively exploited by CERT Polska and a PoC exploit is publicly available [1]. This issue affects only 7.x branch and was fixed in versions: 7.23.4 (Long-term) and 7.24.2 (Stable).
An SSH login argument-handling flaw [CWE-88] in which usernames beginning with a prohibited character can alter the trusted policy mask, leading to privilege escalation and a full administrative session. CVE-2026-86060 has been added to CISA’s KEV list. CIRCL.lu’s Vulnerability Lookup indicates that discussion about a PoC is taking place on Telegram [3]. This issue was fixed in versions: 6.49.21 (Long-term), 7.23.4 (Long-term) and 7.24.2 (Stable).
Also added to CISA’s KEV list:
CVE-2026-67277, also added to CISA’s Known Exploited Vulnerabilities catalog, shown with its CVSS severity band and EPSS exploitation-probability score
A flaw in the bandwidth-test service allows an unauthenticated client to reach a post-authentication state and exploit packet-buffer disclosure and integer-underflow conditions. Exploitation allows an attacker to leak sensitive kernel memory or restart the device. The root-cause is classified as a missing authentication for a critical function [CWE-306]. CVE-2026-67277 has been added to CISA’s KEV list. This issue was fixed in versions: 6.49.21 (Long-term), 7.23.4 (Long-term) and 7.24.2 (Stable).
Additional RouterOS flaws published in September 2026:
CVE-2026-67278, CVE-2026-67279, and CVE-2026-67281, the additional MikroTik RouterOS flaws patched in September 2026, each shown with its CVSS severity band and EPSS exploitation-probability score
An X.509 validation flaw [CWE-347] in TLS handling. Malformed RSA/PKCS#1 v1.5 signatures allow an attacker that controls or can redirect outbound TLS connections to forge a trusted intermediate certificate and impersonate arbitrary hostnames. This issue affects only 7.x branch and was fixed in versions: 7.23.4 (Long-term) and 7.24.2 (Stable).
A client-requested SSH rekey can move the connection into the session and exec path even though authentication was never attempted. Exploitation allows an unauthenticated attacker to conduct file creation, overwrite, and reconstruction in the RouterOS-managed file namespace. This issue was fixed in versions: 6.49.21 (Long-term), 7.23.4 (Long-term) and 7.24.2 (Stable).
A file-read issue in the WebFig/jsproxy path allows an unauthenticated attacker to read root-owned files, including configuration stores containing credentials. The root cause is a stale uninitialized principal pointer [CWE-824] combined with parent-directory traversal [CWE-22]. This issue affects only 7.x branch and was fixed in versions: 7.23.4 (Long-term) and 7.24.2 (Stable).
Understanding the MikroTrick Exploitation Campaign
According to CERT Polska, the MikroTrick exploit chain allows an attacker to take full control of affected devices via the SSH service. The MikroTrick attack combines CVE-2026-67276 and CVE-2026-86060.
CVE-2026-67276 is leveraged first to bypass SSH authentication by abusing incomplete RSA public-key verification. This allows unauthenticated access without the target user’s private key. In the second stage, CVE-2026-86060 is used to manipulate SSH login argument handling so that a crafted username can alter the trusted policy mask to gain root-level permissions. The result is escalation from unauthorized SSH access to a full administrative RouterOS session. After obtaining full administrative access, attackers created a rogue local account named ops, with high-level privileges. Affected system logs recorded entries such as: user ops added by ssh:-2@<attacker-ip>.
CERT Polska has not publicly confirmed any other attacker techniques, but lists several observed attacker IP addresses. Defenders should be aware that the absence of known indicators does not rule out device compromise.
Mitigation for New CVEs Affecting MikroTik RouterOS
Patches for all CVEs discussed above are available in RouterOS versions 7.25 beta 3, 7.24.2, 7.23.4, and 6.49.21. For organizations with the SSH exposed for remote administration, remediation priority should be highest where it is reachable from public or otherwise untrusted networks. The OPENVAS ENTERPRISE FEED includes remote banner detection for the CVEs associated with the MikroTrick exploit chain and other new CVEs affecting MikroTik RouterOS.
For organizations that cannot apply the patches immediately, public SSH access should be disabled. MikroTik also warns that SSH should not be left open to untrusted networks and states that the default configuration blocks the service from the internet. Beyond patching, defenders should review devices for broad indicators of compromise.
Summary
MikroTrick is a newly disclosed exploit chain that combines CVE-2026-67276 with CVE-2026-86060 for full unauthenticated root-level control of RouterOS devices. The attacks leverage the exposed SSH service of vulnerable devices. CERT Polska believes that attacks have been active since at least September 2nd, 2026. CISA added CVE-2026-86060 and a separate flaw, CVE-2026-67277, to its KEV list. Additional risk is posed by public PoC exploit code and a detailed patch analysis.
Detect These Vulnerabilities with Greenbone
The OPENVAS ENTERPRISE FEED includes remote banner detection for the CVEs associated with the MikroTrick exploit chain and other new CVEs affecting MikroTik RouterOS. This includes the most recent batch: CVE-2026-67276, CVE-2026-67277, CVE-2026-67278, CVE-2026-67279, CVE-2026-67281, and CVE-2026-86060. The vendor has released fixes for the affected RouterOS branches and has further advised administrators not to expose SSH to untrusted networks.
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.
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
Affects the Windows Ancillary Function Driver for WinSock; exploited in an espionage campaign combining social engineering with this Windows privilege-escalation flaw.
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.
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.
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
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
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
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
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.
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.
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 (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 (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 (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
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
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 (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
Can be chained with CVE-2026-72530 to execute arbitrary scripts, escape the isolated execution environment, and achieve host-level RCE in TrueConf Server.
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
Update:
Several bypasses for the updates that mitigate CVE-2026-81578 have been disclosed and subsequently patched. A report by watchTowr Labs includes a detailed technical analysis. Users should be especially diligent to ensure all available security patches have been applied. While not all of the bypasses were assigned a unique CVE ID, the patch for CVE-2026-82077 (CVSS 7.3, EPSS ≥ 53rd pctl) includes mitigation for all known flaws affecting PaperCut NG/MF to this point. Users should upgrade to version 25.0.13, 26.0.5 or later. The OPENVAS ENTERPRISE FEED immediately added a remote banner check for CVE-2026-82077.
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
Chainable with CVE-2026-82078 for unauthenticated RCE in PaperCut NG/MF via unsafe dynamic class loading; actively exploited to deploy SimpleHelp and AnyDesk.
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
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].
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.
https://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.png00Joseph Leehttps://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.pngJoseph Lee2026-09-07 14:56:592026-10-16 11:17:04August 2026 Threat Report: The Vulnpocalypse Hits Full Force
Agents are not new to vulnerability management. The reason the question keeps resurfacing is that the estate being scanned stopped holding still. A scanner that assumes every host is reachable on a known network at a scheduled time described most organisations reasonably well fifteen years ago. It describes very few of them now, in an estate that includes laptops connecting through a VPN twice a week, cloud instances that live for forty minutes, and OT segments that are deliberately unreachable from anywhere a scanner sits.
So the useful question is not whether agent-based scanning is better than agentless scanning. It is what each architecture can actually see, and which parts of your estate fall outside both.
A note on where we stand before getting to the general case: Greenbone’s scanning-agent capability is currently available as a TechPreview within OPENVAS SCAN (Enterprise only, new license model only), and is being rolled out in a controlled fashion in collaboration with our professional service team as it is validated. The rest of this post is about the architectural question, which is the part worth understanding regardless of whose tooling you run.
What “Agentless” Actually Means
Agentless scanning means the assessment runs somewhere other than the target. A scanner sits at a vantage point on the network and interrogates the host over the host’s own interfaces.
That splits into two quite different things, which are frequently discussed as though they were one:
Unauthenticated scanning looks at the host from outside, with no privileges: open ports, service banners, TLS configuration, exposed applications, behaviour that can be probed. It answers the question an attacker asks.
Credentialed scanning logs in, over SSH, WMI or an API, and reads the system from the inside: installed packages and versions, patch level, configuration.
The distinction matters because it defuses the most common claim in this topic. A credentialed agentless scan and an agent see largely the same host state. Both read local package inventory and configuration. The difference between them is depth of insight (e.g. scanning of every file) and, as the Agent is directly installed on the host, speed.
What an Agent Changes
An agent moves execution onto the host. NIST’s guide to enterprise patch management technologies describes the architecture plainly: “An agent-based patch management technology requires an agent to be running on each host to be patched, with one or more servers that manage the patching process and coordinate with the agents.” The same document is direct about where the approach earns its keep. Agent-based technologies are “strongly preferred for hosts that are not on the local network all the time, such as telecommuter laptops and smartphones.”
Several things follow from that. The host does not need to be reachable from the scanner at the moment the assessment happens; the agent collects locally and reports when it next has a path back. No scanning credentials need to be distributed to, or stored for, every target, which removes a standing privileged-access problem from the network. And reachability stops depending on firewall rules, NAT, or the segmentation between scanner and target.
The practical effect is a shift away from the scan window toward something closer to continuous state.
What Each One Gives Up
This is the half of the topic that vendor material tends to skip, and it is the part a practitioner needs.
Agentless scanning does not assess hosts that are not there. NIST puts the limitation as omitting “hosts not on the local network, such as telecommuter laptops and mobile devices,” and notes that it can be negatively affected by firewalls and network address translation. Short-lived cloud workloads are the modern version of the same problem: a container that exists for the length of a job will never coincide with a nightly scan. Credentialed agentless scanning also needs credentials with real privileges on every target, which is a risk surface of its own and an operational burden that grows with the estate.
Agent-based scanning has a harder structural limit: a substantial part of a typical estate cannot run an agent at all. NIST again notes that hosts “that don’t permit direct administrator access to the operating system, such as many appliances, generally cannot run agents,” and that agents may not be available for every platform. In practice that category covers network and security equipment, storage appliances, printers, most industrial and building-control systems, embedded devices, and anything on the network nobody has administrative control over, which is precisely the group most likely to be neglected already. An agent is also software you have now installed on every host, with its own lifecycle, resource footprint and patching needs.
The deeper limit is perspective rather than reach. An agent looks at the host from inside. It can tell you that a vulnerable package is installed. It is not well placed to tell you that the affected service is reachable from the internet, sitting behind a misconfigured proxy, or listening on an interface nobody intended. That is a question about the network’s view of the host, and it can only be answered from the network.
Why Hybrid Is the Answer That Survives a Real Estate
Laid out this way, hybrid stops looking like a compromise between two options and starts looking like a consequence of the fact that they answer different questions.
Neither architecture’s blind spots are covered by its own strengths, and each covers the other’s. Agent-based scanning reaches exactly the hosts agentless scanning misses, the absent, roaming and ephemeral ones. Agentless scanning reaches exactly what agents cannot, everything that cannot run one, and it supplies the outside-in view that an agent structurally cannot produce. That is an unusual property. Normally one approach dominates and the other becomes legacy.
Standards already assume more than one vantage point. CIS Controls v8 Control 7.5 requires organisations to “conduct both authenticated and unauthenticated scans, using a SCAP-compliant vulnerability scanning tool” against internal enterprise assets. That requirement predates the agent question and is independent of it, but the reasoning is the same: one viewpoint is not enough to describe a host’s exposure.
Hybrid done well does not mean scanning everything twice. It means deciding, per class of asset, which vantage point answers the question you actually have about it.
A Practical Suggestion to Divide It Up
Roaming endpoints and anything that connects intermittently: an agent, where the platform supports one. This is the case for which agentless scanning has no good answer.
Appliances, network and security equipment, OT and embedded devices: agentless, because there is no alternative. These assets also tend to sit in segments a scanner can only reach from a deliberately placed vantage point, which is worth planning rather than discovering.
Servers and long-lived cloud instances: either works, so decide on your credential policy and the rate at which the systems change. If distributing scanning credentials across a large server estate is a problem you would rather not have, agents remove it. If installing software on production hosts is the harder internal conversation, credentialed scanning is mature and well understood.
Anything internet-facing: always also unauthenticated and from outside, whatever else assesses it. This is the only view that reflects what an attacker can reach, and no agent can produce it.
Ephemeral workloads: neither architecture fits comfortably. Assessing the image or template before deployment is usually a better answer than trying to catch the instance while it exists.
None of this makes agentless scanning an incomplete answer to the estate it was built for. A network-resident host assessed with credentials is fully assessed, and the outside-in view of it is still the only one that shows what an attacker can reach. Due to being directly installed on the target host, Agents extend vulnerability management with detailed information on hosts agentless scans can not discover.
https://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.png00Greenbone AGhttps://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.pngGreenbone AG2026-09-04 12:23:592026-09-04 12:23:59Agent-Based, Agentless, or Both? What Each One Can Actually See
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.
New because of the CRA?
The incident process and the checklist already existed. The checklist was originally created so it can be worked through under stress in an actual emergency, without having to read much first. What was formalized for the CRA is the CVD process and the responsibilities it defines.
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).
New because of the CRA?
Upstream contributions are everyday practice for a company with open-source roots. What’s new is anchoring the notification step in the process as a binding requirement.
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.
New because of the CRA?
CSAF publication and the CVE request process were already established beforehand.
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.
New because of the CRA?
Emergency releases and established processes for fixing and rolling out vulnerabilities in our products promptly already existed beforehand. The systematic post-mortem analysis is one of the things that has become more binding because of the CRA.
Requirement: Being Reachable for Reports From Outside
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.
New because of the CRA?
Automated SBOM generation in the build process is the part of our preparation that was most clearly built with September 11 in mind.
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.
https://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.png00Greenbone AGhttps://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.pngGreenbone AG2026-08-31 12:52:142026-08-31 13:46:50CRA Implementation at Greenbone: How We Made the Reporting Obligation Operational
CVE-2026-64849 (CVSS 9.3, EPSS ≥ 95th pctl) is a critical-severity unauthenticated full-read server-side request forgery (SSRF) flaw [CWE-918] in MLflow webhook delivery. The CVE affects all versions prior to 3.15.0. The root cause is flawed redirect handling and DNS rebinding. The flaw is exploited by bypassing the _validate_webhook_url protections in the default MLflow Tracking Server configuration. CISA has added CVE-2026-64849 to the Known Exploited Vulnerabilities (KEV) catalog, indicating active exploitation. The vendor’s advisory includes a detailed technical write-up and a proof-of-concept (PoC) exploit workflow. Additional technical analysis and PoC exploits are also available [1][2]. Multiple national CERT agencies worldwide have issued alerts [3][4][5][6][7][8][9].
MLflow is one of the most widely adopted self-hosted platforms for machine-learning experiment tracking and ML model lifecycle management. Organizations running MLflow should prioritize remediation because the flaw is being actively exploited, requires no authentication, and can expose internal service responses and cloud metadata through the webhook delivery path.
CISA added CVE-2026-64849 to its KEV catalog on August 19th, 2026. The vendor’s advisory itself includes a detailed technical write up and a proof-of-concept (PoC) exploit workflow. Additional technical analysis and PoC exploits are available [1][2]. These risk indicators support urgent remediation of exposed MLflow Tracking Server instances where webhook functionality is enabled for Model Registry or Prompt Registry events.
Technical Details for CVE-2026-64849 in MLflow
CVE-2026-64849 (CVSS 9.3, EPSS ≥ 95th pctl) is classified as an SSRF flaw [CWE-918]. The _validate_webhook_url function only validates the original webhook URL. However, the mlflow/webhooks/delivery.py execution follows HTTP redirects and re-resolves the hostname without pinning the previously validated address. The flaw exploits this flawed redirect handling and enables DNS rebinding attacks.
CVE-2026-64849 affects the MLflow Tracking Server, which may be reachable over the network without authentication by default in self-hosted deployments. The vulnerable path connects three components:
The attacker accesses the unauthenticated MLflow Tracking Server
The attacker abuses the API’s webhook testing workflow to trigger attacker-controlled requests to internal resources and return the response data to the attacker
Successful exploitation can compromise internal APIs and other services accessible to the MLflow host. The primary impact is information disclosure through unauthorized access to internal and cloud metadata services. This can include internal host and port discovery and, in cloud environments, exfiltration of credentials, API keys, tokens, or other secrets. Some public exploit variants can also preserve the original POST method and body, which may enable blind writes to private-network management endpoints. The official vendor advisory identifies the Docker daemon /stop, Elasticsearch /_close, and Spring Boot Actuator /shutdown endpoints.
Mitigation for CVE-2026-64849 in MLflow
MLflow 3.15.0 is the patched release, and all earlier versions are vulnerable. Users should update to MLflow 3.15.0 for complete mitigation. The OPENVAS ENTERPRISE FEED includes detection for CVE-2026-64849 in MLflow, allowing defenders to identify unpatched instances in their IT environments. Security teams should identify affected systems and prioritize remediation for deployments that use the default MLflow Tracking Server and expose the webhooks API. More information can be found in the MLflow GitHub advisory for CVE-2026-64849.
Summary
CVE-2026-64849 is a critical MLflow SSRF vulnerability affecting all versions prior to 3.15.0. The flaw is being actively exploited, and a significant amount of technical information and PoC exploit code is publicly available [1][2][3]. The operational risk is high because default MLflow Tracking Server deployments can expose the vulnerable webhook testing path without authentication. Multiple national CERT agencies worldwide have issued alerts [4][5][6][7][8][9][10]. Users should identify affected MLflow deployments and upgrade to version 3.15.0 for full mitigation.
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.
Not sure where your CRA reporting readiness stands?
Talk to Greenbone about your specific timeline and evidence trail.
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.
Summary: Guidance
Approved — pending translation
Adopted in substance 27 July 2026. Formally applies once every EU-language version is ready.
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.
Summary: Reporting platform
In testing
Functional and security testing under way now. Scheduled to be operational by 11 September 2026, not necessarily before.
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.
Summary: Standards
Not yet published
No harmonised standard has a citation in the Official Journal yet. The 2026 deadlines may still slip by roughly two months.
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.
Not sure where your CRA reporting readiness stands?
Talk to Greenbone about your specific timeline and evidence trail.
https://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.png00Greenbone AGhttps://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.pngGreenbone AG2026-08-25 13:37:032026-08-25 13:37:55The Cyber Resilience Act at Two Weeks: What’s Actually Ready, and What Isn’t
GitLab has released fixes for CVE-2026-19478 (CVSS 9.4, EPSS 0.7% (51st percentile)), a critical-severity code injection flaw [CWE-94]. The vulnerability affects the GraphQL directive in GitLab Community Edition (CE) and Enterprise Edition (EE). According to GitLab, the flaw can allow an unauthenticated attacker to remotely modify or delete public projects and user data under certain conditions.
watchTowr Labs observed exploitation attempts targeting honeypot instances shortly after disclosure and CIRCL.lu lists CVE-2026-19478 in its Vulnerability Lookupactively exploited list with a Confirmed status. Several detailed technical write-ups and proof-of-concept (PoC) exploits are publicly available, further increasing the risk of ongoing attacks. Multiple national CERT agencies have issued alerts for the flaw [1][2][3][4][5][6][7][8][9][10][11].
One additional CVE was included in the vendor’s disclosure. CVE-2026-19650 (CVSS 7.1) is a cross-site request forgery (CSRF) vulnerability [CWE-352] affecting the GraphQL multiplex query handler. No active exploitation has been reported for CVE-2026-19650. Organizations running self-managed GitLab instances should apply mitigations as soon as possible.
CVE-2026-19478 is exploitable remotely without authentication or user interaction. GitLab reports that exploitation allows an unauthenticated attacker to remotely modify or delete public projects and user data due to flawed GraphQL directive behavior. For organizations that rely on GitLab as a core software delivery system, an unauthorized change has the potential for downstream disruption across build pipelines and production release workflows.
As a DevOps/DevSecOps platform, GitLab often sits at the center of development, security, and operations workflows. A breach can therefore have high-risk consequences, especially where GitLab is integrated into automated deployment processes and CI/CD workflows. It’s also plausible that instances of GitLab vulnerable to CVE-2026-19478 could be leveraged in future supply chain attacks.
watchTowr Labs claims to have reproduced CVE-2026-19478 within minutes of its disclosure by analyzing the patched code. watchTowr also observed honeypot activity indicating in-the-wild exploitation attempts. Several detailed technical analyses [1][2][3] and PoC exploits are available [4][5][6], increasing the risk of ongoing attacks. Multiple national CERT agencies have issued alerts for the flaw [7][8][9][10][11][12][13][14][15][15][16].
The Technical Details for CVE-2026-19478 in GitLab CE/EE
CVE-2026-19478 (CVSS 9.4, EPSS 0.7% (51st percentile)) is a code injection vulnerability in GitLab CE/EE via the GraphQL directive. Exploitation requires only a single unauthenticated HTTP request to a GraphQL endpoint and the ability to resolve an unauthenticated object, such as a public project or accessible user object. The vulnerability stems from GitLab’s FutureFieldFallback logic, which dynamically creates GraphQL fields without an explicit resolver. Without an explicit resolver, graphql-ruby will subsequently use the attacker-controlled field to execute a callable Ruby method on the underlying object. Exploitation allows an unauthenticated attacker to invoke zero-argument Ruby methods to trigger limited command execution.
The attack conditions for CVE-2026-19478 are:
The attacker must be able to reach the GraphQL endpoint and resolve an object accessible without authentication, such as a public project or accessible user object.
The malicious query must use @gl_introduced, a GitLab-specific GraphQL directive, to specify a field that does not exist in the instance’s current GraphQL schema, while also specifying a future GitLab version. The @gl_introduced feature is meant to support version compatibility: fields introduced in a newer GitLab release can be ignored when triggered on an older back-end.
Exploiting the flawed logic causes the FutureFieldFallback Ruby module to synthesize a GraphQL::Schema::Field object for the otherwise nonexistent field requested by the client.
As documented by graphql-ruby, absent an explicitly configured method or resolver, the field name is used as the method name. This step of the exploit chain allows the attacker-controlled field name to trigger a callable Ruby method.
For modification or deletion, the triggered Ruby method must be a state-changing method that can be executed without arguments on the exposed object. Public detection material demonstrates using the touch Ruby method against a public project or associated user data.
Mitigating CVE-2026-19478 and CVE-2026-19650 in GitLab CE/EE
CVE-2026-19478 affects all versions of the 18.2, 19.0, 19.1, and 19.2 branches of self-managed GitLab CE/EE installations prior to the patched releases. GitLab has released patches in versions 18.11.11, 19.0.8, 19.1.6, and 19.2.4. For organizations operating self-managed GitLab CE/EE, upgrading to a fixed release is the primary mitigation. GitLab.com and GitLab Dedicated users do not need to take action.
Product
Affected versions
Fixed version
GitLab Community Edition (CE) and Enterprise Edition (EE)
all versions of 18.2 before 18.11.11
18.11.11
GitLab CE and EE
all versions of 19.0 before 19.0.8
19.0.8
GitLab CE and EE
all versions of 19.1 before 19.1.6
19.1.6
GitLab CE and EE
all versions of 19.2 before 19.2.4
19.2.4
No workarounds or temporary mitigations have been provided by the vendor. However, for users that cannot immediately patch, additional compensating controls can be implemented to reduce the risk posed by CVE-2026-19478 and CVE-2026-19650:
Restrict external access to self-managed GitLab instances where operationally feasible
Limit public accessibility to repositories wherever possible
Monitor for rogue GraphQL requests and unauthorized changes to projects or user data
Patching should be prioritized for internet-accessible instances. However, both CVEs could also be exploited by attackers who already have a foothold inside the victim’s network or by malicious insiders. Security teams should also evaluate the integrity of public projects and associated user data, particularly where GitLab is linked to build or release workflows.
Summary
GitLab versions 18.11.11, 19.0.8, 19.1.6, and 19.2.4 have been released to fix CVE-2026-19478 and CVE-2026-19650. The flaws affect all previous versions of the affected release branches. CVE-2026-19478 is an actively exploited, critical-severity code injection flaw in the GraphQL directive that allows unauthenticated attackers to remotely modify or delete public projects and user data. Publicly available technical write-ups [1][2][3] and PoC exploits [4][5][6] further increase the urgency of upgrading affected GitLab systems. Multiple national CERT agencies have issued alerts for the flaw [7][8][9][10][11][12][13][14][15][15][16], indicating a high level of global risk.
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.
➡
Start Your Free Trial
Grabbing a copy of OPENVAS SCAN with a free two-week trial of the OPENVAS ENTERPRISE FEED is a surefire way to gain the deepest insight into where software vulnerabilities exist in your organization’s IT infrastructure.
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
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.
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
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.
➡
Start Your Free Trial
Grabbing a copy of OPENVAS SCAN with a free two-week trial of the OPENVAS ENTERPRISE FEED is a surefire way to gain the deepest insight into where software vulnerabilities exist in your organization’s IT infrastructure.
https://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.png00Greenbone AGhttps://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.pngGreenbone AG2026-08-21 12:56:352026-08-24 10:48:32Wiz Loves OPENVAS! Our Take on Being a Top Vulnerability Management Tool of 2026
