Self-Hosted Git and Registries 2026: Exposure and Patch Data

Internet exposed self-hosted Git servers patch slowly. Shadowserver counted 5,379 GitLab instances open to CVE-2023-7028 on 23 January 2024, twelve days after the fix, and roughly 1,400 to 2,149 in early May 2024, depending on the outlet. Vendor support windows run from about three months to two years.

Nobody publishes a census of self-hosted GitLab, Gitea, Forgejo, Bitbucket Data Center, GitHub Enterprise Server or Harbor installs. What exists is a handful of internet scan snapshots, each project's own advisory list and support policy, and the CISA Known Exploited Vulnerabilities (KEV) catalog. We pulled each of those from the source, dated every figure, and marked the places where the sources do not agree.

Key takeaways

• The only well documented patch curve for a self-hosted Git server is GitLab and CVE-2023-7028: 5,379 vulnerable instances on 23 January 2024 (Shadowserver via BleepingComputer), about 1,400 on 1 May 2024 (SecurityWeek) or 2,149 from a 4,652 baseline (The Register). Roughly a quarter to a half were still exposed about 16 weeks after the fix.
• CISA added CVE-2023-7028 to KEV on 1 May 2024, almost four months after GitLab's 11 January 2024 patch. A second GitLab flaw, CVE-2026-85706, was added on 11 September 2026 with a three day federal due date.
• Documented security support windows differ by a factor of eight. GitLab backports security fixes to the current release and the two before it (about three months). Forgejo stable releases live about three months and its LTS releases about 15 months. GitHub Enterprise Server releases close about one year after release. Atlassian supports each Bitbucket Data Center feature or LTS release for two years. Gitea's policy fixes only the most recent major release and main.
• Harbor's GitHub advisory list held 41 advisories on 23 October 2026, from a 2019 high severity issue to 13 advisories published on 6 October 2026. Harbor's maintainers disputed CVE-2026-4404 and asked for its rejection, while the NVD record carries a 9.4 score from the CVE's assigner. Both statements are on the public record at the same time.
• Atlassian Server support ended on 15 February 2024. Atlassian's Data Center end of life is 28 March 2029, and Bitbucket Data Center is excepted from it. AWS CodeCommit closed to new customers on 25 July 2024 and reopened on 25 November 2025.
• Scan counts only see servers that are reachable from the internet and fingerprintable. Most self-hosted installs sit behind a VPN or on an internal network and never appear in these numbers, in either direction.

Who runs self-hosted Git and registries, and how big is that population?

The honest answer is that nobody knows the total. Three groups tend to self-host source code and images: regulated organizations that need data residency or air gaps, large engineering organizations that want control over upgrade timing and integrations, and small teams or hobbyists who run Gitea, Forgejo or a plain registry on a single machine. Infrastructure teams also run self-hosted registries such as Harbor as the private image store next to a Kubernetes cluster.

What can be measured is narrower. Internet scanning projects like the Shadowserver Foundation probe public IPv4 and IPv6 space, fingerprint web applications, and, for selected vulnerabilities, infer the installed version. That yields a count of internet exposed instances that look vulnerable, not a count of installs. Shadowserver's January 2024 GitLab data used the tags http_vulnerable and http_vulnerable6, according to the dashboard link BleepingComputer published, which tells you the counts came from HTTP responses over IPv4 and IPv6.

The vendors publish the second kind of data: what versions they support, how often they ship patches, and what they fixed. The third kind is the CISA KEV catalog, which records which of these products have flaws that were exploited in the wild.

None of these three counts installations, so none of them can give you a market size. This post sticks to exposure and patching.

How fast did exposed GitLab servers patch CVE-2023-7028?

GitLab's patch release of 11 January 2024 fixed CVE-2023-7028, a flaw in which password reset emails could be delivered to an unverified address, which allowed account takeover. GitLab rated it critical with a CVSS score of 10.0. The fix shipped in 16.7.2, 16.6.4 and 16.5.6, with backports to 16.1.6, 16.2.9, 16.3.7 and 16.4.5. GitLab's release notes say the flaw affected all authentication mechanisms on self-managed instances, and that accounts with two factor authentication could have their password reset but could not be taken over.

What followed is the clearest public patch curve for any self-hosted Git server.

