CISA added three vulnerabilities to its Known Exploited Vulnerabilities Catalog on September 11, 2026: CVE-2026-42016 and CVE-2026-42018 affecting JFrog Artifactory, and CVE-2026-84869 affecting ConnectWise ScreenConnect. Their inclusion in KEV means CISA has evidence that attackers are exploiting these vulnerabilities in real environments, which should immediately move them above similarly scored but unexploited flaws in remediation queues. The two Artifactory vulnerabilities are especially important when considered together. CVE-2026-42018 allows an unauthenticated attacker to obtain an internal anonymous-user token even when anonymous access has been disabled, while CVE-2026-42016 allows a low-privileged token to be elevated because Artifactory validates the token’s signature and issuer without correctly enforcing its intended scope. Neither flaw necessarily provides administrative control by itself, but Wiz has observed attackers chaining them so that an unauthenticated request first obtains the anonymous token and then exchanges that token for one carrying administrative privileges. CVE-2026-84869 presents a different attack model in ScreenConnect, where files can under certain circumstances be transferred and executed through an active remote session without the required authorization or confirmation by the host. CISA has therefore added three different CVEs, but operationally they tell one consistent story: trusted identity and remote-management mechanisms are increasingly being abused as the pathway to deeper compromise. 

CVE-2026-42018 is an improper-authentication vulnerability in JFrog Artifactory rated High at CVSS 7.5. Under vulnerable conditions, Artifactory can return an internal token associated with the anonymous user to an unauthenticated caller even though anonymous access has supposedly been disabled. JFrog lists affected versions before 7.111.20, 7.117.0 through versions before 7.117.27, 7.125.0 through versions before 7.125.19, 7.133.0 through versions before 7.133.28, and 7.146.0 through versions before the relevant fixed build. Cloud environments have already been fortified by JFrog, while self-hosted customers need to upgrade. At first glance, the vulnerability may appear less severe than a conventional remote-code-execution flaw because obtaining an anonymous-user token does not automatically provide complete administrative access. Real-world exploitation demonstrates why that interpretation would be dangerously incomplete. The token becomes the first stage of a chain rather than the final objective, and once the attacker possesses a legitimate signed token recognized by Artifactory, CVE-2026-42016 can potentially transform that limited identity into something much more powerful.

CVE-2026-42016 is the privilege-escalation half of that chain. JFrog describes it as an incorrect authorization vulnerability caused by insufficient validation of token scope. Artifactory correctly verifies that a token has a legitimate signature and was issued by a trusted issuer, but vulnerable versions fail to enforce what that token was actually authorized to do. This distinction between authentication and authorization is fundamental. A valid signature proves that the token itself is genuine, but it does not mean the holder should be permitted to perform administrative operations. Wiz observed attackers exploiting precisely this gap by taking the token obtained through CVE-2026-42018 and exchanging it for an administrative-scoped token. From that point onward, subsequent requests are technically authenticated, which means post-exploitation activity can increasingly resemble normal administrative behavior rather than obvious exploitation traffic. JFrog’s advisory describes CVE-2026-42016 as a privilege-escalation flaw affecting self-hosted Artifactory versions before the applicable fixed releases, and CISA’s September 11 KEV entry confirms that the vulnerability has moved decisively from theoretical weakness to practical attacker capability.

The exploitation chain documented by Wiz is particularly instructive because it shows how quickly a seemingly modest authentication weakness can become full administrative compromise. Researchers observed attackers first sending an unauthenticated request that caused Artifactory to return a JWT for the internal anonymous identity through CVE-2026-42018. The attackers then submitted that token to Artifactory’s token-generation functionality and exploited CVE-2026-42016 to obtain an administrative-scoped token. Wiz reports that in some observed incidents attackers progressed from the initial unauthenticated request to creation of a persistent administrator account in less than five minutes. This is exactly why organizations should not evaluate the two vulnerabilities independently. A vulnerability scanner may label CVE-2026-42018 as a confidentiality-oriented CVSS 7.5 flaw and CVE-2026-42016 as a High-severity privilege issue, but an attacker sees an unauthenticated-to-admin pathway requiring only two requests. Security risk belongs to the chain, not necessarily to the highest individual CVSS number within it.

