Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVE-2026-85706

  • Two Monday deadlines outrank a day of nines and a seventeen-record batch

    Two Monday deadlines outrank a day of nines and a seventeen-record batch

    Eleven stories ran today, and the loudest of them were loud on the numbers: a 10.0, two 9.9s, a pair of 9.8s on a perimeter VPN appliance, and seventeen CVE records for one project landing in the same minute. None of that is what to deal with first. Two flaws already on CISA’s Known Exploited Vulnerabilities catalog come due Monday, September 14 — ConnectWise ScreenConnect and GitLab — and both carry BOD 26-04’s forensic-triage obligation, which means a federal agency has to remediate inside the window and also determine whether the asset was already compromised. That is about 48 hours, on the weekend, and it is the only thing on today’s wire with a clock attached. A 9.8 with a patch available can wait until Monday morning; these two cannot. The ScreenConnect item is also the one most likely to be misread: the flaw is in the client, not the server, so cloud-hosted customers told “no action is required” for their server still have to update every host client and access agent they run.

    The day had a thread, and it was GitLab. One patch release, September 10, produced three separate stories in eighteen hours, and the vendor supplied none of the new facts in any of them. Overnight, the CISA coordinator block attached to the NVD record marked exploitation “active” while GitLab’s own advisory said nothing about exploitation at all. By the afternoon the catalog itself carried Thursday’s addition and Monday’s deadline — a date this site declined to report twelve hours earlier and has since corrected on the story that got it wrong. And by evening the record for a second flaw in the same release, CVE-2026-87719, named the two things the release notes had left out: the entry condition is an authenticated user with Duo Chat access, not an administrator, and what they come away with is Advanced Search instance configurations and credentials.

    After the deadlines, the perimeter. Check Point’s two 9.8s let an unauthenticated attacker run code on a VPN appliance, and neither record names a fixed version — the boundary is a Jumbo Hotfix take number, and the Spark appliance line the advisories cover is missing from the records entirely. Frontegg SAML SSO accepts unsigned SAML responses at 9.8 with no fix at all, the plugin having been closed on WordPress.org on September 4. The Events Calendar took three releases to close two unauthenticated 9.8 remote code execution flaws on a plugin installed on more than 600,000 sites, and no changelog line says so.

    Below that, three records that describe a flaw better than they describe a remedy. AVideo’s seventeen all draw the affected line at the same git commit hash, with the last tagged release dating to April 2024. vLLM and Socket Firewall make an unflattering pair, because in both the thing that failed was the safeguard: a trust_remote_code flag that vanished into **kwargs, and a firewall that did not verify TLS to the registries it exists to police. Flatpak’s Critical sandbox escape waited 32 days for an identifier, and the one Flatpak CVE issued in the meantime was a different bug.

    Still open at the end of the day: NVD’s record for the GitLab 10.0 does not carry cisaExploitAdd or cisaActionDue, so the single most authoritative machine-readable source an operator is likely to query still does not say the flaw is on KEV with a deadline two days out. GitLab has said nothing about exploitation since the patch release. Frontegg has no fixed version to offer, AVideo has no release to upgrade to, and Check Point’s records still omit Spark.

  • GitLab’s second 9.9 is reachable by anyone with Duo Chat access, and hands over Advanced Search credentials

    GitLab’s second 9.9 is reachable by anyone with Duo Chat access, and hands over Advanced Search credentials

    The record GitLab published overnight names the AI assistant as the entry condition and instance credentials as the payoff — two details that were not in the release notes, and not in this site’s own story about the same release.

    What happened

    NVD published the record for CVE-2026-87719 at 3:16 a.m. UTC on Saturday, September 12, 2026 — the same minute it published the record for CVE-2026-85706, the 10.0 path traversal from the same GitLab patch release that went on the Known Exploited Vulnerabilities catalog Thursday with a Monday deadline. Both records came from GitLab as CNA. Only one of them has been read closely.

    The description for CVE-2026-87719, verbatim: “GitLab has remediated an issue in GitLab EE affecting all versions from 18.3 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that under certain conditions could allow an authenticated user with Duo Chat access to obtain Advanced Search instance configurations and sensitive credentials using a specially crafted GraphQL subscription argument to bypass serialization and perform server object lookup.”

    The record is marked Received. The only CVSS data on it is secondary, from [email protected]: 9.9, Critical, from the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, with an exploitability subscore of 3.1 and an impact subscore of 6.0. The weakness is CWE-502, deserialization of untrusted data. The two references are a GitLab work item and a HackerOne report; neither is readable without credentials.

    This publication covered the patch release on September 11 and described this flaw, from the release notes available then, as an insecure deserialization issue in the GraphQL subscription serializer scored 9.9 and affecting Enterprise Edition from 18.3. That was accurate as far as it went. It omitted the two facts a reader needs to decide whether this applies to them: who can reach it, and what they get.

    Who can reach it: “an authenticated user with Duo Chat access.” The vector’s PR:L agrees — low privileges, not administrative ones.

    What they get: “Advanced Search instance configurations and sensitive credentials.” The record does not say what those credentials authenticate to, and neither reference is reachable to say more, so this story does not assert it. What can be said from the vector alone is that S:C is set. Scope is marked Changed, which in CVSS terms means the impact lands outside the component that contains the flaw.

    The mechanism, in the record’s own words, is “a specially crafted GraphQL subscription argument to bypass serialization and perform server object lookup.” GraphQL subscriptions have to survive across requests, which means the server serializes references to objects and resolves them again later. CWE-502 plus “perform server object lookup” describes an argument that survives that round trip and points the resolver somewhere it should not go. That is a reading of the record’s phrasing, not a vendor-confirmed mechanism; GitLab has published no public writeup this story could reach.

    CVE-2026-87719 is not in the Known Exploited Vulnerabilities catalog. The mirror read for this story, catalog version 2026.09.11, contains four additions dated September 11, and this is not among them. No source checked reports exploitation of it. The fix versions are the same as for the 10.0: 19.1.8, 19.2.6, and 19.3.2.

    Why it matters

    The entry condition is the part that should change how an administrator thinks about this. Duo Chat is a productivity feature. It is the kind of thing that gets enabled at the group or instance level, for everyone, because the point of an assistant is that people use it. It is not a privilege anybody audits, because until this record was published there was no reason to think of it as a privilege at all. A permission model that grants chat access to every developer and a permission model that grants credential access to every developer are, for the duration of this flaw, the same model.

    Earlier tonight this site covered a vLLM flaw in which the flag meant to stop untrusted model code from running was silently discarded by a loader. The two have nothing in common technically. What they share is shape: a capability added for AI, wired through plumbing that predates it, arriving with a permission grant nobody had yet learned to treat as security-relevant. The pattern is not that AI features are written worse. It is that an assistant needs broad read access to be useful, it usually gets that access through the same API surface as everything else, and the threat model it lands in was written before the feature existed.

    Then there is the way this flaw has been ranked, in practice, by everyone including this publication. It scored 9.9, which is a number that in most weeks leads a bulletin. It arrived alongside a 10.0 that is on KEV with a federal deadline on Monday, and so it became the second item. Coverage of the release, this site’s included, treated it as the thing to mention after the main thing. That is a reasonable editorial instinct and it is also how a critical flaw gets under-patched: an organization that reads a summary, sees one headline CVE, and applies the upgrade will in this case be fine, because the upgrade is the same. An organization that reads a summary and applies a targeted workaround for the path traversal — there are people doing exactly that, because the 10.0 is the one with a deadline — will have addressed the flaw with the deadline and left the one with the credentials.

    Finally, the record is once again carrying detail the release notes did not. GitLab authored both. The same organization, as CNA, wrote a CVE description that names Duo Chat and credential disclosure, and as vendor wrote release notes that described a serializer issue. Neither is wrong. But operators read release notes on the day and CVE records weeks later, if at all, and in this case the document that arrived a day late is the one that tells you whether to care.

    What to do

    Upgrade self-managed GitLab to 19.1.8, 19.2.6, or 19.3.2, whichever matches your branch. This is the same release that closes CVE-2026-85706, which federal civilian agencies must remediate by Monday, September 14, 2026. If you were planning that upgrade for the path traversal, you are already covered here; if you were planning a mitigation instead of the upgrade, reconsider.

    This one is Enterprise Edition only, and it reaches back to 18.3 — further back than the 10.0, which starts at 18.7. An 18.3 through 18.6 Enterprise instance that concluded it was out of scope for the path traversal is in scope for this.

    Until you have upgraded, treat Duo Chat access as a privileged grant. Enumerate who has it. If your instance enables it broadly and you cannot upgrade today, turning it off for the interval is a mitigation that matches the record’s stated entry condition, though GitLab has published no mitigation guidance this story could reach, and that is a judgment rather than vendor advice.

    Afterward, rotate whatever credentials your Advanced Search configuration holds. The record says they were obtainable by any user with chat access; an upgrade stops further disclosure and does nothing about disclosure that already happened.

    Sourcing note

    Checked: the NVD record for CVE-2026-87719, published at 3:16 a.m. UTC on September 12, 2026, vulnStatus Received, with GitLab as the CVSS source — the vendor authored this record as CNA, which makes it a primary source for the description and score quoted above. Also checked: the NVD record for CVE-2026-85706 and this site’s two earlier stories on that flaw. The Known Exploited Vulnerabilities catalog was read from the cisagov/kev-data GitHub mirror, catalog version 2026.09.11, released at 7:32 p.m. UTC on September 11, because cisa.gov returns 403 to automated fetching; CVE-2026-87719 does not appear in it. Could not reach: both references on the record — GitLab work item 628160 and HackerOne report 4012289 — returned nothing readable, the HackerOne page with a 403; and GitLab’s patch release notes page redirects to a documentation index that does not list the September patch release, so the vendor’s own advisory wording for this CVE was not re-read for this story. Unresolved: what system the “sensitive credentials” authenticate to; whether GitLab considers Duo Chat access a mitigating control or simply a precondition; and whether any mitigation short of upgrading exists.

  • GitLab’s 10.0 went on KEV Thursday with a Monday deadline, and NVD’s record still doesn’t carry it

    GitLab’s 10.0 went on KEV Thursday with a Monday deadline, and NVD’s record still doesn’t carry it

    CISA added the GitLab path traversal to its Known Exploited Vulnerabilities catalog on Thursday with a remediation deadline of Monday, September 14, 2026 — a date this site declined to report twelve hours ago, because the source that carries it was misread as stale.

    What happened

    CVE-2026-85706 is in the Known Exploited Vulnerabilities catalog. Its entry carries a dateAdded of 2026-09-11 and a dueDate of 2026-09-14. Federal civilian agencies have until Monday.

    The catalog file that carries it is version 2026.09.11, with a dateReleased of 2026-09-11T19:32:16.8993Z — 7:32 p.m. UTC on Thursday, September 11. It holds 1,709 entries. Four of them were added that day: the two JFrog Artifactory flaws this site covered on September 11, a ConnectWise ScreenConnect flaw covered separately today, and GitLab.

    The GitLab entry is titled “GitLab Community Edition and Enterprise Edition Path Traversal Vulnerability.” Its short description reads: “GitLab Community Edition and Enterprise Edition contains a path traversal vulnerability that allows an unauthenticated user to read arbitrary files due to an improper path confinement and missing authentication enforcement in the repository commits API.” It is filed under CWE-35. Its knownRansomwareCampaignUse value is Unknown, and its forensicTriage value is Yes — the BOD 26-04 obligation that requires an agency to remediate inside the window and also determine whether the asset was already compromised.

    The flaw itself is unchanged from what this site reported on the evening of September 11. GitLab’s own record self-assigns CVSS 10.0 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. The description names the affected range as “all versions from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2,” which is the same boundary that produced this site’s earlier finding: there is no fixed 18.x build. An operator on 18.7 through 19.1.7 has one remedy, and it is 19.1.8.

    The record NVD still has not updated

    NVD republishes CISA’s catalog fields verbatim into CVE records — cisaExploitAdd, cisaActionDue, cisaVulnerabilityName, and cisaRequiredAction. As of 3:55 p.m. UTC on Saturday, September 12, the NVD record for CVE-2026-85706 carries none of them. Its lastModified value is 2026-09-12T04:16:44.907 and its vulnStatus is Received. That is more than twenty-five hours after the catalog was released, and the record still does not say the flaw is on KEV.

    The gap is not a general lag. CVE-2026-84869, the ConnectWise ScreenConnect flaw added to the catalog in the same release on the same day, was updated in NVD at 2026-09-11T19:57:11.373 — twenty-five minutes after the catalog went out — and it carries cisaExploitAdd of 2026-09-11 and cisaActionDue of 2026-09-14 in full. The two JFrog records from the same release picked up their CISA fields at 2026-09-12T04:16:32.483 and 2026-09-12T04:16:33.587. GitLab’s record was written twelve seconds after those two, in the same batch, and came away with nothing.

    Three of the four September 11 additions synchronized. One did not, and it is the one carrying a 10.0 and the shortest clock.

    The correction

    This site published a story at 6:47 a.m. UTC today reporting that CISA’s coordinator had flagged the flaw as actively exploited in an SSVC block, and stating that we could not confirm the KEV listing or the September 14 deadline that other outlets were reporting. That story said the cisagov/kev-data GitHub mirror was “stale at catalog version 2026.08.27.”

    It was not. The mirror serves catalog version 2026.09.11, released the previous evening, and it contains the GitLab entry. The file is about 1.7 MB, and it is retrievable in full over plain HTTP. The earlier read of it was wrong, and the conclusion drawn from that read — that no federal deadline could be confirmed — was wrong with it. A dated note now sits at the point of the error in that story, and the Corrections page carries the entry.

    What the earlier story got right is the part that still stands: NVD’s record does not carry the deadline, and the reasoning about the synchronization batch was correct as far as it went. The error was treating one unreadable source as an absent fact.

    Because that read is now load-bearing, it was checked against everything this site has already published from NVD. Twelve KEV dates reported here since September 8 — the two JFrog entries due September 25, both MikroTik RouterOS entries due September 13, Chrome due September 23, Fortinet, Citrix NetScaler, and Cisco FMC all due September 12, Adobe Commerce and N-able N-central due September 11, and both Windows entries due September 22 — match the mirror exactly, in every dateAdded and every dueDate. So does an absence: CVE-2026-67276, the third MikroTik flaw this site reported as unlisted, is still not in the catalog.

    Why it matters

    A federal remediation clock exists in exactly one authoritative place, and every other representation of it is a copy. When the copies disagree, the question of which one an organization is looking at stops being a curiosity and becomes the difference between acting on Saturday and acting on Tuesday.

    Most vulnerability management tooling does not read CISA’s catalog file. It reads NVD, or a vendor feed that reads NVD, because NVD is the one interface that carries scores, affected ranges, weaknesses, and KEV status in a single record. For twenty-five hours and counting, that interface has been telling every downstream consumer that CVE-2026-85706 has no federal deadline. An agency whose scanner enriches from NVD has a 10.0 sitting in its queue with no clock attached to it, and Monday is two days away.

    The second-order problem is that the failure is silent in both directions. Nothing in the NVD record announces that its CISA fields are pending. A missing cisaActionDue looks identical whether the flaw was never listed, was listed and has not synchronized, or was listed and later removed. This site made exactly that mistake this morning, with the primary source in reach and a method already written down for reaching it — which is a reasonable illustration of how the failure behaves for anyone else relying on the same field.

    There is also the matter of what the catalog now says that it did not used to. Every one of the 1,709 entries carries a forensicTriage value, and 51 of them read Yes. That is the BOD 26-04 obligation rendered as a machine-readable field, per entry, which is a meaningful improvement over the situation this publication has repeatedly flagged: the directive’s own deadline schedule is published as PNG images in an appendix, with no alt text, and public transcriptions of it disagree. The forensicTriage flag does not resolve that — it still does not tell anyone which variable combination earns which band — but it does mean an agency reading the catalog directly can see that this entry carries the triage obligation without having to derive it from a picture. None of that reaches a defender who is reading the NVD record for this CVE, because the NVD record for this CVE has no CISA fields in it at all.

    What to do

    Upgrade self-managed GitLab to 19.3.2, 19.2.6, or 19.1.8. There is no fixed 18.x build; installations on 18.7 through 19.1.7 must move to 19.1.8 or later. GitLab.com and Dedicated are on the patched version already.

    Federal civilian agencies: the deadline is Monday, September 14, 2026, and the entry carries the forensic-triage obligation, which means remediation alone does not close it. Assess whether the asset was compromised before the patch landed.

    If your vulnerability management platform sources KEV status from NVD, do not rely on it for this CVE this weekend. Check the catalog file directly. Anyone maintaining internal KEV automation should treat a missing cisaActionDue as unknown rather than as absent, and reconcile against the catalog rather than against the CVE record.

    Sourcing note

    The KEV entry, its dateAdded, dueDate, forensicTriage, requiredAction, short description, and CWE were read from the full catalog JSON published at the cisagov/kev-data mirror on GitHub, retrieved in full on September 12, 2026. cisa.gov returns 403 to automated fetching, so the mirror is the route used; the file carries CISA’s own catalogVersion and dateReleased metadata, and its contents were cross-checked against twelve KEV dates independently confirmed from NVD records over the past five days, all of which matched. CVE details, timestamps, and the absence of CISA fields were read from the NVD API records for CVE-2026-85706 and CVE-2026-84869 on September 12, 2026 at approximately 3:55 p.m. UTC.

    Unresolved: why the GitLab record did not receive its CISA fields when three other entries from the same catalog release did. NVD publishes no status for pending KEV synchronization, and there is no way from here to distinguish a queue failure from a deliberate hold. We also cannot establish from here whether the mirror was briefly serving an older catalog version at the time of this morning’s read or was simply misread; the file it serves now was released before that read took place, which points to the latter.

    Previous coverage: GitLab patches a 10.0 unauthenticated file read, and no 18.x build in the release carries the fix (September 11) and CISA’s coordinator marks the GitLab 10.0 as actively exploited, and GitLab’s own advisory still says nothing (September 12, corrected).

  • CISA’s coordinator marks the GitLab 10.0 as actively exploited, and GitLab’s own advisory still says nothing

    CISA’s coordinator marks the GitLab 10.0 as actively exploited, and GitLab’s own advisory still says nothing

    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.

  • In three of today’s eight stories, the fix on offer covers less than the flaw does

    In three of today’s eight stories, the fix on offer covers less than the flaw does

    The most consequential thing on the site today is not the 10.0. It is a three-day federal clock that runs out on Sunday. CISA added two of the three exploited MikroTik RouterOS flaws to the Known Exploited Vulnerabilities catalog on September 10, due September 13, and left off the SSH authentication bypass that CERT Polska puts first in the chain. Exploitation is confirmed by a national CERT, all three flaws are closed by the same RouterOS releases, and Shadowserver counts at least 122,500 MikroTik devices with SSH reachable per 24-hour scan window. An agency that upgrades is fine. An agency that works the catalog as a queue — patch what is listed, ticket what carries a due date — finishes Sunday compliant and still reachable through the door the catalog does not name.

    The biggest-sounding story is GitLab’s, and it ranks second. An unauthenticated arbitrary file read in the repository commits API, scored 10.0, is as bad as a number gets, and the research published on September 11 describes reaching configuration files, credentials, tokens, and SSH keys. But nobody has confirmed exploitation — watchTowr reports probes, and probing is not exploitation — and the 10.0 is GitLab’s own, with NVD returning no record at all as of early this morning. Recompute the vector without the integrity impact the advisory’s own description does not describe, and it is an 8.6. What is not in dispute is the work: self-managed operators have a critical to install, and some of them cannot.

    That last clause is the day’s thread, and it runs through three of the eight stories. GitLab names installations from 18.7 as affected and ships no 18.x build in the release, so a shop sitting on 18.7 through 18.11 is inside the affected range and outside the branch that got the fix — a major-version migration, not a patch. CISA put two more JFrog Artifactory flaws on KEV with a September 25 deadline, and on the 7.133 branch their fixes are seventeen patch releases apart: an administrator who took 7.133.11 in July to close CVE-2026-42016 is still exposed to CVE-2026-42018 today, and a version check that stops at 7.133.11 reports the box clean. And CISA’s MikroTik entries cover two links of a three-link chain. In each case the fix on offer covers less than the flaw does, and in each case you see it only by reading two documents side by side.

    The other four are disclosure stories, and what they share is an absence. Florida’s motor vehicle agency confirmed that DAVID, its law enforcement driver database, was breached through credentials a Plant City police employee stored on a personal device, and named no number; every figure in circulation — 200,000 records, Social Security numbers, and dates of birth — belongs to ShinyHunters. Nutex Health’s stolen data has been published online, and the company filed that under Item 8.01 with its materiality assessment unchanged, no count and no dates. Conduent settled the class action over its January 2025 breach with no dollar figure, also under Item 8.01, having filed the incident itself under Item 1.05. Greenberg Traurig told Vermont and California regulators that Social Security numbers were in scope on September 8 and September 9, then publicly called the exposure limited on September 10. Furthest from an action item, Anthropic’s misuse report describes one actor working through roughly thirty AI companies in about four days, swapping in each victim’s own API keys as it went — a billing and attribution problem as much as a security one.

    Open tonight. CVE-2026-67276, the MikroTik bypass, still carries no exploit-add date and may yet be added; worth re-checking before Sunday. CISA’s alert for September 11 is titled as one catalog addition while two records carry that day’s exploit-add date, and cisa.gov returns 403 to automated fetching, so the count could not be reconciled. GitLab has said nothing about the 18.x case. The distillation claim circulating in coverage of the Anthropic report — seven named Chinese labs, industrial scale — does not appear in the document we read. And four organizations described a breach today without producing a number. Nutex says its review will take several weeks.

  • GitLab patches a 10.0 unauthenticated file read, and no 18.x build in the release carries the fix

    GitLab patches a 10.0 unauthenticated file read, and no 18.x build in the release carries the fix

    Update, September 12, 2026: NVD published its record for CVE-2026-85706 at 3:16 a.m. UTC on September 12, after this story ran. The record carries a CISA-ADP SSVC block dated September 11 setting Exploitation to active. This story’s statement that exploitation was unconfirmed was accurate at publication and is now contested by CISA’s own coordinator. The record also confirms there is no 18.x fixed build: the vendor gives 19.1.8 as the fix for the 18.7 range. See the follow-up story.

    GitLab’s September 10 critical patch release closes an unauthenticated arbitrary file read in the repository commits API and scores it 10.0 — a number that rests on an integrity impact the advisory’s own description does not describe, in a release that ships no patched 18.x build for the 18.7 installations it names as affected.

    What happened

    GitLab published a critical patch release on September 10, 2026, shipping versions 19.3.2, 19.2.6, and 19.1.8 and closing 18 security issues. At the top of the table is CVE-2026-85706, which GitLab labels Critical and scores 10.0.

    GitLab’s own description of the flaw, verbatim: “GitLab has remediated an issue that, under certain conditions, 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.” The release credits the report to the researcher s3ntago, submitted through GitLab’s HackerOne bug bounty program.

    The affected range, as the release states it: all versions from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N.

    GitLab’s recommended action, verbatim from the release page: “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.” Separately, the company states that “GitLab.com is already running the patched version” and that “GitLab Dedicated customers do not need to take action.” The people who have work to do are the ones running self-managed GitLab.

    The same release carries a second critical issue, CVE-2026-87719, an insecure deserialization flaw in the GraphQL subscription serializer scored 9.9 and affecting GitLab Enterprise Edition from 18.3. Sixteen further issues run from 8.5 down to 3.1, including a buffer overflow in a Unicode conversion wrapper, two denial-of-service flaws in the GraphQL complexity limiter, an incorrect-authorization flaw in the CI/CD environment variable scope matcher, and a SAML single sign-on restriction that is not enforced.

    Two research firms published assessments on September 11. watchTowr says it is “observing in-the-wild probes” against the flaw but gives no count and no dates for them. Horizon3 describes building a NodeZero Rapid Response test to validate exploitability and lists the file classes an attacker could reach — “configuration information, credentials, secrets, tokens, SSH keys, database credentials, or other server-side data.” Neither firm published working exploit code, and neither published a number for exposed or probed instances. GitLab itself says nothing about exploitation. Probing is not exploitation, and nothing in the primary sources supports calling this exploited.

    As of 1:30 a.m. UTC on September 12, the NVD API returns zero results for CVE-2026-85706. GitLab’s self-assigned score is the only score in circulation.

    Why it matters

    Two metrics in that vector are carrying the 10.0, and both are worth reading closely, because with no NVD record there is no second opinion to compare against.

    Recompute the vector with the integrity metric dropped to I:N — an attacker who can read arbitrary files but not change them — and the base score falls to 8.6. Drop the scope change as well, to S:U/C:H/I:N/A:N, the shape a plain unauthenticated file read usually takes, and it falls to 7.5. The distance between “high severity” and a perfect ten is entirely those two metrics.

    The scope change is defensible on its face. Reading gitlab-secrets.json or gitlab.rb off a GitLab server does not stay inside GitLab: it hands over CI/CD variables, runner registration tokens, database credentials, and the keys that sign sessions, all of which are authority over other systems. That is what a changed scope is meant to capture.

    The integrity impact is harder to read off the description. I:H asserts a total loss of integrity — the attacker can modify data. The advisory describes a read, and only a read: “could have read arbitrary files from the GitLab server.” Either the description understates what the flaw permits, or the vector overstates it. A third reading is more charitable and probably closest: GitLab is scoring the downstream consequence of reading credentials rather than the primitive itself, on the grounds that stolen signing secrets become write access in the next step. That is a judgment about chained impact, not a metric the description supports, and it is precisely the kind of scoring choice that is invisible to anyone who reads only the number. This publication has covered the same ambiguity from the other direction more than once this month, where a described crash outscored a described takeover.

    The second problem is more concrete. GitLab says the flaw affects installations from 18.7 onward, and every fixed version in this release is a 19.x build. There is no 18.x release in the batch. GitLab backports security fixes to the current minor and the two before it, which today means 19.3, 19.2, and 19.1 — so an installation sitting on 18.7 through 18.11 is inside the declared affected range and outside the branch that received a fix. For those operators, “upgraded to the latest version as soon as possible” is not a patch. It is a major-version migration, with the runner, database, and extension compatibility work that implies, under a 10.0.

    That gap is worth naming because GitLab’s previous critical patch release, 19.2.4 together with 19.1.6, 19.0.8, and 18.11.11, did carry an 18.x build. The affected range in this release reaches further back than the fix does. We found no statement from GitLab addressing the 18.x case, and the release page does not mention it.

    The shape is familiar from this week. A JFrog Artifactory release named as the fix for one cataloged flaw left a second one on the same branch open. A Knowns release named as the fix for five CVEs turned out to be the top of the affected range for a later 9.8. The pattern is not vendors hiding things — it is that an affected-version range and a fix-version list are produced by different processes inside the same company, and nobody reconciles them before publication. The reader who patches to the named version and stops has done what the advisory asked and is still exposed.

    Self-managed GitLab is also a worse target than its install base suggests. It is where source code, pipeline definitions, signing keys, and cloud deploy credentials sit in one place, usually behind a single hostname, frequently internet-facing because developers and runners need to reach it. An unauthenticated read primitive against that host is a credential-harvesting operation, not an information disclosure. That is the reason to treat two firms’ reports of reconnaissance as a clock, even though neither is evidence of a breach.

    What to do

    Upgrade self-managed GitLab to 19.3.2, 19.2.6, or 19.1.8, whichever is on your branch. GitLab.com and GitLab Dedicated are patched and need no action, per GitLab.

    If you are on 18.7 through 18.11, there is no patched build on your branch in this release. Plan the move to 19.1.8 and, until it lands, block or tightly restrict unauthenticated access to the repository commits API at the reverse proxy or WAF, and put the instance behind network controls if it is internet-facing.

    Search access logs for requests to repository commits API paths carrying traversal sequences, including encoded forms. If you find reads that succeeded, treat it as credential compromise: rotate gitlab-secrets.json, CI/CD variables at every scope, runner registration tokens, personal and project access tokens, database credentials, and any cloud role keys stored on the host.

    Apply the same release’s CVE-2026-87719 fix if you run Enterprise Edition 18.3 or later — a 9.9 insecure deserialization in the GraphQL subscription serializer is not a second-tier item, and it reaches further back than the path traversal does.

    Sourcing note

    Written from GitLab’s critical patch release page for 19.3.2, 19.2.6, and 19.1.8 on docs.gitlab.com, dated September 10, 2026, which is the source for the release date, the CVE list, the verbatim description and recommended-action language, the CVSS vector and score, the affected ranges, and the HackerOne credit. The CVSS recomputations are ours, using the published CVSS v3.1 formula against GitLab’s vector with single metrics changed.

    The NVD API was queried for CVE-2026-85706 and returned zero results at 1:30 a.m. UTC on September 12, 2026; there is therefore no NVD-assigned score, no CWE, and no CPE range to compare against GitLab’s. The 18.x question was checked against GitLab’s own release pages, which show an 18.11.11 build in the previous critical patch release and none in this one; we found no GitLab statement on whether 18.x will receive a backport, and that remains unresolved. Added September 11, 2026, 9:10 p.m. Central: the statement that GitLab backports to the current minor and the two before it reflects its published maintenance policy as borne out by the release pattern; the policy page itself was not re-read for this story, and the conclusion that no 18.x build exists in this release rests on the release page’s own version list.

    watchTowr’s and Horizon3’s assessments, both dated September 11, 2026, are the source for the reconnaissance reports and the file classes at risk. Both are single-vendor observations with no published counts, and neither reports confirmed exploitation. No exploit code was reviewed because neither firm published any. GitLab has made no statement about exploitation, and this page does not treat the flaw as exploited. cisa.gov returns 403 to automated fetching, so the catalog could not be read directly; the NVD record for this CVE does not exist yet, so there is no cisaExploitAdd to report either way, and the flaw carries no federal deadline as of this writing.