Ranked table: GitLab CVE-2023-7028 exposure snapshots, by count

The table is ordered by the measured count, highest first. It is not a clean time series. Two outlets read the same Shadowserver dashboard around the same week in May 2024 and reported numbers that differ by about 750 instances, and they used different January baselines. We discuss why below.

The country split from the first snapshot, as BleepingComputer reported it on 24 January 2024: United States 964, Germany 730, Russia 721, China 503, France 298, United Kingdom 122, India 117 and Canada 99. The Register's May article named no countries and said only that the largest concentrations were in Europe and Asia.

What the curve says, read carefully

Take the two consistent pairs. Using BleepingComputer's January figure and SecurityWeek's May figure, about 74% of the exposed instances dropped out of the vulnerable count in roughly 14 weeks. Using The Register's own pair, about 54% dropped out. "Dropped out" is not the same as "patched". An instance leaves the count when it is upgraded, but also when it is shut down, moved behind a firewall, changes IP address, or stops returning a fingerprint the scanner recognizes.

Even with that generous reading, at least 1,400 internet facing GitLab servers were still running a version open to a CVSS 10.0 account takeover flaw on the day CISA put it on the KEV list. The fix had been public for 16 weeks by then.

The January baseline, the May count, the severity score and even one fix version differ between sources; the full list is in the section on disagreements below. None of it changes the shape of the curve, but any single number from this case should be quoted with its source and date.

What patch cadence and backport window does GitLab document?

GitLab's maintenance policy, fetched on 23 October 2026, sets three rhythms:

• A monthly minor release on the third Thursday of each month.
• Planned patch releases twice a month, on the Wednesdays the week before and the week after the minor release.
• Security fixes backported to the current stable release and the two previous monthly releases. Bug fixes go only to the current stable release.

On the day we checked, GitLab listed 19.5 for bug and security fixes, and 19.4 and 19.3 for security fixes only. The policy also says some vulnerabilities may be fixed only in the current release with no backport, and that backport requests for lower severities are declined automatically.

In practice, three monthly releases is about 13 weeks of security coverage for any given minor version, which matches the "91 day window" phrase our planning notes used. A team that upgrades once a quarter can stay inside the window, but only if each quarterly upgrade lands on the newest release. A team that upgrades twice a year will spend months on a minor version that no longer gets security backports at all.

The same release notes for 16.7.2 show what a critical patch also asks of you: review gitlab-rails/production_json.log and gitlab-rails/audit_json.log for signs of abuse, enable two factor authentication for every account and especially admins, and rotate secrets if you suspect compromise. GitLab also told self-managed users to move on to 16.7.3, 16.6.5 or 16.5.7 because of a database migration issue in the first patch. A single critical CVE produced two upgrades in a row.

GitLab's second KEV entry is a 2026 one. CVE-2026-85706, a file read flaw in the repository commits API that GitLab scored at 10.0, affects 18.7 before 18.11.12 and the 19.0 through 19.3 lines before their listed fixes, according to the NVD record. CISA added it to KEV on 11 September 2026 with a federal due date of 14 September 2026, three days later. Our explainer on a separate 2026 GitLab self-managed flaw walks through a similar upgrade.

What does Gitea's and Forgejo's release history show?

Gitea

Gitea's security policy states that only the most recent major release and the main branch receive security fixes. Reports that affect only unsupported versions are closed as out of scope. The policy does not publish a response or disclosure timeline.

The release notes we fetched show what a Gitea security release tends to look like. Gitea 1.23.6, released on 24 March 2025, was described as addressing "three critical security issues". Two of the three were dependency updates: CVE-2025-30204 in a JWT library, CVE-2025-29923 in a Redis client, and CVE-2025-22870 in the Go x/crypto and x/net modules, alongside a fix to Git LFS URL handling. Gitea 1.25.3, released on 18 December 2025, carried one security entry: a bump of the Go toolchain to 1.25.5 to pick up two crypto/x509 fixes, tracked as GO-2025-4175 and GO-2025-4155 rather than as CVEs.

That pattern matters for anyone tracking Gitea exposure. A large share of a Gitea server's security fixes arrive through its Go dependencies and the Go toolchain, not through Gitea's own code. Scanners that only match the Gitea version against Gitea CVEs can miss them, and scanners that read the embedded Go module list can catch them.

