GitLab's critical patch: unauth file read from the commits API

Every CI system is a trust hierarchy pretending to be a build tool. Somewhere at the bottom of that hierarchy, someone put an authentication check that assumed the caller had already been checked. This week that assumption cost GitLab a Critical.

GitLab shipped patch releases 19.3.2, 19.2.6, and 19.1.8 on September 10, per the release note. Eighteen CVEs across Community Edition and Enterprise Edition, two of them Critical, six High, nine Medium, one Low. The self-managed guidance is the usual: upgrade immediately. GitLab.com is already running the patched version. GitLab Dedicated customers do not need to take action.

You do.

The one to open first

CVE-2026-85706 is the top of the read. Per the advisory: "an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API." Unauthenticated. Arbitrary files. From the commits API. Three phrases you never want in the same sentence.

For self-managed the affected range is CE and EE 18.7 through 19.3, and the fix landed only in 19.1.8, 19.2.6 and 19.3.2. If your platform team has been letting patch windows slip because "we're on the latest minor", check whether "latest minor" means 19.3.0 or 19.3.2. There is a difference now, and it is public.

The second Critical, CVE-2026-87719, has a smaller blast radius but a sharper one for anyone running Duo Chat. The advisory: "an authenticated user with Duo Chat access to obtain Advanced Search instance configurations and sensitive credentials using a specially crafted GraphQL subscription argument." Sensitive credentials. From a chat surface. Through a GraphQL subscription. If your assistant integration was already the part of the deployment nobody quite audited, congratulations: it is now the part nobody quite audited that also leaks configuration.

What the CI owner should actually rotate

Past the two Criticals, CVE-2026-88765 (High) is next on the pile: "an authenticated user to achieve remote code execution by importing a specially crafted Git project export to overflow the Unicode conversion buffer." Project import is exactly the surface a Developer-role account is expected to touch. Now it is also a Unicode-buffer overflow away from RCE on the instance that owns your pipelines.

Then CVE-2026-79708, also High: "a developer user to execute a policy test pipeline on projects within their group and access protected CI/CD variables." Protected CI/CD variables are the ones you told your compliance reviewer would only be reachable by protected branches on production jobs. A developer with policy-test-pipeline access can now reach them from a test path.

Rotate the ones that live on affected instances. All of them, if that answer is faster than the audit.

The upgrade itself is the second incident

Here is the part the release note says out loud, and the part worth rereading before scheduling the window: "This patch will cause downtime during the upgrade as migrations must complete before GitLab can start." That applies to single-node installs. Multi-node instances "with proper zero-downtime upgrade procedures" can apply the patch without downtime, per the same note. Which is to say: if you have not rehearsed the zero-downtime playbook, you are going to take the outage.

A Critical unauthenticated file read is not a defer-until-next-Tuesday event. A migration-heavy patch is not a "run it in prod first" event. Those two facts collide, and the collision is where CI teams lose weekends.

Verdict

GitLab did the right thing here on the release-note side: a coordinated cut across three supported minor lines, per-CVE descriptions instead of a vague "security fixes" blurb, explicit deployment guidance for both the SaaS side and self-managed operators. That is the version of security shipping we want.

It is also, as ever, only half of the transaction. The other half is you, on a Wednesday night, dragging a self-managed 19.2.x instance forward while your on-call engineer keeps refreshing the pipelines page.

Signed advisories are cheap. Applying them is not.

Rotate the CI/CD variables. Then upgrade.