Once administrative privileges were obtained, Wiz observed a wide range of post-exploitation activity, including creation of persistent administrator accounts, deployment of malicious Groovy plugins, command execution through Artifactory’s plugin framework, web-shell placement, download of second-stage payloads into writable directories such as `/tmp` and `/dev/shm`, and installation of a custom Rust-based backdoor capable of communicating with attacker command-and-control infrastructure. These actions demonstrate why Artifactory should be treated as part of the software supply-chain security boundary rather than simply as another repository application. An Artifactory administrator can potentially access software artifacts, package repositories, deployment credentials, tokens, configuration, and integrations used by development and production environments. Compromising the repository manager can therefore provide attackers with something considerably more valuable than control over one server: a position upstream from the software and infrastructure that the organization trusts.

The software-supply-chain implications are particularly serious. Artifactory frequently acts as the trusted internal source from which build systems obtain libraries, container images, packages, and other artifacts. Developers and CI/CD systems may deliberately trust packages retrieved from Artifactory more than content downloaded directly from the public internet. An attacker with administrative access can potentially exploit that trust relationship. Even where the observed campaign primarily created backdoors and administrator accounts, defenders need to consider whether artifacts, repository configuration, build integrations, or credentials were manipulated while the attacker controlled the platform. A compromised package repository is dangerous not merely because attackers can steal what it contains, but because they may be able to influence what downstream systems consume. This turns repository compromise into a potential distribution mechanism, allowing one intrusion to propagate toward developer workstations, build systems, containers, or production environments depending on how the organization uses Artifactory.

Credential exposure compounds that risk. Artifactory installations may contain repository tokens, service credentials, cluster secrets, cloud integration material, and other authentication information required for automated software delivery. Wiz observed attackers targeting configuration and token-related resources in related Artifactory exploitation, including persistent token creation and administrator account creation. Organizations that identify exploitation should therefore not assume that removing a malicious account and installing the patch restores trust. They need to determine what secrets were accessible during the compromise period and rotate those that may have been exposed. A stolen long-lived token remains valid after the vulnerability itself has been patched, which is why credential remediation must accompany software remediation whenever attackers obtained administrative control.

The CISA deadlines also reflect a difference in how the three vulnerabilities are being treated operationally. CISA lists CVE-2026-42016 and CVE-2026-42018 with a federal remediation deadline of September 25, 2026, while the ScreenConnect vulnerability CVE-2026-84869 has a much shorter September 14 deadline and requires forensic triage under BOD 26-04. CISA currently lists ransomware use as unknown for these vulnerabilities. The absence of confirmed ransomware use should not reduce urgency, because KEV inclusion already establishes that exploitation exists. CISA also does not require forensic triage for the two Artifactory flaws under the relevant directive, but organizations with exposed vulnerable Artifactory instances should still perform compromise hunting because Wiz has independently documented successful exploitation and persistent post-compromise activity. Regulatory minimums and sensible incident response are not always identical things.

CVE-2026-84869 in ConnectWise ScreenConnect represents a different but equally important failure of trust boundaries. ConnectWise describes the issue as a combination of missing authorization and improper privilege management in the ScreenConnect client that can allow files to be transferred and executed through an active remote session without the required authorization or confirmation from the Host in certain circumstances. The vulnerability carries a CVSS v3.1 score of 9.9, requires low privileges but no user interaction, and affects ScreenConnect versions prior to 26.6.5. ConnectWise released version 26.6.5 on September 8 and says ScreenConnect servers themselves are not directly affected; the vulnerable behavior occurs within client and session handling. Cloud environments are being upgraded by ConnectWise, while on-premises customers need to install the corrected version and ensure host clients and access agents are appropriately updated.

