What did CISA add to the KEV Catalog in September 2026?
CISA added actively exploited vulnerabilities affecting JFrog Artifactory, ConnectWise ScreenConnect, and GitLab to its Known Exploited Vulnerabilities Catalog on September 11, 2026. For Modesto and Central Valley organizations, the lesson is direct: remote access tools, software repositories, and developer platforms need faster remediation workflows than ordinary patch queues.
CISA’s September 11 alert identified three newly added Known Exploited Vulnerabilities: CVE-2026-42016 for JFrog Artifactory incorrect authorization, CVE-2026-42018 for JFrog Artifactory improper authentication, and CVE-2026-84869 for ConnectWise ScreenConnect improper privilege management and missing authorization.1 On the same date, CISA also added CVE-2026-85706, a GitLab Community Edition and Enterprise Edition path traversal vulnerability, based on evidence of active exploitation.2
That combination matters because these are not isolated desktop patch issues. ScreenConnect is a remote support tool. Artifactory is a repository manager that often sits inside build, deployment, and software distribution workflows. GitLab may hold source code, pipelines, secrets references, deployment automation, and issue history. If any of these systems are internet-facing, tied to privileged workflows, or used by a managed IT provider, a delayed response can create exposure beyond the originally vulnerable server.
For organizations with lean IT teams, the most important shift is this: treat CISA KEV additions as operational risk events, not just vulnerability scanner findings.
Why should Modesto and Central Valley organizations care?
Central Valley organizations often run with small IT teams, distributed locations, and a heavy dependence on outside technology partners. A KEV-listed vulnerability in remote support, code hosting, or software repository infrastructure can affect help desk access, vendor access, endpoint control, backups, business applications, and incident response visibility at the same time.
This is especially relevant for healthcare clinics, K-12 districts, local government offices, manufacturers, construction firms, and financial services teams around Modesto, Fresno, Stockton, Merced, Turlock, and Manteca. These organizations may not think of themselves as “software companies,” but they still rely on remote monitoring and management tools, ticketing systems, endpoint support agents, Microsoft 365 integrations, line-of-business applications, and vendor-maintained portals.
The risk is not theoretical. CISA says KEV Catalog entries are based on evidence of active exploitation.1 NIST’s National Vulnerability Database entry for CVE-2026-84869 describes a ScreenConnect client condition that may allow files to be transferred and executed through an active remote session without authorization or host confirmation in certain circumstances, and notes that ScreenConnect servers are not impacted.3 That distinction is operationally important: a server patch may be necessary, but organizations also need to understand where clients are installed, which sessions were active, and whether unauthorized file transfer or execution occurred.
For a regulated organization, the response also has documentation implications. If the affected system touches ePHI, student information, financial data, CJIS data, or privileged administrative access, leadership should expect an evidence trail: what was exposed, what was patched, what logs were reviewed, what accounts were rotated, and what monitoring was added after remediation.
What is the practical risk from ScreenConnect CVE-2026-84869?
The practical risk is unauthorized file transfer and execution through an active remote session under certain circumstances. Because ScreenConnect is commonly used for remote support, the affected asset class is high leverage: a compromised remote support workflow can become a path into endpoints, servers, administrative sessions, and downstream business systems.
NIST’s CVE detail says the condition exists in the ScreenConnect client and may allow files to be transferred and executed through an active remote session without authorization or host confirmation in certain circumstances.3 NIST also lists the vulnerability as part of CISA’s Known Exploited Vulnerabilities Catalog, with a required action to apply mitigations in accordance with vendor instructions and follow CISA’s BOD 26-04 guidance where applicable.3
For a local business, the response should not stop at “confirm the vendor patched.” The right questions are more specific:
- Where are ScreenConnect clients installed?
- Which hosts had active remote sessions during the exposure window?
- Are any ScreenConnect clients unmanaged, duplicate, stale, or tied to former vendors?
- Were files transferred during sessions that do not match ticket history?
- Were scripts or executables run outside normal support procedures?
- Are remote support permissions scoped by role, endpoint group, and approval path?
- Are session logs retained long enough for forensic review?
The worst response is to treat remote access tooling as a black box controlled entirely by a vendor. Even when a tool is vendor-hosted or MSP-managed, the client organization still needs asset inventory, contract clarity, logging expectations, and escalation procedures.
What is the practical risk from JFrog Artifactory CVE-2026-42016 and CVE-2026-42018?
The practical risk is that a repository manager compromise can become a software supply chain problem. Artifactory often stores internal packages, build artifacts, container images, libraries, deployment dependencies, and release metadata. If attackers manipulate that layer, the impact can move from one application server to many systems downstream.
CISA’s September 11 alert added two Artifactory vulnerabilities to the KEV Catalog: CVE-2026-42016 for incorrect authorization and CVE-2026-42018 for improper authentication.1 Even if an organization does not develop commercial software, Artifactory may still support internal applications, automation, IT scripts, endpoint packages, infrastructure-as-code modules, or vendor-maintained deployments.
The response should include more than patching. IT teams should review:
- Local and federated Artifactory users.
- Recently created access tokens, API keys, SSH keys, and service accounts.
- Administrative groups and permission targets.
- Repository changes during the suspected exposure window.
- Build metadata, promoted artifacts, and package checksums.
- CI/CD jobs that pull from the affected repository.
- Secrets exposed through build logs, environment variables, or deployment scripts.
For regulated industries, repository integrity is part of operational resilience. A poisoned package or modified deployment artifact can bypass traditional perimeter defenses because it appears to come from a trusted internal workflow.
What is the practical risk from GitLab CVE-2026-85706?
The practical risk is that GitLab often sits at the center of code, automation, and operational knowledge. A path traversal vulnerability in GitLab Community Edition or Enterprise Edition should trigger review of source repositories, pipeline permissions, credentials exposure, access logs, and integrations.
CISA added CVE-2026-85706 to the KEV Catalog on September 11, 2026, describing it as a GitLab Community Edition and Enterprise Edition path traversal vulnerability with evidence of active exploitation.2 Path traversal flaws can be especially dangerous when they expose files outside intended directories, although the exact impact depends on the affected version, configuration, and vendor guidance.
For most mid-market organizations, GitLab risk is less about public source code embarrassment and more about operational secrets. Repositories and pipelines may reference deployment keys, cloud accounts, service principals, container registries, internal hostnames, environment variables, API endpoints, and application architecture. Even if secrets are not directly stored in Git, commit history, CI variables, and pipeline logs can provide enough information to accelerate an attacker’s next move.
A practical GitLab response should include:
- Confirm affected versions and patch status.
- Review authentication logs and administrative events.
- Rotate exposed or potentially exposed deploy tokens.
- Audit project and group membership.
- Review CI/CD variables and runner access.
- Check pipeline logs for credential leakage.
- Validate backups before making major changes.
- Confirm whether GitLab is internet-facing or restricted behind VPN, ZTNA, or conditional access.
How should IT leaders prioritize these vulnerabilities?
Prioritize based on exposure, privilege, business dependency, and evidence. Internet-facing systems, remote access tools, identity-connected platforms, developer infrastructure, and systems with administrative reach should move ahead of ordinary workstation patching when they appear in CISA’s KEV Catalog.
CISA’s BOD 26-04, issued June 10, 2026, formalizes this risk-based approach for Federal Civilian Executive Branch agencies. The directive says vulnerability remediation urgency is determined by variables including asset exposure, KEV status, exploit automation, and technical impact.4 While BOD 26-04 applies to federal agencies, CISA’s September 11 alerts explicitly encourage all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities.1
For non-federal organizations, that translates into a simple operating model:
- Find the asset. Confirm whether ScreenConnect clients, Artifactory instances, or GitLab servers exist in your environment.
- Classify exposure. Determine whether the asset is internet-facing, vendor-accessible, VPN-accessible, or internal only.
- Confirm business role. Identify whether the system supports remote access, software deployment, regulated data, backups, finance systems, or clinical operations.
- Patch or mitigate. Apply vendor instructions and document exactly what changed.
- Triage for compromise. Review logs, sessions, accounts, tokens, files, and administrative actions.
- Rotate credentials where warranted. Prioritize tokens, service accounts, API keys, and privileged accounts tied to the affected platform.
- Increase monitoring. Add detection for abnormal remote sessions, package changes, pipeline changes, and suspicious authentication.
- Record evidence. Save screenshots, export logs, ticket notes, approvals, timestamps, and before-and-after configuration details.
This is where many organizations fail. They patch but do not investigate. They investigate but do not preserve evidence. They preserve evidence but do not brief leadership. The result is a technical response that cannot survive an insurance questionnaire, board review, compliance audit, or post-incident legal review.
What should an MSP or co-managed IT partner provide?
An MSP or co-managed IT partner should provide asset discovery, exposure validation, patch confirmation, forensic triage, credential rotation guidance, and executive-ready documentation. For KEV-listed vulnerabilities, “we patched it” is not enough.
A serious response package should include:
- A list of affected and unaffected assets.
- Current version numbers and remediation timestamps.
- Exposure classification for each system.
- Vendor advisory references.
- Screenshots or exports proving mitigation.
- Log review summary.
- Accounts, tokens, or integrations reviewed.
- Any suspicious findings and escalation decisions.
- Residual risk statement.
- Next monitoring steps.
- Business owner sign-off.
That evidence matters for cyber insurance, regulated-industry oversight, board reporting, and vendor management. It also creates a repeatable motion for the next KEV event, because there will be a next KEV event.
Datapath’s managed cybersecurity services and managed IT services in Modesto are built around this kind of operational accountability: inventory, monitoring, remediation, documentation, and leadership visibility. For organizations with internal IT staff, the model can also be co-managed so the internal team keeps control while Datapath provides surge capacity, escalation support, and security depth.
What should organizations do this week?
This week, organizations should run a focused KEV response sprint. The sprint should identify whether the affected products exist, validate exposure, apply vendor mitigations, review relevant logs, rotate credentials where needed, and document the result in a short executive summary.
Start with remote access tooling. Remote support platforms deserve priority because they can reach endpoints and servers across the business. Inventory every ScreenConnect client and confirm whether it belongs to your organization, your MSP, a past vendor, or an unknown source. Remove stale agents. Confirm that remote support privileges are scoped to current business need. Tie every privileged remote session to a ticket, approval, or emergency access record.
Next, review developer and repository platforms. Even if your company is not a software company, you may have line-of-business integrations, automation scripts, PowerShell repositories, deployment packages, or vendor-maintained code. Artifactory and GitLab should be treated as privileged systems if they can influence production systems or endpoint configurations.
Finally, brief leadership in plain English. Do not bury the update in technical jargon. A useful executive summary answers four questions:
- Are we affected?
- What did we do?
- Did we see evidence of misuse?
- What remains to be fixed?
If the answer to any of those questions is unknown, say so and assign an owner.
How does this fit into a broader vulnerability management program?
This KEV event reinforces the need for a vulnerability management program that combines asset inventory, exposure management, patching, forensic triage, and evidence collection. Scanner output alone is not a program. A program turns threat intelligence into accountable operational action.
Organizations should maintain:
- A current asset inventory for servers, endpoints, SaaS platforms, remote access tools, and developer systems.
- Ownership records for every privileged platform.
- Internet exposure monitoring.
- Emergency patch procedures.
- Vendor access review.
- Remote support approval rules.
- Centralized logging.
- Token and service account rotation procedures.
- Incident response escalation paths.
- Board- or executive-level reporting templates.
If you are building from scratch, start with a practical foundation: known assets, known owners, known remote access tools, and known patch SLAs. Datapath’s guide on building a vulnerability management program is a useful companion for turning this kind of event into a durable process instead of another one-time scramble.
CTA: Need help validating your KEV exposure?
If your team needs help determining whether ScreenConnect, Artifactory, GitLab, or other KEV-listed systems create exposure in your environment, Datapath can help with asset review, remediation planning, co-managed escalation, and executive-ready documentation.
Talk with Datapath about vulnerability response and managed cybersecurity
FAQ
What is CISA’s KEV Catalog?
CISA’s Known Exploited Vulnerabilities Catalog is an authoritative list of vulnerabilities that have been exploited in the wild. CISA says organizations should use the catalog as an input to their vulnerability management prioritization framework.5
Does CISA’s September 2026 KEV guidance apply only to federal agencies?
The binding requirements in BOD 26-04 apply to Federal Civilian Executive Branch agencies, but CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities.1 Private companies, schools, clinics, and local governments can use the same logic without being legally bound by the directive.
Is patching enough for KEV-listed vulnerabilities?
No. Patching is necessary, but KEV status means the vulnerability has evidence of active exploitation. Organizations should also review logs, sessions, accounts, tokens, files, and administrative changes to determine whether exploitation occurred before remediation.
Why are remote support tools especially sensitive?
Remote support tools often have legitimate access to endpoints, servers, user sessions, file transfer, script execution, and administrative workflows. If abused, they can give attackers a trusted path into systems that would otherwise be harder to reach.
What should a small IT team do first?
Start with asset discovery and exposure. Confirm whether the affected tools exist, whether they are internet-facing or vendor-accessible, who owns them, whether vendor mitigations were applied, and whether logs show unusual activity. Then document the result for leadership.
Footnotes
-
CISA, “CISA Adds Three Known Exploited Vulnerabilities to Catalog,” published September 11, 2026. Source ↩ ↩2 ↩3 ↩4 ↩5
-
CISA, “CISA Adds One Known Exploited Vulnerability to Catalog,” published September 11, 2026. Source ↩ ↩2
-
NIST National Vulnerability Database, “CVE-2026-84869 Detail,” NVD published September 8, 2026 and last modified September 12, 2026. Source ↩ ↩2 ↩3
-
CISA, “BOD 26-04: Prioritizing Security Updates Based on Risk,” published June 10, 2026. Source ↩
