CISA Adds Five Actively Exploited Vulnerabilities to KEV: Artifactory, ScreenConnect and RouterOS

CISA has added five vulnerabilities affecting JFrog Artifactory, ConnectWise ScreenConnect and MikroTik RouterOS to its Known Exploited Vulnerabilities catalog following reports of exploitation in the wild. The flaws include privilege escalation, authentication weaknesses, unauthorized file transfer and execution, kernel memory disclosure, and RouterOS privilege escalation.[1][2][3][4]

The latest addition brings together vulnerabilities affecting three products with very different attack surfaces: software supply-chain infrastructure, remote-access software and network operating systems. According to The Hacker News, CISA added CVE-2026-42016 and CVE-2026-42018 affecting JFrog Artifactory, CVE-2026-84869 affecting ConnectWise ScreenConnect, and CVE-2026-67277 and CVE-2026-86060 affecting MikroTik RouterOS.[1]

The individual vulnerabilities do not all provide the same capability, and they should not be treated as a single attack chain. The available evidence instead shows three separate product families with vulnerabilities that have reached the operational threshold represented by CISA's KEV program.[1][3]

The Five Vulnerabilities at a Glance

The scores above come from the available vendor or vulnerability records and should not be interpreted as interchangeable measurements. ConnectWise explicitly gives CVE-2026-84869 a CVSS v3.1 score of 9.9 with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.[3] CERT Polska reports CVE-2026-86060 with a CVSS v4.0 score of 9.2, while its advisory reports CVE-2026-67277 with a CVSS score of 8.8.[4]

JFrog Artifactory: Two Vulnerabilities in a Larger Exploitation Picture

Two of the newly listed vulnerabilities affect JFrog Artifactory: CVE-2026-42016 and CVE-2026-42018. JFrog's security advisory describes CVE-2026-42016 as an incorrect user-token authorization validation issue that can allow privilege escalation.[2]

JFrog lists CVE-2026-42016 as a high-severity vulnerability affecting Artifactory Self Hosted versions before 7.133.11.[2] The flaw involves validation of a token's signature and issuer without validating the token's scope.[2]

CVE-2026-42018 is another high-severity Artifactory issue. JFrog describes it as a condition in which Artifactory can return an internal anonymous-user token to an unauthenticated caller when anonymous access is disabled.[2]

JFrog lists the affected ranges for CVE-2026-42018 as versions below 7.111.20, as well as specific affected ranges in the 7.117, 7.125, 7.133 and 7.146 branches.[2] The corresponding fixes include 7.111.20, 7.117.27, 7.125.19, 7.133.28 and 7.146.8.[2]

The two vulnerabilities are particularly significant because subsequent reporting has documented their use together with another Artifactory vulnerability. The Hacker News reported that attackers chained CVE-2026-42018 and CVE-2026-42016 with CVE-2026-82329 to obtain administrative control of self-hosted Artifactory servers.[5]

Wiz reported that observed post-exploitation activity included creation of persistent administrator accounts, malicious Groovy plugins and Rust-based backdoors.[1] Those observations concern the reported Artifactory attacks and should not be generalized to every system affected by either CVE individually.[1][5]

Why the Artifactory Pair Matters to Software Supply Chains

Artifactory sits inside software-development and software-delivery workflows, where repositories can contain packages, binaries and other artifacts used by build systems. That makes unauthorized administrative access potentially more consequential than a compromise limited to an isolated application.[5]

However, defenders should separate demonstrated activity from potential downstream impact. The available reporting establishes exploitation and administrative compromise in observed cases, but it does not establish that every vulnerable Artifactory deployment was compromised or that every organization using an affected version suffered supply-chain impact.[1][5]

ConnectWise ScreenConnect: CVE-2026-84869

The third vulnerability is CVE-2026-84869, affecting ConnectWise ScreenConnect. ConnectWise describes the issue as a condition in the ScreenConnect client that may allow files to be transferred and executed through an active remote session without authorization or host confirmation in certain circumstances.[3]

The vendor explicitly states that ScreenConnect servers are not impacted by this vulnerability.[3] The affected component is the client, and ConnectWise says both cloud and on-premise deployments are within the scope of the advisory.[6]

ConnectWise assigns CVE-2026-84869 a CVSS v3.1 score of 9.9 with a critical attack profile. The published vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.[3]

ScreenConnect versions prior to 26.6.5 are affected. ConnectWise released version 26.6.5 on September 8, 2026 to address the vulnerability.[3]

For cloud deployments, ConnectWise says no customer action is required because cloud instances are upgraded automatically, although affected host clients and access agents may need to be reinstalled or updated after the upgrade.[3] On-premise customers are instructed to upgrade to ScreenConnect 26.6.5.[3]

ScreenConnect Exploitation and the Difference Between Client and Server Exposure

The distinction between the ScreenConnect client and server is important for incident response. A vulnerable client is not equivalent to a vulnerable ScreenConnect server, and ConnectWise explicitly states that the servers are not impacted by CVE-2026-84869.[3]

