CISA’s alert says the additions were based on evidence of active exploitation. The agency did not publish technical indicators or a campaign attribution in the announcement, but independent research from Wiz fills in a significant part of the Artifactory picture: attackers have reportedly chained the two listed JFrog flaws to turn an unauthenticated request into administrator-level access on self-hosted Artifactory servers. ConnectWise, meanwhile, says CVE-2026-84869 can allow unauthorized file transfer and execution through an active remote ScreenConnect session, although it maintains that ScreenConnect servers themselves are not affected.
The difference in attack paths matters. Artifactory often sits in the build and release path holding private packages, container images, credentials, and deployment integrations. ScreenConnect is commonly a privileged remote-management channel into Windows endpoints. A successful compromise of either can create a path well beyond the initially vulnerable application.
The two Artifactory CVEs form a more serious chain
CVE-2026-42018 is an improper-authentication vulnerability in JFrog Artifactory. JFrog says an unauthenticated caller could receive an internal anonymous-user token even when anonymous access is disabled. By itself, that exposed token is limited to the access granted to Artifactory’s internal anonymous identity.
CVE-2026-42016 is an authorization-validation weakness. JFrog describes it as a flaw in how Artifactory validates a token’s signature and issuer without properly enforcing its intended scope. An attacker who already has a low-privilege token may be able to obtain permissions beyond that token’s legitimate scope.
Wiz reported on September 10 that attackers had chained these weaknesses against self-hosted Artifactory instances between August 15 and September 8. In Wiz’s account, CVE-2026-42018 supplied the anonymous token and CVE-2026-42016 elevated it into an administrator-scoped token. Wiz observed persistent administrator accounts, malicious Groovy plugins, shell-command execution through plugin endpoints, and Rust-based backdoors after compromise.
That finding changes the priority calculation for teams that had categorized CVE-2026-42016 as requiring a pre-existing low-privilege identity. In isolation, that is true of the authorization issue. In the observed chain, the second CVE supplies the lower-privilege foothold without a normal login. The pair must be treated as a route from an internet-accessible Artifactory service to administrative control.
JFrog’s advisories show why a generic “upgrade Artifactory” ticket is insufficiently precise. CVE-2026-42016 affects versions earlier than 7.133.11. CVE-2026-42018 has a different affected range and multiple fixed releases depending on the maintenance branch: 7.111.20, 7.117.27, 7.125.19, 7.133.28, or 7.146.8. Later branch releases may contain additional security fixes, and administrators should select the current supported fixed build for their deployed branch rather than stopping at an older minimum version.
JFrog says affected cloud environments have already been fortified for both issues. That does not remove work for customers operating self-hosted Artifactory, nor does it answer whether a self-hosted server was reached before it was patched. The distinction is especially important in organizations where Artifactory is installed on Linux infrastructure but feeds Windows developer workstations, Azure DevOps pipelines, IIS deployments, or endpoint software packaging systems.
Patch Artifactory, then investigate it as a potential breach
CISA KEV status means the remediation workflow should include evidence gathering before logs age out. An Artifactory system patched today may no longer be vulnerable, but an attacker-created administrator account, token, plugin, or altered artifact can persist after the original bug is closed.
Wiz’s reported activity gives administrators useful starting points. Review Artifactory access logs for an unexpected successful request to the anonymous-token endpoint, especially a 401 response on the normal path followed shortly by a 200 response to a variant of that path. Also investigate low-privilege or anonymous identities creating tokens, enumerating users or repositories, accessing plugin paths, or making administrative changes.
The highest-value post-patch checks should include:
- Review all Artifactory users, groups, access tokens, API keys, SSH keys, and administrative roles for recently created or unrecognized entries.
- Inspect installed Groovy plugins and server-side automation for unauthorized code, particularly plugins able to run operating-system commands.
- Check repository contents, build metadata, and promoted release artifacts for unexpected modifications, because a repository manager compromise can become a downstream software-supply-chain incident.
- Rotate credentials and tokens stored in or accessible through the instance if there is evidence of administrative access, including integration credentials used by CI/CD systems.
- Restrict public network access to self-hosted Artifactory while the review is underway, allowing only trusted build systems and administrators where operations permit.
Wiz reported that some attacker-created accounts used obvious names such as Nxploited, labadmin, and svc_ variants, while other names were designed to blend in with JFrog components or routine services. Name matching is useful for triage, but it is not enough. Audit timestamps, account creation sources, assigned roles, tokens issued, and subsequent activity.
The key operational error would be to let the availability of a patch become the end of the incident. CISA’s new Binding Operational Directive 26-04 puts added emphasis on checking whether an actor compromised a system before remediation when the risk profile warrants it. Although that directive applies directly to Federal Civilian Executive Branch agencies, its logic applies to any organization with exposed build infrastructure: when exploitation is known, patch deployment and compromise assessment are two separate tasks.
ScreenConnect CVE-2026-84869 affects active sessions, not the server
CVE-2026-84869 is a different kind of urgent issue. ConnectWise’s September 8 bulletin says the vulnerability affects ScreenConnect versions before 26.6.5 and may permit files to be transferred and executed through an active remote session without authorization or host confirmation in certain circumstances. It carries a CVSS 3.1 score of 9.9 and is associated with missing authorization and improper privilege management.
ConnectWise states that ScreenConnect servers are not impacted. That is an important correction to the instinct many administrators will have after previous ScreenConnect emergencies: this advisory does not describe a server takeover flaw. The risk is in the client and session handling around file-transfer and execution actions.
That narrower technical scope does not make the business impact narrow. ScreenConnect is used precisely because it bridges technicians and managed devices. If a malicious or unauthorized file can cross an active support session and execute without proper host confirmation, the meaningful exposure is on the endpoint or remote participant in that session. In a Windows fleet, that can translate into malicious payload delivery to a workstation, server, or customer device through a tool that is normally trusted and often highly privileged.
ConnectWise has released ScreenConnect 26.6.5 as the fix. Its cloud instances have been updated automatically, but the company says customers should reinstall host clients and update access agents after the platform update. On-premises installations need an upgrade to 26.6.5, and ConnectWise says systems must be on version 25.4 or later to move directly to that release.
There is also an operational catch for self-hosted customers: ConnectWise says that an expired maintenance entitlement can prevent installation of the latest supported release. That is not a reason to defer the fix. It is a reason to identify licensing and upgrade-path blockers immediately, before a security change freezes into a commercial support problem.
For teams that cannot patch at once, ConnectWise’s temporary mitigation is to remove the TransferFiles permission — called TransferFilesInSession on legacy releases — from every assigned role and session group. This reduces exposure but does not replace the update. Because the vulnerability is tied to active-session behavior, administrators should verify the effective permissions of actual technician and guest roles rather than assuming a global policy setting covers every custom role.
Treat remote-support software as a controlled delivery channel
ScreenConnect’s placement in the KEV catalog means organizations should examine recent session activity, especially unusual file-transfer events, unrecognized technician activity, and unexpected executable launches tied to support windows. ConnectWise recommends reviewing users, roles, permissions, passwords, and MFA after patching; those steps are prudent, but the starting point should be a clear inventory of who can initiate sessions and who retains file-transfer rights.
MSPs have an added obligation here. A ScreenConnect configuration often centralizes access to multiple customer environments, while a client and agent update may involve endpoints the provider does not continuously manage. The remediation plan should distinguish between updating the central on-premises ScreenConnect installation and confirming that its deployed host clients and access agents were refreshed. Declaring success after the server reaches 26.6.5 risks leaving the vulnerable component in place.
CISA’s addition of these CVEs is a warning about exploitation, not a substitute for a remediation plan. Self-hosted Artifactory operators should upgrade and hunt for administrative persistence now; ScreenConnect operators should move clients and agents to 26.6.5, remove file-transfer permissions where an immediate upgrade is impossible, and review recent remote-support activity. The common thread is that both products sit on trusted administrative paths — exactly where a small authorization failure can have consequences far outside the application that first exposed it.