GitLab 19.0 Stops Receiving Security Patches on August 20 — and GitLab's Whole Support Window Is 91 Days Wide

Published: August 10, 2026  ·  EOL Watch — deadline coverage  ·  Dates verified against GitLab's release and maintenance policy, the live CISA KEV catalog (August 10, 2026), and our tracked lifecycle data — methodology

On August 20, 2026, GitLab 19.0 leaves the security-patch window. Per our tracked lifecycle data, 19.0 shipped on May 21, 2026 — which means the version that was GitLab's newest release in late May will be an unsupported release 91 days later. That is not a slip, a deprecation, or a special case. It is GitLab's support model working exactly as documented, and it is radically shorter than what most infrastructure teams assume a "supported version" window looks like.

GitLab's release and maintenance policy is explicit: security fixes go to "the previous two monthly releases in addition to the current stable release," and regular bug fixes go to only the current stable release. Minor versions ship monthly, "scheduled for the third Thursday of each month." Put those two rules together and support for self-managed GitLab is a rolling three-release window, roughly 90 days wide, that moves every month whether you do or not. There is no LTS track. August's monthly release is due August 20 — the third Thursday — and when it lands, 19.0 becomes the fourth-newest release and falls out.

If you run gitlab.com, none of this is your problem; GitLab operates and patches it. If you run self-managed GitLab — the instance holding your source code, your CI/CD credentials, and the pipelines that deploy to production — the next section is the one assumption to check this week.

The three-release window: what GitLab's policy actually says

Three sentences of GitLab's maintenance policy define the entire mechanism. Minor releases are monthly, on the third Thursday. Bug fixes target only the current stable release. Security fixes reach the current stable release plus the previous two monthly releases. That last rule is the load-bearing one: each version is patched from its release day until three newer monthly releases exist — in practice about 91 days, per the release-to-EOL spans in our tracked data.

Two honest caveats cut in opposite directions. First, GitLab notes that "for highly severe security issues, there is precedent to backport security fixes to even more previous GitLab release versions" — an exception process, real but discretionary, not something an instance's lifecycle can be planned around. Second, the policy also states that in some circumstances GitLab may address a vulnerability in the regular monthly process "with no backports" — meaning even inside the three-release window, the guaranteed fix vehicle is the newest patch release of your minor. The window is the commitment; everything older runs on precedent and luck.

Compare that to the platforms GitLab usually sits next to in an infrastructure inventory. Ubuntu LTS gets five years of standard security maintenance. RHEL gets ten. PostgreSQL gets five. Even Kubernetes — famously fast-moving — patches each minor for roughly 14 months. GitLab's window is ~3 months. Teams that put GitLab on the same "patch it quarterly" schedule as the rest of the stack are not slightly behind GitLab's model — they are permanently outside it, because a quarterly cadence is almost exactly one full window wide.

Where every recent GitLab version stands

Dates below are from our tracked lifecycle data (verification pass 2026-08-10), which follows GitLab's published release and maintenance schedule. Each version links to its live lifecycle page with current status and risk score. "Security patches end" is the day the version exits the three-release window — GitLab's effective end of life for that minor.

Every version older than 18.8 — 18.7 back through 17.x and earlier — is further past its window still. Note the pattern in the middle columns: each version's "security patches end" date is exactly the release date of the version three rows up. That is the rolling window made visible. Even 19.2, today's current stable release, carries a Warning badge — on this cadence, every GitLab version is always within 180 days of its end date, from the day it ships.

Why an unpatched GitLab is a crown-jewel target

A self-managed GitLab instance is not one system; it is the keys to most of the others. It holds your source code, the secrets and deploy credentials stored in CI/CD variables, and pipeline runners that execute code against production infrastructure. Compromising it yields supply-chain access — which is why GitLab has a verified track record in CISA's Known Exploited Vulnerabilities catalog, the US government's list of flaws confirmed exploited in the wild. We checked the live catalog today (August 10, 2026 release, 1,662 entries). It contains four GitLab vulnerabilities:

• CVE-2021-22205 — remote code execution in GitLab CE/EE. Added to KEV on November 3, 2021, and flagged by CISA for known use in ransomware campaigns.
• CVE-2023-7028 — the account-takeover flaw (KEV lists it as improper access control) in which password-reset emails could be sent to an attacker-controlled address. Added to KEV on May 1, 2024.
• CVE-2021-39935 — server-side request forgery in GitLab CE/EE. Added to KEV on February 3, 2026.
• CVE-2021-22175 — server-side request forgery. Added to KEV on February 18, 2026.

Read the dates on the last two again. CISA added two 2021 GitLab vulnerabilities to the exploited-in-the-wild list in February 2026 — five-year-old flaws, still being used against instances that never left their patch level. That is the practical meaning of a 91-day support window on a high-value target: the fixes exist, ship fast, and stop shipping for your version quickly, while the exploitation of old versions carries on for years. An instance that exits the window on August 20 doesn't become a target eventually; it joins a population that attackers demonstrably still work through in 2026.

Starting late compounds: the upgrade-stop trap

The three-release window has a second-order consequence that surprises teams who fall behind: catching up is not one jump. GitLab's upgrade-path documentation states that "upgrade paths include required upgrade stops, which are versions of GitLab that you must upgrade to before upgrading to later versions" — and that at each stop you must let background database migrations finish before continuing. In the 18.x line, the required stops are 18.2, 18.5, 18.8, and 18.11; in 19.x, 19.2 is a required stop, with 19.5, 19.8, and 19.11 planned.

So an instance sitting on, say, 18.4 today cannot go straight to 19.2. It goes 18.4 → 18.5 → 18.8 → 18.11 → 19.2 — four sequential upgrades, each with a migration wait, each a maintenance window to schedule. Every month of delay risks adding another stop to the path, which is why "we'll batch it up and do one big upgrade later" is the single most expensive way to run self-managed GitLab: the work grows linearly while the unpatched exposure grows with it. Teams that stay inside the window do one small monthly (or at minimum quarterly-with-stops) upgrade forever — which is the actual price of self-managing this product, and worth comparing honestly against gitlab.com or a managed provider if the cadence doesn't fit your operations.

What to do before August 20: run gitlab-rake gitlab:env:info (or check Admin > Overview) on every instance — including the "temporary" ones on forgotten VMs — and read its version against the table above. On 19.0 or 19.1: upgrade to 19.2 this window; it is a required stop anyway, so the work is never wasted. On 18.x or earlier: you are already unpatched, and the job is a staged catch-up through the stops, starting now rather than after the next KEV entry. We track every GitLab version's status live, or check your exact version in seconds.

Frequently Asked Questions

Related

• All GitLab versions with live status · GitLab 19.0 — dates and risk score
• Every Jenkins LTS Except the Newest Is Now Permanently Vulnerable — the same rolling-support mechanism, caught mid-incident
• The H2 2026 EOL Pileup — what else runs out this half
• The 2026 EOL Calendar — every tracked deadline this year