Gitea's GitHub security advisory list spanned 16 pages on 23 October 2026. Eight advisories on the first page alone were published on 6 or 18 October 2026, covering permission checks on attachments, a cross site request forgery issue, a memory exhaustion issue in the Actions artifact API, and a case where push to create ignored the server's force private setting. All were rated low or moderate. We cover a higher severity 2026 Gitea flaw in our Gitea git hooks explainer.

We did not count Gitea CVEs from aggregator sites. Some sites publish totals for Gitea CVEs; we could not reproduce those totals from NVD or GitHub advisories, so we do not quote them.

Forgejo

Forgejo publishes a fixed release schedule. Stable releases ship every quarter. Every fourth release is a long term support (LTS) release: 7.0, 11.0, 15.0 and 19.0. From the release and end of life dates on Forgejo's schedule page, a stable release lives about three months and an LTS release about 15 months. Forgejo 15.0 LTS, released on 16 April 2026, reaches end of life on 15 July 2027. Forgejo 16.0 reaches end of life on 29 October 2026, six days after this post's date, and 17.0 on 28 January 2027.

So a Forgejo admin who runs 16.0 today has a hard upgrade date next week, and an admin who wants fewer upgrades has a clear option in the LTS line. The schedule page does not spell out what security coverage applies before end of life, so treat the end of life date as the latest date you can expect fixes, not as a promise of backports for every issue.

What does Harbor's advisory history show?

Harbor is the Cloud Native Computing Foundation registry that many teams run as their private image store. Its GitHub advisory list held 41 advisories on 23 October 2026: four full pages of ten and one advisory on page five. That oldest advisory is GHSA-fqvr-xx6w-m6m7, CVE-2019-16097, rated high and published on 19 September 2019. It concerned self registration that could grant elevated rights.

The list shows clusters rather than a steady drip:

Source: goharbor/harbor GitHub security advisories, pages 1, 2, 3 and 5, fetched 23 October 2026. We did not fetch page 4, so ten advisories published between 2019 and August 2022 are not broken out here; the table covers 31 of the 41.

We cover the 6 October 2026 batch in detail in Harbor's October 2026 advisories.

Harbor's security policy says it maintains release branches for the three most recent minor releases and may backport security fixes to them depending on severity and feasibility. For critical issues with a straightforward mitigation, it expects about 14 business days from report to public disclosure.

The CVE-2026-4404 dispute

CVE-2026-4404 is a useful example of why "what the advisory says" can depend on whose advisory you read.

• The NVD record, published on 23 March 2026 and marked analyzed, describes hard coded default credentials in Harbor 2.15.0 and below, carries a CVSS 3.1 score of 9.4 from the assigning organization, and cites a CERT/CC vulnerability note.
• Harbor's maintainers published GHSA-56j8-6qr5-cg75 on 7 April 2026, rated it low, and said the CVE had not been acknowledged as a valid Harbor vulnerability. Their position is that harbor.yml.tmpl is a sample, that operators generate their own harbor.yml and set their own admin password, and that they are requesting rejection of the CVE.
• Belgium's national cyber security centre published a "patch immediately" warning about it, according to our planning notes. That page returned an error to our fetch, so we did not use its text.

The practical reading is the same either way. If a Harbor admin password was never changed from the sample value, that installation is exposed regardless of how the CVE is scored, and the fix is a configuration change, not an upgrade. Our Harbor configuration guide covers the settings to check.

Which self-hosted products reached end of support, and which are excepted?

Atlassian Server and Data Center

Atlassian's Server products, including Bitbucket Server, reached end of support on 15 February 2024. Atlassian's page states that support and bug fixes are no longer available for Server products and apps. Fisheye and Crucible follow a later date, 15 May 2028.

Atlassian's Data Center end of life is set for 28 March 2029. New Data Center subscriptions closed to new customers on 30 March 2026, and existing customers can buy expansions and upgrades until 30 March 2028. The products affected are Jira Software, Jira Service Management, Confluence and Crowd Data Center and their apps. Bitbucket Data Center and Bamboo Data Center are not affected and continue beyond 2029; existing customers can move to a Bitbucket Hybrid License that covers Bitbucket Data Center, Bamboo Data Center and Bitbucket Cloud.