The Hacker News reported three unrelated incidents in which threat actors abused ScreenConnect to distribute a malicious VBScript payload to newly connected systems.[7] Those incidents demonstrate malicious use of ScreenConnect technology, but they should not automatically be attributed to CVE-2026-84869 without evidence connecting the vulnerability to those specific intrusions.[7]

ConnectWise nevertheless classifies the vulnerability as a high-priority issue and recommends emergency or rapid installation of the security update.[3]

MikroTik RouterOS: Two Vulnerabilities Added to KEV

The remaining two vulnerabilities affect MikroTik RouterOS: CVE-2026-67277 and CVE-2026-86060. Both were discovered and coordinated by CERT Polska as part of research into RouterOS vulnerabilities.[4]

CERT Polska reported on September 5 that attackers were actively exploiting a combination of RouterOS vulnerabilities against devices whose SSH services were accessible from public networks.[8] The organization described the observed attack chain as “MikroTrick” and said successful attacks could result in full control of affected devices.[8]

CVE-2026-67277: RouterOS Memory Disclosure and Denial of Service

CERT Polska describes CVE-2026-67277 as a missing-authentication-for-critical-function vulnerability. RouterOS accepts a related bandwidth-test connection before the associated primary session has completed authentication.[4]

An unauthenticated client can use that state to start an IPv4 UDP bandwidth test. CERT Polska says the vulnerable behavior can expose uninitialized data from a kernel packet buffer, while a separate size-validation problem can cause an integer underflow and trigger anomalously large fragmented output or a RouterOS kernel restart.[4]

CERT Polska lists affected RouterOS versions as releases from 7.24 below 7.24.2, from 7.0.0 below 7.23.4, and from 6.0.0 below 6.49.21.[4] MikroTik states that fixes were released in 7.25 beta 3, 7.24.2, 7.23.4 and 6.49.21.[9]

The vulnerability therefore has two distinct security implications: information disclosure through kernel memory exposure and potential denial of service through kernel instability.[4] Neither should be confused with remote code execution; the sources reviewed for this article do not establish RCE for CVE-2026-67277.[4]

CVE-2026-86060: RouterOS SSH Privilege Escalation

CVE-2026-86060 is a separate RouterOS vulnerability involving argument handling in the SSH login path. CERT Polska says usernames beginning with a prohibited character can be used to manipulate the trusted RouterOS policy mask and elevate privileges.[4]

The resulting session can obtain full administrative privileges in RouterOS, according to CERT Polska's active-exploitation advisory.[8] Exploitation requires an unauthenticated SSH session to reach the RouterOS login helper.[4]

CERT Polska lists affected versions as RouterOS 7.24 below 7.24.2, 7.0.0 below 7.23.4, and 6.0.0 below 6.49.21.[4] The corresponding fixes are 7.24.2, 7.23.4 and 6.49.21.[4]

CERT Polska's vulnerability record assigns CVE-2026-86060 a CVSS v4.0 score of 9.2 Critical with the vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.[10]

The MikroTrick Campaign Changes the Risk Calculation

The RouterOS vulnerabilities deserve particular attention because exploitation has been observed in real attacks rather than merely demonstrated in a laboratory. CERT Polska says it observed attacks against RouterOS devices accessible from the internet and confirmed exploitation of a combination of vulnerabilities to take full control of devices with publicly reachable SSH.[8]

MikroTik's own security advisory recommends upgrading and warns users to ensure SSH is not exposed to untrusted networks.[9] The vendor says its fixed releases include mechanisms that can flag certain suspicious configuration changes following compromise.[9]

Importantly, the absence of a RouterOS “Flagged” status should not be treated as proof that a device has never been compromised. CERT Polska explicitly warns that the mechanism detects selected traces and that the absence of the marker does not prove that a device is safe.[8]

What Organizations Should Do Now

1. Check for affected products

Security teams should first determine whether their environments contain self-hosted JFrog Artifactory, ScreenConnect deployments or MikroTik RouterOS devices within the affected ranges. Asset inventories should be checked against the exact product and version ranges rather than relying solely on generic “critical vulnerability” labels.

2. Patch JFrog Artifactory

JFrog customers should compare their Artifactory versions against the affected ranges in the vendor's security advisory and move to the corresponding fixed releases.[2] Organizations that find evidence of exploitation should also treat the event as a potential security incident rather than as a simple patching exercise.

3. Update ScreenConnect clients

ScreenConnect installations running versions before 26.6.5 should be updated according to ConnectWise's remediation guidance.[3] On-premise customers should upgrade to 26.6.5, while cloud instances are automatically updated by the provider.[3]

4. Patch MikroTik RouterOS immediately

Organizations operating potentially affected RouterOS devices should upgrade to the fixed releases: 6.49.21, 7.23.4 or 7.24.2, depending on the release branch.[4][9]