That server-versus-client distinction is important because it prevents the flaw from being exaggerated into an unauthenticated ScreenConnect server takeover. CVE-2026-84869 requires circumstances involving an active remote session and low-privileged access. However, those requirements should not make organizations complacent. ScreenConnect exists specifically to provide remote control of endpoints, meaning even a relatively limited privilege inside the platform can sit extraordinarily close to powerful functionality. If an attacker can transfer and execute files through an active remote-support session without obtaining the authorization or host confirmation normally required, the legitimate remote-management mechanism itself becomes the malware-delivery channel. The remote-access agent does not need to be exploited in the traditional sense if attackers can persuade it to perform actions that should have been blocked by session authorization rules.

This is precisely why remote monitoring and management platforms have become such valuable targets. RMM and remote-support products are deliberately allowed to perform operations that would look highly suspicious from ordinary software: execute programs, transfer files, interact with desktops, install components, and administer remote systems. Security tools may also treat these agents as trusted because they are legitimately deployed by the organization. An attacker abusing ScreenConnect can therefore potentially make malicious activity arrive through a process and communication path that defenders expect to see. Detection needs to understand who initiated an action, what session it belonged to, and whether the requested privilege was appropriate rather than simply trusting activity because it originated from approved remote-management software.

ConnectWise’s remediation guidance reflects the seriousness of the issue. The company recommends upgrading immediately to ScreenConnect 26.6.5 or later and classifies the update as Priority 1, meaning it should be handled as an emergency change or installed within days. For environments where immediate installation is impossible, ConnectWise had previously recommended temporarily removing `TransferFiles` or the legacy `TransferFilesInSession` permission from relevant ScreenConnect roles and session groups. Once the patched version is installed, administrators are advised to review users, roles, permissions, passwords, and MFA configuration.

CISA’s decision to require forensic triage for CVE-2026-84869 is especially important because patching an RMM vulnerability does not establish whether an attacker previously used a legitimate remote session to deliver files or commands. Organizations should review ScreenConnect session histories, file-transfer events, unexpected process execution, account changes, and remote sessions involving unfamiliar operators or endpoints. Endpoint telemetry should be correlated with ScreenConnect activity to identify executables that appeared immediately after remote sessions, particularly where those files originated from unusual operator accounts or were executed without normal user confirmation. Since RMM platforms can touch many endpoints, one compromised identity or abused session may have downstream effects across a large customer estate.

The JFrog and ScreenConnect vulnerabilities also share an important identity-security theme even though their technical mechanisms are very different. The Artifactory chain begins by creating a token the system itself recognizes as legitimate and then abusing inadequate authorization checking to increase its privileges. The ScreenConnect flaw operates within a legitimate remote session but fails to enforce the authorization normally required for sensitive file-transfer and execution behavior. In both cases, the problem appears after some representation of trust has already been established. This is an increasingly common attacker strategy because exploiting trust is often easier than defeating every technical control protecting the underlying system.

For defenders, this means authorization telemetry deserves as much attention as authentication telemetry. Security systems traditionally focus heavily on failed logins, brute-force attempts, impossible travel, and suspicious credential use. Those remain important, but once an attacker obtains or manufactures a legitimate token, subsequent operations may produce no authentication failure at all. Security teams need to detect when a low-privilege token suddenly requests administrative capabilities, when an anonymous identity begins minting tokens, when a remote-support operator performs actions outside its normal role, or when an account creates persistent administrators shortly after authentication. Identity is not merely who the system thinks the user is; security also depends on whether the actions performed by that identity make sense.

Organizations running self-hosted Artifactory should therefore patch immediately and examine authentication and token-generation logs for behavior associated with the exploit chain. Wiz identifies a particularly useful pattern in which a request to the relevant AWS token endpoint returns an internal anonymous JWT, followed by the same identity interacting with token-generation endpoints and subsequently creating administrator users or accessing plugin functionality. Administrators should also review unexpected accounts, especially recently created privileged identities, inspect Groovy plugins and repository scripts, search temporary directories for unfamiliar binaries, and investigate outbound connections from the Artifactory service. Static indicators such as attacker IP addresses or filenames are useful, but behavioral indicators are more durable because attackers can change infrastructure far faster than organizations can update blocklists.