Within that, each Bitbucket Data Center release has its own clock. Atlassian supports each feature or LTS release for two years. On 23 October 2026, Atlassian's end of life policy page listed Bitbucket 9.0 ending support on 23 July 2026 (already past), 9.3 on 29 October 2026, 9.4 LTS on 3 December 2026, 10.2 LTS on 3 March 2028 and 10.4 on 21 July 2028.

Bitbucket Data Center also has a 2026 KEV entry by way of a shared flaw. CVE-2026-21589, an arbitrary file access flaw that the NVD record lists across Bitbucket, Confluence, Jira, Bamboo and Crowd Data Center plus Fisheye and Crucible, was added to KEV on 15 October 2026 with a due date of 18 October 2026. NVD scores it 7.5 under CVSS 3.1; Atlassian scores it 9.3 under CVSS 4.0. For Bitbucket Data Center, the record lists fixes in 9.4.26, 10.2.8 and 10.5.1. Note that 9.4.26 sits on the 9.4 LTS line, whose support ends on 3 December 2026.

AWS CodeCommit: closed, then reopened

AWS CodeCommit is a hosted service, not self-hosted software, but it belongs in this discussion because many teams moved off it to a self-hosted server. AWS's documentation history records that CodeCommit stopped accepting new customers on 25 July 2024 and became available to new customers again on 25 November 2025. Existing customers could keep using it throughout. InfoQ reported on 7 December 2025 that AWS cited customer feedback, planned Git LFS support for early 2026, and said the service ran in 29 regions.

For teams that migrated to a self-hosted Git server during the closure, the security consequence is that they took on patching work a managed service used to do for them. The GitLab and Gitea data above is what that work looks like.

Data table: documented security support windows per self-hosted product

The windows are not comparable as a quality measure. A three month window with monthly releases and a two year window with large upgrades ask different things of a team. They are comparable as a planning input: the window tells you the longest you can stay on one version and still expect security fixes.

Which self-hosted SCM and registry CVEs are in CISA KEV?

We read the CISA KEV catalog JSON (catalog version 2026.10.21, 1,754 entries, released 21 October 2026) and CISA's 1 May 2024 alert. Our read of the JSON covered the most recent entries; older entries were checked only where a CISA alert or NVD record confirmed them.

Sources: CISA alert of 1 May 2024; CISA KEV JSON catalog 2026.10.21; NVD API records for CVE-2026-85706 and CVE-2026-21589; SecurityWeek for the 22 May 2024 due date. In the portion of the catalog we read, there were no entries naming Gitea, Forgejo, Harbor, Quay or GitHub Enterprise Server as the product.

Two things stand out. First, KEV due dates for these products have shortened. The 2024 GitLab entry had the usual 21 days; both 2026 SCM entries had three. Second, a product's absence from KEV says only that CISA has not confirmed exploitation, not that the product is safe to leave unpatched. Harbor's 6 October 2026 batch and Gitea's October advisories were not in KEV when we checked.

How we measured

Exposure data. Shadowserver's scans fingerprint internet reachable HTTP services and infer vulnerable versions for specific CVEs. We could not fetch Shadowserver's own post or dashboard, so every Shadowserver number here comes through three news reports that quote it: BleepingComputer (24 January 2024), SecurityWeek (2 May 2024) and The Register (2 May 2024). Each outlet read the dashboard on a different day and may have used different filters or IP versions. These counts measure internet reachable instances that look vulnerable. They do not measure installs, users, or organizations, and an instance that leaves the count was not necessarily patched.

Support windows. Taken from each project's own policy page on 23 October 2026: GitLab's maintenance policy, GitHub's Enterprise Server releases page, Atlassian's end of life policy and Data Center end of life page, Gitea's and Harbor's SECURITY.md files, and Forgejo's release schedule. Where a page gave dates but no stated duration, we computed the duration from the dates and say so.

Advisory counts. Counted from GitHub security advisory pages for goharbor/harbor and go-gitea/gitea on 23 October 2026. Harbor's 41 is exact (four pages of ten plus one). Gitea's list spanned 16 pages; we did not count every page, so we give the page count rather than a total. We did not use any third party CVE totals.