Where immediate patching is impossible, CERT Polska recommends restricting exposed services to trusted networks, particularly SSH, WebFig-related services and bandwidth-test functionality.[8] These measures are temporary risk reduction and do not replace installing the vendor fixes.[8]

5. Investigate internet-facing systems

The RouterOS case demonstrates why externally reachable management services deserve special attention. CERT Polska confirmed exploitation against devices whose SSH services were accessible from public networks.[8]

For Artifactory and ScreenConnect, incident-response teams should similarly review available audit and access telemetry for suspicious activity around the vulnerable components. A suspicious request or login event establishes an investigation lead, not automatically a confirmed compromise.

6. Treat KEV-listed vulnerabilities differently from ordinary patch backlog

A vulnerability appearing in CISA's Known Exploited Vulnerabilities catalog is an important prioritization signal because the catalog is designed around vulnerabilities with evidence of exploitation. Organizations should therefore avoid treating these five CVEs as ordinary items in a long-term vulnerability queue.[1]

Federal Remediation Deadlines

The Hacker News reports that federal civilian agencies have different remediation deadlines for the five vulnerabilities.[1] The reported deadlines are September 13, 2026 for the two RouterOS vulnerabilities, September 14 for the ScreenConnect vulnerability, and September 25 for the two Artifactory vulnerabilities.[1]

These deadlines are specifically associated with U.S. Federal Civilian Executive Branch agencies. Other organizations should not interpret the dates as universal legal or regulatory deadlines, but they can use the KEV inclusion and observed exploitation as strong indicators for prioritization.[1]

The Security Significance

The five vulnerabilities illustrate why vulnerability management cannot rely on CVSS scores alone. The Artifactory flaws carry high severity ratings but become particularly urgent because exploitation has been observed against self-hosted installations.[1][5]

The ScreenConnect vulnerability carries a 9.9 CVSS v3.1 score and affects a client component capable of file transfer and execution under certain circumstances.[3] ConnectWise has nevertheless made clear that the ScreenConnect server itself is not affected.[3]

The RouterOS vulnerabilities demonstrate another important distinction. CVE-2026-67277 has a lower published score than CVE-2026-86060, yet both are operationally important because CERT Polska has reported real-world exploitation of RouterOS vulnerabilities and confirmed attacks against internet-accessible devices.[4][8]

In other words, defenders should combine severity, exposure, exploitability, affected asset role and evidence of exploitation when deciding what gets patched first.

Security Takeaway

The addition of CVE-2026-42016, CVE-2026-42018, CVE-2026-84869, CVE-2026-67277 and CVE-2026-86060 to CISA's KEV catalog places five different vulnerabilities on an elevated operational radar.[1]

For Artifactory operators, the immediate priority is to verify versions and investigate systems that may have been exposed to the reported exploitation activity.[2][5] ScreenConnect administrators should ensure clients are running 26.6.5 or later where applicable.[3] MikroTik operators should update affected RouterOS branches and examine internet-facing SSH exposure and device configuration for signs of compromise.[4][8][9]

The central lesson is straightforward: known exploitation changes the patching equation. These vulnerabilities should not be left sitting in a normal vulnerability backlog when affected systems are exposed to untrusted networks.

Sources & References

1. [1] The Hacker News — CISA Adds 5 Actively Exploited Artifactory, ScreenConnect, and RouterOS Flaws to KEV — September 12, 2026 — The Hacker News report
2. [2] JFrog — JFrog Security Advisories — Official JFrog security advisories
3. [3] ConnectWise — 2026-09-08 ScreenConnect Bulletin — September 8, 2026 — Official ConnectWise security bulletin
4. [4] CERT Polska — Vulnerabilities in Mikrotik RouterOS software — September 5, 2026 — CERT Polska vulnerability disclosure
5. [5] The Hacker News — Attackers Chain JFrog Artifactory Flaws to Gain Admin Control and Plant Backdoors — September 11, 2026 — The Hacker News Artifactory exploitation report
6. [6] ConnectWise — Trust Center Advisories — ConnectWise Trust Center
7. [7] The Hacker News — Rogue ScreenConnect Clients Spread Four-Stage VBScript Chain to Newly Connected Hosts — September 7, 2026 — The Hacker News ScreenConnect report
8. [8] CERT Polska — Critical vulnerabilities in MikroTik RouterOS are being actively exploited. Immediate update recommended — September 5, 2026 — CERT Polska exploitation advisory
9. [9] MikroTik — September 2026 vulnerability — September 3, 2026 — Official MikroTik security advisory
10. [10] CVE record for CVE-2026-86060 — CERT-PL CNA data — CVE record mirror containing CNA data

Editorial note: This article distinguishes CVE severity, vulnerability existence, observed exploitation and KEV status. The five vulnerabilities are not presented as one unified exploit chain. Claims about exploitation are attributed to the specific sources that reported or observed the activity.