What landed in CVE-land this week

The week ending 2026-09-14 saw twelve additions to CISA's Known Exploited Vulnerabilities catalog, the list you should be patching before the CVSS-of-the-week beauty contest. Entries landed between 2026-09-08 and 2026-09-11, spanning source hosting, remote access, artifact repositories, edge routers, browsers, firewall management, VPN gateways, RMM, and Windows itself. Rather than tour all twelve, this post drills into two: the GitLab arbitrary file read that CISA added on 2026-09-11, and the Cisco Secure Firewall Management Center authentication bypass added on 2026-09-09. Both are unauthenticated, both are actively exploited against real targets, and both sit at the top of enterprise trust hierarchies. Getting the mechanism right lets you answer the only question that matters after a KEV listing: am I exposed, and can I prove it?

CVE-2026-85706: unauthenticated arbitrary file read in GitLab

The GitLab advisory covers CE and EE and lists three affected version bands: 18.7 up to 19.1.8, 19.2 up to 19.2.6, and 19.3 up to 19.3.2. CISA's KEV entry, published 2026-09-11, describes the flaw as a path traversal in the repository commits API with improper path confinement and no authentication enforcement. That combination is worse than a simple traversal. A traversal alone lets an authenticated user reach outside their project scope. Absent authentication removes that prerequisite entirely, which is why the CVSS scored 10.0 and why the entry landed on KEV the same day.

The blast radius is bounded by the process's filesystem view. In a standard omnibus deployment, that means the GitLab application user can read repository storage, secrets under /etc/gitlab/, the Rails secret key base, Kubernetes agent tokens or runner registration tokens on disk, CI job artifacts on shared storage, and whatever else sits in the working set. An attacker retrieves the crown jewels of your software delivery chain in a single request.

Detection is where most teams either catch the intrusion or discover, six weeks later, that they did not. If your GitLab is fronted by a reverse proxy or WAF, filter the last thirty days of access logs for anonymous hits (no session cookie, no PRIVATE-TOKEN, no Authorization) against the commits endpoint on repository storage paths, and correlate against the affected versions. A starting query:

# ripgrep across nginx/gitlab access logs for anonymous hits to the commits API
rg -N --no-heading \
   -e '"(GET|POST) /api/v4/projects/[^ ]*/repository/commits[^ ]*" 200' \
   -g '*access*.log*' /var/log/gitlab/ \
| awk '$0 !~ /PRIVATE-TOKEN|Authorization|Bearer|_gitlab_session/' \
| awk '$0 ~ /%2e%2e|\.\.\/|%252e%252e|%2f\.\.%2f/'

Treat that as a starting shape, not a signature. Path-traversal attempts against a commits handler typically carry URL-encoded traversal sequences (%2e%2e%2f, ..%2f, %252e%252e) or unusual path segments where a commit SHA is expected. Once you have candidates, join them to your repository storage layout and check for unexpected reads of gitlab-secrets.json, config/secrets.yml, .git/config, or runner token files. If any of those show anonymous traffic on a vulnerable version, treat it as a compromise, not a probe: rotate the Rails secret_key_base, invalidate all sessions and personal access tokens, roll runner registration tokens, and rotate any Kubernetes agent, deploy, or CI variables that could have been read.

Patching to 19.1.8, 19.2.6, or 19.3.2 closes the endpoint. It does not un-leak anything already exfiltrated, and static secrets on disk are the whole point of the exposure, so rotation is not optional. A quick network-side check: from an unauthenticated client, a request to https://gitlab.example.com/api/v4/projects/1/repository/commits should return a 401 on a patched instance and must not return a 200 with disk content on any instance.

CVE-2026-20079: authentication bypass in Cisco Secure Firewall Management Center

The Cisco advisory, published 2026-09-14 and matching the CISA KEV listing from 2026-09-09, covers a critical authentication bypass in the FMC web interface. Cisco's own language is worth quoting closely: the flaw exists because of "an improper system process that is created at boot time," an attacker exploits it by sending "crafted HTTP requests," and a successful exploit lets the attacker "execute a variety of scripts and commands" with root on the underlying operating system. In CWE terms, this is an alternate-path authentication bypass leading to root-level script execution. There is no privilege prerequisite and no user interaction requirement.

The threat model is not "firewall gets popped." It is "firewall management plane gets popped." FMC is where policy is authored, where access control rules live, where interface objects and NAT rules resolve, and where deployment jobs push configuration to managed sensors. Root on an FMC lets an attacker rewrite policy across the fleet, disable logging, add or remove ACLs at will, exfiltrate the configuration of every managed device, or push a malicious deployment that opens a path they can then walk through. The compromise falls in the same category as owning the domain controller for a firewall estate.

Exposure comes down to two questions. First, is your FMC web interface reachable from anywhere it should not be? For most organizations, the intended answer is that the management UI is reachable only from a jump network, yet many appliances end up bound to interfaces on management VLANs with routing that operators never cleaned up. Run an unauthenticated probe from outside your management segment and confirm you get nothing. Second, are you on a fixed release? Cisco's PSIRT bulletin is authoritative on that; do not infer version state from banners.

For detection, treat any HTTP request to the FMC UI from a source that is not a known jump host as an incident-grade event. Log CGI script execution on the FMC itself where you can (auditd on the underlying OS is the mechanism) and alert on any process launched by the web server user that is not on the short list of expected helpers.

Two patterns worth naming

The GitLab bug and the Cisco bug belong to different vulnerability classes, but share a shape: both put a critical control plane behind an interface that treats authentication as an ambient condition rather than a precondition checked on every request. That is a recurring failure mode in software that has grown by accretion, and it is exactly the failure mode a defender should assume exists in the next critical KEV entry, whichever product it lands on.

Pick one product in your estate this week and ask, at each authentication-bearing endpoint, whether authentication is enforced by the endpoint itself or inherited from a middleware that a "system process created at boot time" might silently replace. That question is cheap. The answer is not.

Verifiable security.