KEV. CISA's JSON feed, catalog version 2026.10.21, plus the CISA alert for 1 May 2024 and NVD API records for the 2026 entries. Our read of the JSON covered the newest portion of a 1.8 million character file, so older entries for these products may exist that we did not see. The command in the walkthrough below runs the full check locally.

Why the numbers cannot be combined. A Shadowserver count (reachable instances), an advisory count (published advisories, of any severity), a KEV entry (confirmed exploitation) and a support window (a vendor promise) measure four different things. We never add, average or rank across them. The one ranked table orders a single series, GitLab exposure snapshots, by its own count.

Step by step: find your version, compare it with the window, and watch KEV

This walkthrough checks each self-hosted server's version over its own API, compares it with the vendor's supported range, and alerts on KEV entries for the products you run. Replace the hostnames and tokens with your own. None of these commands change the server.

1. Read each server's version

# GitLab self-managed (needs a token with read_api)
curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  https://gitlab.example.com/api/v4/version
# or, with the GitLab CLI already authenticated to that host
glab api version --hostname gitlab.example.com

# On the GitLab host itself
sudo gitlab-rake gitlab:env:info | grep -i "GitLab information" -A3

# Gitea and Forgejo share this endpoint
curl -s https://git.example.com/api/v1/version

# GitHub Enterprise Server
curl -s https://ghes.example.com/api/v3/meta | jq -r .installed_version

# Bitbucket Data Center
curl -s https://bitbucket.example.com/rest/api/1.0/application-properties | jq -r .version

# Harbor (needs credentials)
curl -s -u "$HARBOR_USER:$HARBOR_PASS" \
  https://harbor.example.com/api/v2.0/systeminfo | jq -r .harbor_version

2. Compare with the supported range

Keep a small file in a repository that records the oldest version you accept for each product, based on the vendor's window. For GitLab, that is the oldest of the three monthly releases currently listed for security fixes. For Bitbucket Data Center, it is any release whose end of support date is in the future, and for Forgejo, any release before its end of life date.

# supported-min.yaml, updated when a vendor publishes a new release
gitlab: "19.3.0"
forgejo: "15.0.0"      # LTS line; 16.0 ends 29 Oct 2026
bitbucket: "9.4.0"     # 9.4 LTS support ends 3 Dec 2026
harbor: "2.14.0"       # example only; set to your oldest of three supported minors

3. Check KEV for the products you run

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[]
      | select((.vendorProject + " " + .product + " " + .shortDescription)
               | test("GitLab|Gitea|Forgejo|Harbor|Bitbucket|GitHub Enterprise"; "i"))
      | [.dateAdded, .dueDate, .cveID, .vendorProject, .product] | @tsv' \
  | sort -r

The match on shortDescription matters. CVE-2026-21589 lists Atlassian "Multiple Products" in the product field, and only the description names Bitbucket Data Center.

4. Run it on a schedule

A scheduled GitLab CI job, for example, can run the version check and the KEV query each morning and fail if a server is under the minimum or a new KEV entry appeared since the last run.

# .gitlab-ci.yml
check-self-hosted-versions:
  image: alpine:3.20
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
  before_script:
    - apk add --no-cache curl jq
  script:
    - ./scripts/check-versions.sh supported-min.yaml
    - ./scripts/check-kev.sh --since "$(cat .kev-last-run 2>/dev/null || echo 2024-01-01)"

The same two scripts run under a GitHub Actions schedule trigger, an Azure Pipelines scheduled trigger or a Bitbucket Pipelines schedule with no changes beyond the wrapper.

5. After a critical patch, do the follow up the advisory asks for

GitLab's CVE-2023-7028 notes asked admins to review two log files, turn on two factor authentication and rotate secrets on suspicion of compromise. Harbor's CVE-2026-4404 discussion comes down to confirming the admin password is not the sample value. Put the advisory's follow up steps in the same ticket as the upgrade, so the ticket cannot close on the upgrade alone.

What patching SLAs fit internet exposed SCM and registry servers?

The data gives a few anchors rather than one right answer.