Organizations should additionally verify that every Artifactory instance is known and patched. Development environments have an unfortunate tendency to multiply, leaving staging repositories, migration systems, disaster-recovery instances, or forgotten proof-of-concept servers outside normal maintenance processes. An old Artifactory server may still contain source packages and credentials even if developers no longer actively use it. External attack-surface monitoring should therefore identify every internet-reachable Artifactory service associated with the organization, while internal inventories should ensure secondary systems receive the same security attention as the primary production platform.

Network exposure should also be reduced where possible. Artifactory commonly needs to communicate with developers, CI runners, upstream repositories, and deployment systems, but that does not automatically mean every management and authentication endpoint needs to be publicly accessible. Network restrictions, reverse proxies, VPN access, or zero-trust gateways can reduce exploitability, particularly for administrative interfaces. Similarly, ScreenConnect servers and operator interfaces should be reachable only from networks and identities that genuinely require access. Reducing exposure does not replace patching, but it removes opportunities attackers would otherwise have to reach vulnerable functionality.

The September 11 KEV update ultimately demonstrates why vulnerability management cannot be reduced to sorting a spreadsheet by CVSS score. CVE-2026-42018 scores 7.5, CVE-2026-42016 is High severity, and CVE-2026-84869 scores 9.9. If defenders looked only at those numbers, ScreenConnect would obviously appear to dominate the response queue. Yet attackers have already shown that the two lower-rated Artifactory flaws can be chained into unauthenticated administrative access and followed by persistent account creation, arbitrary command execution, web shells, and backdoors. The real-world chain is far more severe than either individual score implies.

This is one of the strongest reasons CISA’s KEV Catalog is useful. CVSS explains what a vulnerability might allow under defined technical assumptions, while KEV tells defenders that someone has already demonstrated enough practical value to use the weakness against real targets. Neither metric is perfect, but confirmed exploitation should be one of the strongest inputs into patch prioritization. The September 11 additions are especially instructive because they show attackers operating at two different layers of enterprise trust: the software repository responsible for supplying applications and packages, and the remote-management system responsible for controlling endpoints.

The broader security lesson is therefore about concentration of trust. Artifactory is trusted to store and distribute software artifacts. ScreenConnect is trusted to remotely control endpoints. Those privileges exist because organizations need them, but the same privileges make these platforms exceptionally valuable to attackers. An attacker who compromises an ordinary application may control one application. An attacker who compromises the systems that distribute software or remotely administer machines may inherit a path toward many systems at once. That is why these three vulnerabilities should not be treated simply as another CISA patch alert. They affect platforms sitting upstream from large portions of enterprise infrastructure, and once attackers reach those platforms, the trusted administration and software-delivery mechanisms themselves can become part of the attack.

CISA has added three new vulnerabilities to its Known Exploited Vulnerabilities (KEV) Catalog , based on evidence of active exploitation. CVE-2026-42016 JFrog Artifactory Incorrect Authorization Vulnerability CVE-2026-42018 JFrog Artifactory Improper Authentication Vulnerability CVE-2026-84869 ConnectWise ScreenConnect Improper Privilege Management and Missing Authorization Vulnerability These types of vulnerabilities are a frequent attack vector for malicious cyber actors and pose significant risks to the federal enterprise. Binding Operational Directive (BOD) 26-04: Prioritizing Security Updates Based on Risk establishes vulnerability management requirements for Federal Civilian Executive Branch (FCEB) agencies. BOD 26-04 reinforces the importance of the KEV Catalog and requires federal agencies to prioritize rapid remediation of high-risk vulnerabilities, specifically those identified by Common Vulnerabilities and Exposures (CVEs) listed in CISA’s KEV Catalog on publicly exposed assets that grant total control of the asset post-exploitation, while deferring action for lower-risk vulnerabilities. BOD 26-04 further establishes basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied. While BOD 26-04 applies only to FCEB agencies, CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities . CISA will continue to add vulnerabilities to

Source: CISA Adds Three Known Exploited Vulnerabilities to Catalog via CISA Advisories — published 11 Sep 2026.