The CVE record NVD published overnight carries a CISA Coordinator block dated September 11 that reads Exploitation: active — a call GitLab has not made, watchTowr has not made, and that no reachable primary source ties to a federal deadline.
What happened
NVD published its record for CVE-2026-85706 at 3:16 a.m. UTC on Saturday, September 12. Severity Daily covered the GitLab patch release the flaw came from on the evening of September 11, when there was no NVD record to read. There is one now, and it carries something the release notes do not.
Attached to the record is a second data container contributed by CISA under its Authorized Data Publisher program. It is an SSVC decision-point block, version 2.0.3, carrying the organization ID 134c704f-9b21-4f2e-91b3-4a467353bcc0, the role CISA Coordinator, and the timestamp 2026-09-11T00:00:00+00:00. It sets three values. Exploitation is active. Automatable is yes. Technical Impact is total.
That is a United States government coordinator stating, in the public vulnerability record, that this flaw is being exploited. It is the strongest reading any of the three decision points allows.
GitLab has said no such thing. The vendor’s critical patch release of September 10, 2026 — versions 19.3.2, 19.2.6, and 19.1.8 — lists the path traversal at the top of an eighteen-item table with a self-assigned CVSS 10.0 and the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Its only urgency language is generic: “We strongly recommend that all installations running a version affected by the issues described below are upgraded to the latest version as soon as possible.” The page says nothing about exploitation, and GitLab has published nothing since.
watchTowr, which published a rapid reaction on September 11 and is the only public telemetry on this flaw, is more careful than CISA and less careful than silence. It reports observing “in-the-wild probes” and assesses the vulnerability as “high-likelihood for in-the-wild exploitation.” It gives no probe count, no host count, no timestamps, and no indicators. Probing is not exploitation, and watchTowr does not claim it is.
So three parties who can see this flaw have taken three positions: the vendor is silent, the researcher says probes, and the agency says active.
The catalog entry we cannot confirm
Correction, September 12, 2026, 4:10 p.m. Central. This section is wrong. CISA did add CVE-2026-85706 to the Known Exploited Vulnerabilities catalog on September 11, 2026, with a dueDate of 2026-09-14 — the deadline reported by other outlets and declined here. The claim below that the cisagov/kev-data GitHub mirror is “stale at catalog version 2026.08.27” is also wrong: the mirror serves catalog version 2026.09.11, released at 2026-09-11T19:32:16.8993Z, and it contains the GitLab entry in full. The mirror was misread. Everything this section says about the NVD record remains accurate — as of 3:55 p.m. UTC on September 12 the record still carries no cisaExploitAdd and no cisaActionDue — but the absence of those fields in NVD is not evidence that the catalog entry does not exist, which is the inference this section drew. The listing, the Monday deadline, and the NVD synchronization gap are reported in a separate story. This post has been tagged kev-due-2026-09-14.
Several outlets reported on September 12 that CISA added CVE-2026-85706 to the Known Exploited Vulnerabilities catalog on September 11 with a remediation deadline of September 14, 2026. We are not reporting that date, because we could not verify it from a primary source, and there is affirmative evidence against it in the record.
NVD republishes CISA’s own catalog fields verbatim — cisaExploitAdd, cisaActionDue, cisaVulnerabilityName, cisaRequiredAction. The GitLab record was last modified at 2026-09-12T04:16:44.907 and carries none of them. That timestamp matters. In the same NVD batch, twelve seconds earlier, the two JFrog Artifactory records this site covered on September 11 were updated at 2026-09-12T04:16:32.483 and 2026-09-12T04:16:33.587, and both came away carrying cisaExploitAdd of 2026-09-11 and cisaActionDue of 2026-09-25. The synchronization that would have delivered a GitLab catalog entry ran, delivered two others dated the same day, and delivered nothing for GitLab.
That is not proof the entry does not exist. NVD lags the catalog, and a catalog write after the batch would not appear yet. But it is the opposite of the usual lag pattern, and it is the only primary evidence available, because cisa.gov returns 403 to automated readers and the cisagov/kev-data GitHub mirror is stale at catalog version 2026.08.27. Until cisaActionDue appears in the record, this page carries no federal deadline and no kev-due- tag, and the homepage deadline strip will not show one.
Why it matters
KEV and SSVC are different instruments that happen to be published by the same agency, and this week they are pointing in different directions on the same flaw.
KEV is a catalog with an obligation attached: a listing sets a clock for federal civilian agencies. SSVC is a prioritization aid CISA writes into CVE records through the ADP program, and it carries no clock at all. Most defenders watch the first and have never looked at the second. On this flaw, the second one moved first and said more.
Which is the safer instrument to trust depends on a question nobody outside CISA can answer from here: whether Exploitation: active in an ADP block is the same determination that puts a CVE on KEV, arriving early, or a looser judgment that does not by itself meet the catalog’s evidentiary bar. Both readings are alive in the record as it stands. A defender who treats the SSVC block as the real signal patches today. A defender who waits for the catalog may be waiting on a synchronization delay, or may be correctly declining to act on a flag that was never meant to trigger action.
There is a second reason the SSVC block is worth reading closely. CISA’s BOD 26-04, which replaced BOD 22-01 in June, derives federal remediation deadlines from four binary variables: internet exposure, KEV listing, exploit automation, and whether technical impact is total or partial. Three of those four are now filled in on the public record by CISA itself — automation is yes, technical impact is total, and exploitation is active. The fourth, internet exposure, is a property of each agency’s own deployment.
An agency running an internet-facing self-managed GitLab therefore has all four values in hand. It still cannot derive its own deadline, because the mapping from variables to deadline bands is Table 1 in Appendix A of the directive, published only as PNG images with no alt text, and the third parties who transcribed it by eye do not agree with each other about which combinations earn the shortest clock. That is the unresolved condition this publication has flagged before, and this flaw is a clean example of what it costs: the inputs are machine-readable and the function is not.
Finally, the record now settles a question this site left open yesterday. GitLab’s CNA container gives three affected ranges with their fixed versions: 18.7 through 19.1.7, fixed in 19.1.8; 19.2 through 19.2.5, fixed in 19.2.6; and 19.3 through 19.3.1, fixed in 19.3.2. There is no 18.x fixed build, and now there is no ambiguity about whether one is coming — the vendor’s own structured data says the remedy for an 18.7 installation is 19.1.8. For anyone still on the 18 series, the fix for a 10.0 is a major-version upgrade, and change-control boards do not treat those the way they treat patches.
What to do
Self-managed GitLab installations should move to 19.1.8, 19.2.6, or 19.3.2, whichever is the lowest version at or above the current branch. GitLab.com is vendor-operated and not the customer’s action.
If you are on any build from 18.7 onward, there is no in-branch patch. The minimum safe target is 19.1.8, and treating that as an emergency major upgrade rather than a scheduled one is the right posture given the SSVC flag.
For detection, watchTowr’s guidance is to review “recent access logs on the repository commits API for unusual or unauthenticated requests.” Unauthenticated reads of the commits API are the signature; there are no published indicators beyond that.
Federal agencies should check the live KEV catalog directly rather than relying on NVD’s copy or on this page. If a catalog entry and deadline exist, our sources cannot see them.
Sourcing note
Checked: the CVE record for CVE-2026-85706 at NVD (published 2026-09-12T03:16:30.473, last modified 2026-09-12T04:16:44.907) and the same record at the CVE Program’s own API, where the CNA container is dated 2026-09-12T02:46:31.624Z and the CISA-ADP container 2026-09-12T03:55:28.239Z; GitLab’s critical patch release page for 19.3.2, 19.2.6, and 19.1.8; watchTowr’s rapid reaction of September 11; and the NVD records for CVE-2026-42016 and CVE-2026-42018 as a same-batch control.
Could not reach: cisa.gov, which returns 403 to automated fetching, so the KEV catalog page and the September 11 alert could not be read. The cisagov/kev-data GitHub mirror was read instead and is stale, ending at catalog version 2026.08.27. We did not route around the 403 by any other means.
Unresolved: whether CVE-2026-85706 is on KEV and whether a September 14, 2026 deadline exists. Secondary coverage says both; no primary source we can read confirms either, and NVD’s same-batch behavior points the other way. Also unresolved: what evidence underlies CISA’s Exploitation: active determination, and whether GitLab agrees with it. GitLab has not responded publicly to the flag as of publication.