• KEV listed flaws. The two 2026 SCM entries came with three day federal due dates. If an internet reachable server runs a product with a fresh KEV entry, three days is the pace CISA set for federal agencies, and it is a reasonable ceiling for anyone.
• Critical, not yet in KEV. CVE-2023-7028 went from patch to KEV in 16 weeks. During those weeks thousands of servers sat exposed. A seven day target for critical fixes on internet reachable servers keeps you well ahead of that curve.
• Everything else. Stay inside the vendor's support window. For GitLab, that means at least one upgrade per quarter to a current release. For Forgejo stable, the same; for Forgejo LTS, GitHub Enterprise Server or Bitbucket Data Center, a planned annual upgrade plus patch releases in between.
• Not reachable from the internet. Internal servers are not in the scan counts, but they are reachable by anyone already inside the network, and their vendors do not change the support window for them. Use the same window, with a longer deadline for non critical fixes if you must.

The biggest variable is the inventory. Teams that cannot list every self-hosted Git server and registry they run, with its version, will miss one. Our guide to answering "which systems are affected" quickly applies to servers as much as to applications.

Where do sources disagree on counts and dates?

• GitLab January count: 5,379 on 23 January 2024 (BleepingComputer) against 4,652 "at disclosure" (The Register).
• GitLab May count: about 1,400 on 1 May 2024 (SecurityWeek) against 2,149 (The Register, 2 May 2024).
• CVE-2023-7028 severity: 10.0 from GitLab against 7.5 from NVD, as reported by The Register.
• CVE-2023-7028 16.4 fix: 16.4.4 (BleepingComputer) against 16.4.5 (GitLab).
• CVE-2026-21589 severity: 7.5 under CVSS 3.1 from NVD against 9.3 under CVSS 4.0 from Atlassian.
• CVE-2026-4404 validity and severity: 9.4 from the assigning organization in NVD, "Low" and a rejection request from Harbor's maintainers. NVD gives a publication date of 23 March 2026; Harbor's advisory is dated 7 April 2026, which our planning notes had recorded as the CVE's publication date.
• CodeCommit reopening date: AWS's documentation history says 25 November 2025; our planning notes had both 24 and 25 November from secondary coverage. We use AWS's date.

Common mistakes

Reading scan counts as install counts. A Shadowserver number is a floor for exposed, fingerprintable servers, not a measure of how many organizations run a product. Most installs are internal and invisible to scans.

Reading a falling count as a patching rate. Servers leave the vulnerable count when they are shut down, firewalled or renumbered, too. The May 2024 GitLab figures are an upper bound on patching, not a measure of it.

Quoting one number without its source. Two outlets reported May 2024 GitLab figures 750 apart. Always give the date and who reported it.

Assuming "not in KEV" means "not urgent". KEV records confirmed exploitation. Harbor's 13 advisories of 6 October 2026 were not in KEV when we checked, and five were rated high.

Treating a disputed CVE as a non issue. CVE-2026-4404's validity is disputed, but the configuration risk it names is real if the default password was never changed. Check the configuration, then follow the dispute.

Tracking only the product version. Gitea's 1.23.6 and 1.25.3 security releases were mostly dependency and Go toolchain fixes. A version check catches the release; it does not tell you which of the fixes apply.

Staying on a release after its window closes. Bitbucket 9.0 left support on 23 July 2026 and 9.3 leaves on 29 October 2026. Forgejo 16.0 reaches end of life the same week. An upgrade that slips by a month can take a server out of the support window.

FAQ

How many self-hosted GitLab servers are exposed to the internet?

There is no current public total. The most detailed public figures are for vulnerable instances in a single case: Shadowserver counted 5,379 GitLab instances exposed to CVE-2023-7028 on 23 January 2024, as reported by BleepingComputer. Those counts cover only fingerprintable, internet reachable servers.

How long did it take GitLab servers to patch CVE-2023-7028?

GitLab shipped the fix on 11 January 2024. By 1 May 2024, about 1,400 exposed instances still looked vulnerable according to SecurityWeek, or 2,149 according to The Register. That is roughly a quarter to a half of the January counts, depending on the pair of figures used.

How long does GitLab support a self-managed version with security fixes?

GitLab backports security fixes to the current stable release and the two previous monthly releases, which is about three months for any one minor version. Some fixes are not backported at all, according to its maintenance policy.

Is Bitbucket Data Center being discontinued in 2029?

