// hackerlogs
login+ register
LLM AppSecSupply ChainAI for DefenseThreat BriefCriticalCVE-2026-85706CVE-2026-87719

CISA's GitLab KEV Clock Ran Out. Self-Managed Still Reads Open.

CISA listed CVE-2026-85706 as KEV on 11 September. Federal due date was 14 September. Self-managed GitLab CE/EE before 19.1.8, 19.2.6, or 19.3.2 still reads open.

The short answer

CISA added CVE-2026-85706 to KEV on 11 September. GitLab's CVSS 10.0 path traversal in the repository commits API lets an unauthenticated caller read files on self-managed CE and EE. Federal due date was 14 September, with forensic triage required. Patch to 19.1.8, 19.2.6, or 19.3.2. GitLab.com and Dedicated are already covered.

Key takeaways

  • GitLab patched on 10 September: 19.1.8, 19.2.6, and 19.3.2. CISA listed the bug as KEV on 11 September. Federal due date was 14 September. Forensic triage is Yes.
  • The hole is unauthenticated file read on the repository commits API. Scope is self-managed CE and EE from 18.7 up to those patched builds. GitLab.com was already on the fix.
  • watchTowr saw honeypot probes the day after the patch. BleepingComputer carried CISA's in-the-wild warning on 14 September.
  • The same release also ships CVE-2026-87719, a 9.9 authenticated GraphQL issue on EE with Duo Chat. It is not KEV. It is still a reason to take the upgrade.
  • This is not the July Hugging Face Artifactory path and not the May RubyGems flood. It is a human-exploited Git host.

CISA's federal clock on CVE-2026-85706 ran out on 14 September. BleepingComputer carried the in-the-wild warning that morning. This is the Google-searchable ticket: a CVSS 10.0 unauthenticated file read on self-managed GitLab, added to KEV on 11 September, with forensic triage required.

GitLab.com was already patched. Dedicated needs no action. Self-managed is the remaining surface.

Critical Unauthenticated file read on the repository commits API, listed as KEV, due 14 September. Critical because secrets on disk become a foothold, not because this is an AI agent.

Three panels for GitLab CVE-2026-85706: unauthenticated file read on the commits API, CISA KEV with a 14 September due date and forensic triage, and the patched builds 19.1.8, 19.2.6, and 19.3.2 for self-managed CE and EE.

What GitLab actually patched.#

On 10 September GitLab shipped 19.3.2, 19.2.6, and 19.1.8. The critical row is CVE-2026-85706: improper path confinement and missing authentication enforcement in the repository commits API. Under certain conditions an unauthenticated caller could read arbitrary files from the GitLab server. Impacted versions are CE and EE from 18.7 before those three builds. CVSS 10.0. Reported through HackerOne by s3ntago.

We are not reprinting the request that proves it. The operator fact is enough: if the commits API is on the public internet, an unauthenticated read of server files is in scope until you are on a patched build.

watchTowr reproduced the hole and said its honeypots were already seeing behavioral probes on 11 September, about a day after the patch. That is the usual N-day clock. CISA listed it the same day and gave federal civilian agencies three days.

The same patch train includes CVE-2026-87719, CVSS 9.9, EE only: an authenticated user with Duo Chat access could pull Advanced Search configuration and credentials through a crafted GraphQL subscription. It is not on KEV. It is still sitting in the upgrade you should already be taking.

Why the due date matters on the 15th.#

BOD 26-04 is the federal rule. KEV plus internet exposure plus a path to control of the asset gets a short clock and, on this row, forensic triage. CISA's ransomware field is Unknown. That is not a reason to wait.

Private-sector teams are not under the directive. They are under the same honeypots. If you are reading this after 14 September on an unpatched self-managed box, treat it as late, not as a planning item.

This is not the July OpenAI Artifactory path and not the May RubyGems flood. Those were eval agents. This is a human-exploited Git host that happens to sit next to the same CI secrets an agent would love.

  1. GitLab ships 19.3.2, 19.2.6, and 19.1.8. CVE-2026-85706 is the critical commits-API file read.
  2. watchTowr reports honeypot probes. CISA adds CVE-2026-85706 to KEV. Due date 14 September. Forensic triage Yes.
  3. Federal clock runs out. BleepingComputer: CISA says hackers are exploiting the max-severity GitLab flaw.
  4. Self-managed instances that waited through the weekend are the remaining open readers.

What this is not.#

It is not a stated remote code execution. GitLab's text is arbitrary file read. The 10.0 vector is C:H I:H A:N with changed scope: high confidentiality and integrity, availability none. That is about what those files enable, not about a documented shell. Do not wait for a second write-up that says RCE before you rotate what the box could have leaked.

It is not GitLab Dedicated. It is not GitLab.com. It is not every Git host. Gitea's separate July RCE, CVE-2026-60004, is a different product and a different campaign.

What to do.#

If you run self-managed GitLab, or you own the CI secrets that live on it:

  1. Upgrade to 19.1.8, 19.2.6, or 19.3.2 now. Confirm the about page, then relaunch whatever sits in front of it.
  2. Pull internet-exposed GitLab off the public net until that version is live. The commits API does not need to be a search result.
  3. Hunt unauthenticated requests to the repository commits API from before the upgrade. Rotate tokens, deploy keys, SSH keys, and database credentials that lived on that host.
  4. Review new users, project access tokens, and runner registrations you did not mint. File-read plus a writable registry is how a secret becomes persistence.
  5. Take the rest of the 10 September train while you are there. CVE-2026-87719 is the EE Duo Chat row. It is not KEV. It is in the same package.

The X debate this week is a CEO forecast about swarms. The Google-searchable ticket is a Git host that still answers file reads without a login. Patch the host. Then read the logs as if someone already did.

Frequently asked

If we use GitLab.com, are we done?

For this CVE, yes. GitLab says GitLab.com was already running the patched version when 19.3.2 shipped, and Dedicated customers do not need to take action. Self-managed CE and EE from 18.7 below 19.1.8, 19.2.6, or 19.3.2 are the estate that still reads open.

Does this give the attacker a shell?

GitLab's advisory is arbitrary file read, not a stated RCE. Secrets, tokens, SSH keys, and database credentials on disk are the reason CISA put a three-day clock on it. A readable secret is how a file-read becomes a foothold. Do not wait for a second CVE to treat the box as burned.

CISA's due date was 14 September. Why write this on the 15th?

Because the clock running out is the news. Federal civilian agencies that missed BOD 26-04 are already late. Private-sector self-managed instances that waited for the weekend are the ones watchTowr's honeypots were watching. Patch, then triage.

What should we hunt after the upgrade?

Unexpected unauthenticated traffic to the repository commits API. New tokens, deploy keys, or users you did not mint. Configuration files that should never have been reachable from the internet. CISA's KEV row requires forensic triage, not just a version bump.

Sources

Related