4 new KEV entries: GitLab CE/EE and what else CISA flagged

On 2026-09-11, CISA added four vulnerabilities to the Known Exploited Vulnerabilities (KEV) catalog: an unauthenticated path traversal in GitLab Community Edition and Enterprise Edition (CVE-2026-85706), an authorization bypass in ConnectWise ScreenConnect (CVE-2026-84869), and a two-CVE chain in JFrog Artifactory (CVE-2026-42018 and CVE-2026-42016). KEV inclusion is not a routine advisory; it is CISA's evidence-backed determination that each flaw is being actively exploited right now, and it triggers a Binding Operational Directive 22-01 remediation clock for federal civilian agencies. Every other operator should treat that clock as their own.

This post covers the GitLab entry in depth, then addresses the JFrog Artifactory pair; both sit in the software supply chain and both can turn a foothold into source code, build artifacts, and signing material. The ConnectWise ScreenConnect entry matters too, but code and package infrastructure exposure is where defenders get the highest return this week.

CVE-2026-85706: unauthenticated file read in GitLab

CISA's KEV entry describes CVE-2026-85706 as a path traversal in GitLab Community Edition and Enterprise Edition that lets an unauthenticated user read arbitrary files. Two failures compound: the repository commits API accepts requests without authenticating the caller, and the path-resolution code does not confine results to the repository tree.

Path traversal in a repository API is more dangerous than a generic file read. GitLab processes hold credentials and secrets that can turn a read primitive into full downstream compromise:

Any one of those pivots a read into write. secret_key_base is the sharpest: recovering it lets an attacker mint arbitrary user sessions, converting anonymous read into authenticated push on projects the victim controls, including protected branches wired to CI runners.

How to tell whether you are affected

Because the flaw is unauthenticated and API-level, asking "did we patch?" is the wrong exposure test. The right question: was the commits API reachable from an untrusted network, and did any request resolve a path outside the repository root? A read primitive leaves faint but real traces.

Start at the reverse proxy or edge. GitLab commits API traffic lands on paths like /api/v4/projects/{id}/repository/commits/{sha} and adjacent endpoints. Traversal payloads typically inject ..%2F or literal ../ sequences into a path or ref parameter, sometimes URL-encoded twice to survive an intermediate decode. This ripgrep pass over an NGINX or Workhorse access log is a reasonable first sweep:

# Hunt likely traversal shapes against the commits API window.
# Adjust the path prefix to your deployment; scope to the days
# before your patch was applied.
rg -N --no-heading \
  -e 'GET .*/api/v4/projects/[^ ]+/repository/commits/[^ ]*(\.\./|%2e%2e%2f|%2E%2E%2F|%252e%252e%252f)' \
  /var/log/gitlab/nginx/gitlab_access.log* \
  | awk '{print $1, $4, $7, $9}' \
  | sort -u

# For any hit, pull the surrounding requests from the same client IP
# and user agent to characterise reconnaissance vs. exploitation.
awk -v ip="203.0.113.42" '$1==ip' /var/log/gitlab/nginx/gitlab_access.log \
  | head -n 200

Two patterns warrant escalation. First, requests returning HTTP 200 with a body length inconsistent with normal commit JSON, suggesting raw file content leaked. Second, sequences where the same client walked common file targets (config/secrets.yml, config/database.yml, .git/config, /etc/passwd) immediately after fetching a project listing.

Plausible hits require more than patching. Assume any secret readable at that path was exfiltrated and rotate: the Rails secret_key_base, OmniAuth secrets, runner registration tokens, personal access tokens, deploy tokens, and any credentials stored as CI/CD variables at group or project scope. Invalidate active sessions. Rebuild runners whose tokens rotated; a leaked runner token accepts jobs and executes attacker-supplied scripts.

Meeting the deadline

BOD 22-01 requires federal civilian agencies to remediate KEV entries by CISA's stated deadline, typically two to three weeks for live-exploited authentication and path issues, sometimes shorter. For self-managed GitLab, remediation means upgrading to a fixed release per the vendor advisory and placing the API layer behind an authenticated proxy or IP-restricted ingress. For SaaS-hosted GitLab, the platform patch is upstream; your work is credential rotation for anything protected by a tenant token or CI variable, and log review across the exposure window.

The JFrog Artifactory pair: CVE-2026-42018 and CVE-2026-42016

The two Artifactory entries are best read together. CVE-2026-42018 is an authentication flaw: when anonymous access is disabled, the server can still return an internal anonymous-user token to an unauthenticated caller. CVE-2026-42016 is an authorization flaw: token validation checks the signature and issuer but not the token's scope, so a token minted for one purpose is accepted for another.

Chained, they convert "no anonymous access" into "authenticated as an internal principal with over-broad reach." The blast radius in a package registry is severe. Read access exposes the full inventory of internal packages, versioned build artifacts, container images, and any secrets baked into layers. Write access, when scope collapse extends that far, lets an attacker publish or overwrite package versions that downstream builds consume: the classical dependency-substitution attack.

Detection

Look for unauthenticated requests to token endpoints that returned a token, followed by API calls presenting that token against unrelated resources. In the request access log, the pattern is a POST to a token issuance path with no Authorization header, a 200 response, and immediately subsequent GET or PUT calls from the same client bearing a bearer token that references an anonymous or system principal.

# Requires the access log to include the client IP and the
# Authorization presence flag; adjust field indexes to your format.
rg -N '"POST /(access|api)/api/v[0-9]+/tokens[^"]*" 200' \
   /var/opt/jfrog/artifactory/logs/request.log \
  | awk '{print $1, $4}' \
  | sort -u

Any positive result is grounds for treating every artifact published since the earliest hit as suspect. Compare checksums for internal packages against a known-good build cache, force a re-pull of container images from an isolated mirror, and rotate any repository-scoped access tokens.

Remediation and hardening

Patch to the fixed Artifactory version per the vendor advisory. Two structural changes reduce recurrence risk: require a session-bound identity at the ingress before token endpoints are reachable, and enable per-repository token scope checks in policy so a token cannot silently reach outside its intended repository.

What to do this week

For any operator running GitLab self-managed, Artifactory self-managed, or ScreenConnect, a KEV addition is not another advisory. It signals that exploitation is active and the window between disclosure and mass targeting has closed. Patch on the CISA clock, hunt for the patterns above in your logs across the exposure window, and rotate any credentials a read primitive could have surfaced. Confirm the fix with a targeted request that would have succeeded pre-patch and now fails. Keep that evidence.

Verifiable security.