No. Atlassian's Data Center end of life on 28 March 2029 covers Jira, Jira Service Management, Confluence and Crowd Data Center. Bitbucket Data Center and Bamboo Data Center are excepted and continue beyond 2029. Each Bitbucket release still has its own two year support window.

When did Bitbucket Server lose support?

Atlassian Server products, including Bitbucket Server, reached end of support on 15 February 2024, according to Atlassian's server end of support page.

Is CVE-2026-4404 in Harbor a real vulnerability?

It is disputed. NVD lists it with a 9.4 score from its assigner. Harbor's maintainers rate it low and have requested rejection, arguing that the default password is in a sample file that operators replace. Either way, confirm your Harbor admin password is not the sample value.

Which Git server CVEs are in the CISA KEV catalog?

In our 23 October 2026 check: GitLab CVE-2023-7028 (added 1 May 2024) and CVE-2026-85706 (added 11 September 2026), and Atlassian CVE-2026-21589, which affects Bitbucket Data Center among other products (added 15 October 2026). Run the jq query above against the live feed for a full list.

How often does Forgejo release, and what is its LTS?

Forgejo ships a stable release every quarter, and every fourth release is LTS. Stable releases reach end of life after about three months; LTS releases after about 15 months. Forgejo 15.0 LTS reaches end of life on 15 July 2027.

Fix it without waiting for upstream

A self-hosted Git server or registry is infrastructure you run, and its own fixes have to come from its vendor or project. What you can control directly is what lives inside it: the open source dependencies in the repositories it hosts and the container images it stores. That is where the steps below apply.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

For self-hosted servers specifically, Safeguard connects to repositories on GitHub, GitLab (cloud or self-managed) and Bitbucket, plus any Git compatible repository, and scans container images by name with safeguard scan --image <name>. The GitLab connection guide and Bitbucket connection guide show the setup. Safeguard does not patch the GitLab, Gitea, Forgejo, Bitbucket or Harbor server software itself; that upgrade stays with your platform team and the vendor's release. You can download the apps at https://safeguard.sh/download and read the CLI docs at https://docs.safeguard.sh/docs/cli .

See how Safeguard would help

The first demo is a real Safeguard CLI session. It reads a finding and its advisory, asks before each command, updates a vulnerable dependency, runs the install and tests with your approval and pushes nothing. The same flow applies to the repositories your self-hosted GitLab or Gitea server holds: the server patch is the vendor's job, and the dependencies inside those repositories are yours.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code, and scans from the terminal. Teams that keep code on internal Git servers or images in an internal Harbor can use a runner inside their network so scans run where the code and images already live.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask which projects contain a given component and version, which is the same question you face after a new KEV entry for a library inside your repositories.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• BleepingComputer: Over 5,300 GitLab servers exposed to zero-click account takeover attacks (24 Jan 2024)
• SecurityWeek: 1,400 GitLab servers impacted by exploited vulnerability (2 May 2024)
• The Register: Critical GitLab vulnerability (2 May 2024)
• GitLab: Patch release 16.7.2 (11 Jan 2024)
• GitLab: Maintenance policy
• CISA: CISA adds one known exploited vulnerability to catalog (1 May 2024)
• CISA KEV catalog JSON (catalog version 2026.10.21)
• CISA Known Exploited Vulnerabilities catalog
• NVD API: CVE-2026-85706
• NVD API: CVE-2026-21589
• NVD API: CVE-2026-4404
• Harbor: GitHub security advisories
• Harbor: GHSA-56j8-6qr5-cg75, About CVE-2026-4404
• Harbor: SECURITY.md
• Gitea: GitHub security advisories
• Gitea: SECURITY.md
• Gitea: Release of 1.23.6 (24 Mar 2025)
• Gitea: Release of 1.25.3 (18 Dec 2025)
• Forgejo: Release schedule
• GitHub Docs: GitHub Enterprise Server releases
• Atlassian: Data Center end of life
• Atlassian: Server end of support
• Atlassian: Support end of life policy
• AWS: CodeCommit user guide document history
• InfoQ: AWS CodeCommit returns to general availability (7 Dec 2025)

Last reviewed: 23 October 2026. Exposure counts and advisory lists change often; check the linked advisories and the KEV catalog for the latest status.