What landed in CVE-land this week

CISA added twelve entries to the Known Exploited Vulnerabilities catalogue in the seven days leading up to 12 September 2026, and none on the day itself. That is a heavy week: a Chromium V8 out-of-bounds write, another Citrix NetScaler authentication bypass, a Cisco Secure Firewall Management Center flaw that yields root, two MikroTik RouterOS issues, an N-able N-central pre-auth code injection, and more. This digest goes deep on the entry most likely to be sitting on your internet edge right now, then a second that quietly changes the trust model of a build system many teams treat as internal-only.

Lead: unauthenticated arbitrary file read in GitLab (CVE-2026-85706)

CVE-2026-85706 is a path traversal in GitLab Community Edition and Enterprise Edition that lets an unauthenticated user read arbitrary files. Two bugs drive it: improper path confinement and missing authentication enforcement in the repository commits API. Neither requires a valid session. That combination turns a routine traversal into an internet-scale problem; any GitLab instance reachable on TCP/443 is in scope regardless of whether public sign-up is disabled.

The danger lies in the interplay. A path traversal alone is often gated behind a project membership check. A missing-auth bug alone usually covers an endpoint that reads only project-scoped, sanitised data. Chain them and the endpoint becomes a generic read primitive against the filesystem of the Rails app user, which on a stock install has read access to the GitLab secrets file, the Rails secret_key_base, database configuration, and any workhorse or runner registration tokens on disk.

You do not need a working exploit to check exposure. Two things matter: is the endpoint reachable without a session cookie or PAT, and does the response body change when you vary the traversal input? A defensive probe against a lab instance looks like this:

# Lab-only. Replace example.com with your own instance URL.
BASE="https://gitlab.example.com"
PROJECT="42"                    # numeric project ID or url-encoded path
SHA="HEAD"

# Baseline: does the commits API respond at all without auth?
curl -sS -o /tmp/baseline.json -w "%{http_code}\n" \
  "$BASE/api/v4/projects/$PROJECT/repository/commits/$SHA"

# Traversal probe. The exact parameter name is not public;
# fuzz path-shaped params (path=, file=, ref=, filepath=) and
# compare response length and content-type to baseline.
for p in path file filepath ref; do
  curl -sS -o /tmp/probe.$p -w "$p %{http_code} %{size_download}\n" \
    --data-urlencode "$p=../../../../etc/passwd" \
    -G "$BASE/api/v4/projects/$PROJECT/repository/commits/$SHA"
done

Look for any variant that returns 200 with a body that differs meaningfully from the baseline, especially one whose content type flips from application/json to text/plain or whose length correlates with the requested file. If the endpoint refuses unauthenticated calls entirely (401 on the baseline), the missing-auth half of the bug is absent from your build; you are then exposed only to the traversal side, which requires a low-privilege token.

Detection is straightforward with request logs. Access-log signatures include unusually long query strings on /api/v4/projects//repository/commits/, high ratios of 200 responses to path-like parameters on that route, and clients hitting the endpoint without a preceding /users/sign_in or an Authorization: Bearer header. If a suspicious pattern predates your upgrade, rotate everything stored under the Rails root: secret_key_base, database credentials, runner registration tokens, and SMTP or OAuth secrets. Rotating the Rails secret invalidates existing session cookies and CSRF tokens by design; plan for the user impact.

If patching today is not feasible, two compensating controls apply: front the instance with an authenticating reverse proxy on the commits API path, or drop unauthenticated requests to /api/v4/projects//repository/commits/ at the load balancer. Neither substitutes for the fix.

Second: JFrog Artifactory anonymous token leak plus scope confusion (CVE-2026-42018 and CVE-2026-42016)

The two Artifactory entries added on 11 September are best read together. CVE-2026-42018 is an improper-authentication bug where the server returns an internal anonymous-user token to an unauthenticated caller even when anonymous access is explicitly disabled. CVE-2026-42016 is an incorrect-authorization bug where token validation checks the signature and issuer but not the scope, letting a low-scoped token perform higher-scoped actions.

Either alone is a real finding. Chained, they collapse the entire anonymous-access hardening story: a caller with no credentials requests a token, receives one, then wields it beyond its documented scope. Every operator who satisfied a compliance question with "anonymous access is disabled" must now re-evaluate.

The audit steps are quick. From an unauthenticated position, ask Artifactory for a token:

# Lab-only. Replace example.com with your registry URL.
BASE="https://artifactory.example.com"

# Does an unauthenticated caller receive any token material?
curl -sS -i "$BASE/access/api/v1/tokens" -X POST \
  -H 'Content-Type: application/json' \
  --data '{"scope":"applied-permissions/user"}'

A hardened build should refuse with 401 or 403 and no body containing access_token. If a token is returned, decode it (cut -d. -f2 | base64 -d) and inspect the sub, scp, and iss claims. A sub of jfac@01/users/anonymous or similar, combined with a 200 response when anonymous access is nominally disabled, is the CVE-2026-42018 signature. Then, using that token, attempt an action outside its scope (a repository listing, a build info retrieval) and check whether the server enforces scope or ignores it. Any success is the CVE-2026-42016 signature.

Detection over historical logs is harder because these calls resemble ordinary Artifactory traffic. The higher-signal indicators are anonymous-subject tokens appearing in access logs after your configuration disabled anonymous access, and successful reads of repositories that no policy should have granted to the token's stated scope.

Remediation: upgrade, then rotate. Every token the server issued during the window in which either bug was live is untrusted; revoke it and force downstream CI systems to re-authenticate. If your Artifactory instance is internet-reachable, treat that window as starting from the earliest vulnerable version you ran, not from the KEV date.

What to do this week

Patch the two above if they apply. Then work through the remaining KEV entries against your inventory in this order: internet-exposed edge (Citrix NetScaler CVE-2026-19490, Cisco FMC and SCC CVE-2026-20079, Fortinet CVE-2025-25249), remote-access tooling (ConnectWise ScreenConnect CVE-2026-84869), managed endpoints (N-able N-central CVE-2026-86218, Microsoft Windows ALPC CVE-2026-85880), browsers (Chromium V8 CVE-2026-87491), and network kit (MikroTik RouterOS CVE-2026-86060 and CVE-2026-67277). KEV inclusion means exploitation is already happening; the only question is whether it has reached you yet.

Verifiable security.