CVE-2026-7273 (CVSS 8.8, EPSS 1.286% (69th)), published in mid-June 2026, is a stack-based buffer overflow that allows unauthenticated remote code execution (RCE) on Zyxel GS1900 series switches. The flaw is in the device’s firmware CGI program and can be triggered via crafted HTTP request. As of September 21st, 2026, CVE-2026-7273 is considered actively exploited and has been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog. According to Zyxel’s advisory, ten GS1900 models are affected. Several national CERT alerts were issued soon after the CVE’s initial disclosure [1][2] and several more have been issued since active exploitation was uncovered [3][4][5].
Immediate Action Recommended
Greenbone’s OPENVAS ENTERPRISE FEED added a remote banner check for CVE-2026-7273 immediately after the CVE was published in June 2026. Patches have also been available since the disclosure. Regular vulnerability scanning with OPENVAS SCAN allows defenders to identify and patch affected products before attackers can cause damage. Due to the elevated risk signals, users should upgrade the firmware of their Zyxel GS1900 series switches as soon as possible.
A Risk Assessment of CVE-2026-7273 in Zyxel GS1900 Switches
Zyxel GS1900 series switches are smart-managed devices, marketed to small businesses. Their capabilities include VLAN management, Quality of Service (QoS) traffic control, IGMP snooping, Link Aggregation Grouping (LAG), and Denial of Service (DoS) defense.
An attacker with network access to the web interface of a vulnerable switch can exploit CVE-2026-7273 remotely without authentication, privileges, or user interaction by sending a crafted HTTP request to a vulnerable device. Because CVE-2026-7273 allows the execution of OS commands [T1059] on Zyxel GS1900 series switches, an attacker can trigger DoS conditions [T1499.004], or more complex attacks to achieve full arbitrary code execution. Compromise can expose device credentials [T1003] and configuration data [T1602.002], expose traffic on the network to snooping [T1040], and potentially allow data theft [TA0010] or lateral movement [TA0008] to other network devices. This makes the flaw serious for enterprise and small-business environments where administrative interfaces are reachable from internal network segments.
Risk is elevated further by reports of exploitation in the wild. GreyNoise observed attacks targeting CVE-2026-7273 as early as August 17th, and the CVE was added to CISA’s KEV list on September 21st. In total, Zyxel has had 13 entries on CISA’s KEV list since 2021. Two of those entries are associated with ransomware attacks. The GreyNoise report included a technical analysis of the flaw and a reverse-engineering analysis of the Python-based malware payload. However, no fully functional proof-of-concept (PoC) exploits are yet available online.
The Technical Details of CVE-2026-7273
CVE-2026-7273 (CVSS 8.8, EPSS 1.286% (69th)) is a stack-based buffer overflow flaw [CWE-121] in the CGI program of GS1900 series switch firmware. Exploitation happens via memory corruption rather than conventional command injection [CWE-77]. An attacker with network access to the web interface of a vulnerable switch can exploit CVE-2026-7273 remotely without authentication, privileges, or user interaction via specially crafted HTTP request. During request processing, user-supplied data is written to a stack-allocated buffer without adequate bounds checking.
The Python-based exploit analyzed by GreyNoise contains command-line parameters for a libc base address, the address of an object named reqParameters, the Global Offset Table (GOT) entries for strcmp(), and system() within libc. GOT is a data structure used by ELF executables and shared libraries on Linux and other Unix-like systems to resolve addresses that are not known until runtime. The payload’s parameters indicate that the exploit converts a memory-corruption flaw into controlled execution by manipulating dynamically linked function locations. Data that would ordinarily be supplied to strcmp() is redirected to system() to achieve OS command execution on the victim’s computer. However, the GreyNoise analysis doesn’t reveal the full exploit path.
The Campaigns Targeting Zyxel GS1900 Switches
GreyNoise observed that in-the-wild exploitation began on August 17th, 2026. The report described post-compromise data theft from 996 compromised switches across 48 countries. During a successful exploitation, commands were executed via the device’s shell environment. GreyNoise observed the attacker invoking /bin/sh and using the switch’s Trivial File Transfer Protocol (TFTP) client to import a malicious second-stage payload onto the infected device.
Attackers then staged the stolen data in the device’s /home/web/tmp/ directory where it could be retrieved via HTTP request. Attackers exfiltrated hashed root credentials [T1003], configuration data [T1602.002], and networking information from affected devices. GreyNoise also ties exploitation of CVE-2026-7273 to a broader campaign that leveraged software flaws in multiple other technologies including Ubiquiti UniFi OS, WordPress, the Linux kernel, Gitea, Proxmox VE, and PAN-OS GlobalProtect.
Affected Zyxel GS1900 Models and Mitigation for CVE-2026-7273
Immediate Action Recommended
Greenbone’s OPENVAS ENTERPRISE FEED added a remote banner check for CVE-2026-7273 immediately after the CVE was published in June 2026. Patches have also been available since the disclosure. Regular vulnerability scanning with OPENVAS SCAN allows defenders to identify and patch affected products before attackers can cause damage. Due to the elevated risk signals, users should upgrade the firmware of their Zyxel GS1900 series switches as soon as possible.
Zyxel published firmware patches for affected models in a community advisory on June 16th, 2026. No workaround mitigations are available for CVE-2026-7273. Organizations using the affected models should treat the updates as a priority. CISA has also assigned the relatively new forensicTriage flag to CVE-2026-7273 indicating that users should conduct a forensic analysis to determine whether an affected device has already been compromised.
The Zyxel models affected by CVE-2026-7273 are listed below:
Model
Affected versions
Fixed versions
GS1900-8
2.90(AAHH.1)C0 and earlier
2.90(AAHH.2)C0
GS1900-8HP
2.90(AAHI.1)C0 and earlier
2.90(AAHI.2)C0
GS1900-10HP
2.90(AAZI.1)C0 and earlier
2.90(AAZI.2)C0
GS1900-16
2.90(AAHJ.1)C0 and earlier
2.90(AAHJ.2)C0
GS1900-24
2.90(AAHL.1)C0 and earlier
2.90(AAHL.2)C0
GS1900-24E
2.90(AAHK.1)C0 and earlier
2.90(AAHK.2)C0
GS1900-24EP
2.90(ABTO.1)C0 and earlier
2.90(ABTO.2)C0
GS1900-24HPv2
2.90(ABTP.1)C0 and earlier
2.90(ABTP.2)C0
GS1900-48
2.90(AAHN.1)C0 and earlier
2.90(AAHN.2)C0
GS1900-48HPv2
2.90(ABTQ.1)C0 and earlier
2.90(ABTQ.2)C0
Summary
CVE-2026-7273 is a high-severity stack-based buffer overflow in the CGI program of Zyxel GS1900 series switch firmware that can be exploited by an unauthenticated attacker with network access to the devices. Exploitation allows OS command execution on the device. The flaw has been exploited in the wild, and some technical details for exploitation have been published. In the observed campaign, attackers focused on data exfiltration from breached devices.
Immediate Action Recommended
Greenbone’s OPENVAS ENTERPRISE FEED added a remote banner check for CVE-2026-7273 immediately after the CVE was published in June 2026. Patches have also been available since the disclosure. Regular vulnerability scanning with OPENVAS SCAN allows defenders to identify and patch affected products before attackers can cause damage. Due to the elevated risk signals, users should upgrade the firmware of their Zyxel GS1900 series switches as soon as possible.
Overview of CVE-2026-48842, the unauthenticated SQL injection flaw in Roundcube Webmail, shown with its CVSS severity band and EPSS exploitation-probability score
CVE-2026-48842 (CVSS 8.1, EPSS ≥ 54th pctl), published in May 2026, is an unauthenticated SQL injection flaw in Roundcube Webmail. Vulnerable instances warrant prompt attention due to the elevated risk signals. The flaw affects Roundcube Webmail 1.6.x before 1.6.16 and 1.7.x before 1.7.1.
Coalition has reported exploitation attempts against its honeypot, and on September 21st, the Canadian Centre for Cyber Security issued an update warning of the exploited status. However, CVE-2026-48842 has not been added to CISA’s Known Exploited Vulnerabilities (KEV) list.
Roundcube Webmail has a long record of in-the-wild exploitation, particularly in espionage-motivated attacks. CISA’s KEV catalog contains 11 Roundcube vulnerabilities. Previous attack campaigns have exploited SQL injection, Cross-Site Scripting (XSS) and other types of defects in Roundcube to steal credentials and sensitive email content, and establish persistent access to the victim’s servers.
Start Your Free Trial
After CVE-2026-48842 was released in May 2026, Greenbone’s OPENVAS ENTERPRISE FEED added package detection across multiple Linux distributions [1][2][3][4][5][6][7], as well as remote banner detection for CVE-2026-48842 in Windows [8] and Linux [9] instances of Roundcube Webmail. The ENTERPRISE FEED includes regular detection for vulnerabilities affecting Roundcube Webmail, including more recent critical-severity flaws. 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.
Risk Assessment of CVE-2026-48842 in Roundcube Webmail
Roundcube is a PHP-based web application and server that connects to separate IMAP and SMTP mail services. The multilingual user interface is used to access and manage email messages, while the server contains sensitive credentials to an organization’s email system. CVE-2026-48842 is a network-reachable vulnerability, and no credentials or privileges are required for exploitation.
CVE-2026-48842 also warrants prompt attention due to additional elevated risk signals. Coalition has reported exploitation attempts against its honeypot. However, the flaw has not been added to CISA’s Known Exploited Vulnerabilities (KEV) list. Roundcube also has a long record of in-the-wild exploitation, particularly for cyber espionage. Previous Roundcube exploitation campaigns have targeted Ukrainian government organizations [1][2], government and military entities across Eastern Europe, including Albania, Greece, Moldova, and Türkiye [3], European government entities and think tanks [4], and physics and engineering departments at U.S. and Canadian universities [5].
A Technical Assessment of CVE-2026-48842 in Roundcube Webmail
From a technical standpoint, CVE-2026-48842 (CVSS 8.1, EPSS ≥ 54th pctl) is an unauthenticated SQL injection flaw [CWE-89] in the virtuser_query plugin. The root cause is a bypass of backslash character escaping when user-supplied input is processed by the preg_replace() function. Analyzing the fixed GitHub commits [1][2] reveals that the vulnerability is not a general failure to SQL-escape input fields. After sanitizing user-supplied credentials via $dbh->escape(), inputs were subsequently passed to PHP’s preg_replace() function.
$dbh->escape() inserted backslashes to protect SQL metacharacters. However, backslashes have a different contextual impact in the subsequent preg_replace() function, allowing an attacker to bypass the applied SQL statement protections. The fixed code now performs a literal placeholder substitution via the PHP str_replace() function.
Affected Versions and Mitigation
CVE-2026-48842 affects Roundcube Webmail 1.6.x before 1.6.16 and 1.7.x before 1.7.1. Although the vendor has released security updates for the affected release lines [1][2], users should review recent vulnerability scans of their Roundcube Webmail infrastructure since new critical and high-severity CVEs, such as CVE-2026-75003, have emerged since the patches for CVE-2026-48842 were released. Due to the product’s history of exploitation in the wild, users should upgrade to the most recent fixed versions.
The most recent stable release trains for Roundcube Webmail are:
Release Train
Current Release
Release Date
Support Status
1.7.x
1.7.4
2026-09-06
Current stable release train; fully maintained
1.6.x
1.6.19
2026-09-06
LTS / low-maintenance release train; security and critical fixes only
Summary
CVE-2026-48842 is a high-severity pre-authentication SQL injection in Roundcube Webmail’s virtuser_query plugin affecting 1.6.x before 1.6.16 and 1.7.x before 1.7.1. Risk is elevated because active exploitation has been observed against honeypot instances and because of the product’s historical abuse in espionage-motivated attacks.
Start Your Free Trial
After its release in May 2026, Greenbone’s OPENVAS ENTERPRISE FEED added package detection for CVE-2026-48842 across multiple Linux distributions [1][2][3][4][5][6][7], as well as remote banner detection for CVE-2026-48842 in Windows [8] and Linux [9] instances of Roundcube Webmail. The ENTERPRISE FEED includes regular detection for vulnerabilities affecting Roundcube Webmail, including more recent critical-severity flaws. 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.
So far, Cisco has published 97 new CVE IDs affecting its products this month. Although cyber security experts have noted that raw CVE count is not a direct measure of risk, the total makes September Cisco’s largest-ever month for coordinated CVE disclosures. Also, 32 of the CVEs are “umbrella CVEs”—clusters of multiple underlying vulnerabilities grouped by CWE classification. Despite being officially discouraged by the CVE program, the approach is part of Cisco’s new disclosure policy to tackle AI-accelerated vulnerability discovery.
On September 16th, Cisco disclosed 42 new CVE IDs affecting ISE. CVE-2026-76460 (CVSS 10) was immediately marked as actively exploited and added to CISA’s KEV list. CVE-2026-76460 is classified as a critical authentication bypass in an API [CWE-648]. Exploitation allows an unauthenticated remote attacker to bypass authentication, gain unauthorized access to the web-based management interface, and execute commands with root privileges. The flaw can be exploited via HTTP request to an affected API endpoint.
Affected Versions and Mitigation for CVE-2026-76460
Product
Affected release
Fixed release
Cisco ISE / ISE-PIC
3.1
3.1 Patch 12
Cisco ISE / ISE-PIC
3.2
3.2 Patch 11
Cisco ISE / ISE-PIC
3.3
3.3 Patch 12
Cisco ISE / ISE-PIC
3.4
3.4 Patch 7
Cisco ISE / ISE-PIC
3.5
3.5 Patch 4
Where immediate patching is not possible, Cisco advises limiting traffic to the affected device by restricting management and control-plane traffic. The vendor also provides incident response guidance to identify any potential compromise. The OPENVAS ENTERPRISE FEED includes package-level detection for CVE-2026-76460 and broad vulnerability detection for Cisco flaws, including all new CVEs affecting ISE.
CVE-2026-76461: Cisco Secure Email Gateway Actively Exploited for Root-Level RCE
CVE-2026-76461 (CVSS 9.8) is an SQL injection vulnerability [CWE-89] in the email parsing logic of Cisco AsyncOS Software for Cisco Secure Email Gateway. The flaw is considered actively exploited and has been added to CISA’s KEV list. According to Cisco, a remote unauthenticated attacker can achieve root-level remote code execution (RCE) by sending a crafted email that contains malicious SQL statements to an affected device.
Affected Versions and Mitigation for CVE-2026-76461
Product
Affected release
Fixed release
Cisco Secure Email Gateway
15.5 and earlier
15.5.5-014
Cisco Secure Email Gateway
16.0
16.0.4-302
Cisco Secure Email Gateway
16.5
16.5.0-780
The OPENVAS ENTERPRISE FEED includes package-level detection for CVE-2026-76461 in Cisco Secure Email Gateway. Cisco advises users to review logs for suspicious entries, including the SQL command pattern COPY…TO PROGRAM. A breach carries additional risk of lateral movement for clustered deployments since exploitation may expose private SSH keys used between cluster members.
Broader Exposure for Cisco Secure Email Platform
In two separate advisories, Cisco issued seven additional CVE IDs that included five CVE clusters, covering various components of the Secure Email product family [1][2]. Four of the CVE IDs are rated critical severity, indicating they are remotely exploitable without authentication. The OPENVAS ENTERPRISE FEED includes package-level detection for the actively exploited CVE-2026-76461 and all other new vulnerabilities affecting Cisco Secure Email Gateway [1][2].
Critical-Severity CVE Clusters Across Cisco Secure Firewall Products
Cisco also disclosed 29 CVE IDs affecting Secure Firewall Adaptive Security Appliance (ASA), Secure Firewall Threat Defense (FTD), and Secure Firewall Management Center (FMC). Eight of the IDs are rated critical severity, indicating they include unauthenticated, remotely exploitable security issues. None have yet been tagged as actively exploited.
In a blog post, Cisco also provided details for active campaigns targeting CVE-2026-20079 (CVSS 10, EPSS ≥ 99th pctl) and CVE-2026-20316 (CVSS 5.3, EPSS ≥ 96th pctl) affecting FMC. Both are on CISA’s KEV list [4][5]. The latter, CVE-2026-20316, was added in July and is known to be associated with ransomware attacks, while CVE-2026-20079 is a new KEV list addition in September 2026.
The OPENVAS ENTERPRISE FEED includes separate package-level detection tests for all new CVEs affecting ASA [1], FTD [2], and FMC [3] and has included detection for the actively exploited CVE-2026-20079 [4][5] and CVE-2026-20316 [6] since their disclosure.
Seven CVE clusters were disclosed in Cisco’s September IOS XR Software Security Hardening Release. Two of the seven clusters are rated critical severity, indicating they include unauthenticated, remotely exploitable flaws. None have yet been tagged as actively exploited.
All IOS XR Software releases, including IOS XR7 (LNT), are affected regardless of device configuration. Fixes are available in IOS XR 26.2.2 and 26.3.1. No workarounds are available. Older supported trains, including 7.3, 7.9, 7.10, 7.11, 24.1–24.4, 25.1–25.4, 26.1, and 26.2, must first be upgraded to a maintenance release and then patched with the applicable Software Maintenance Updates (SMUs). See Cisco’s release advisory for more details. The OPENVAS ENTERPRISE FEED includes a remote banner check that covers all CVE clusters from the September IOS XR Software Security Hardening Release.
Cisco disclosed six CVE clusters in its Nexus Dashboard Hardening Release. Three of the six clusters are rated critical severity, indicating they include unauthenticated, remotely exploitable security issues. None have yet been tagged as actively exploited. No workarounds can mitigate the flaws, and all configurations of Cisco Nexus Dashboard are affected.
Product
Affected release
Fixed release
Cisco Nexus Dashboard
4.2 and earlier
Migrate to a fixed release
Cisco Nexus Dashboard
4.3
4.3.1.175
The OPENVAS ENTERPRISE FEED includes a remote banner check for all CVE clusters in the Nexus Dashboard Hardening Release. Users should update to a fixed version as soon as possible.
Summary
September 2026 marks Cisco’s largest coordinated vulnerability disclosure period to date, with 97 new CVE IDs spanning major enterprise security and networking products. Thirty-two are umbrella CVEs, meaning the actual number of underlying software flaws is unknown. So far this month, Cisco ISE, Secure Email Gateway, and FMC flaws have been added to CISA’s KEV list indicating active exploitation. Users should conduct regular vulnerability scans of their IT networks and endpoints to detect emerging security risks and prioritize mitigation.
https://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.png00Joseph Leehttps://www.greenbone.net/wp-content/uploads/greenbone-logo-2025.pngJoseph Lee2026-09-22 14:34:332026-09-22 14:34:33Patch Now! Heightened Risk Across Cisco Products in September 2026
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.
