Overview 2,733 matches · 384 in Waratek scope · 21 protected · 37 exploited · 14 CISA KEV · 132 public PoC · 55 EPSS ≥ 0.5
2,733matches
384in Waratek scope14.1%
21protected0.8%
37exploited1.4%
14CISA KEV0.5%
132public PoC4.8%
55EPSS ≥ 0.52.0%
Protected by Waratek
21
0.8%
Rule in development
1
0.0%
Mitigation candidate
12
0.4%
No exploit published
350
12.8%
Outside Waratek scope
6
0.2%
Not applicable
2,343
85.7%
Withdrawn CVE
0
0.0%
blocked by ARMR today
21
0.8%
partly blocked
0
0.0%
not blocked
2,712
99.2%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 423 / year
19981
Not applicable1
High1
not blocked1
No public exploit1
19990
20000
20011
Not applicable1
High1
not blocked1
No public exploit1
20024
Not applicable4
Medium3
Low1
not blocked4
Working exploit published1
No public exploit3
20031
Not applicable1
High1
not blocked1
Working exploit published1
20041
Not applicable1
High1
not blocked1
Working exploit published1
20057
Not applicable7
High3
Medium4
not blocked7
Working exploit published2
No public exploit5
20067
Not applicable7
High4
Medium3
not blocked7
Working exploit published4
No public exploit3
200712
Not applicable12
High7
Medium5
not blocked12
Exploited1
Working exploit published6
No public exploit5
200812
Not applicable12
High7
Medium5
not blocked12
Working exploit published7
No public exploit5
200917
Not applicable17
High7
Medium10
not blocked17
Working exploit published9
No public exploit8
201012
Not applicable12
High7
Medium5
not blocked12
Working exploit published5
No public exploit7
201110
Not applicable10
High4
Medium3
Low3
not blocked10
Working exploit published4
No public exploit6
20127
Not applicable7
High2
Medium5
not blocked7
No public exploit7
20136
Not applicable6
High1
Medium5
not blocked6
No public exploit6
201419
Not applicable19
High5
Medium14
not blocked19
Working exploit published5
No public exploit14
201522
Not applicable22
High5
Medium16
Low1
not blocked22
Working exploit published6
No public exploit16
201624
Not applicable24
Critical16
High4
Medium2
Low2
not blocked24
Working exploit published1
No public exploit23
201768
Protected by Waratek1
No exploit published4
Not applicable63
Critical15
High32
Medium20
Low1
blocked by ARMR today1
not blocked67
Exploited1
Working exploit published4
No public exploit63
2018109
Mitigation candidate1
No exploit published9
Not applicable99
Critical24
High40
Medium45
not blocked109
Exploited2
Working exploit published3
Proof of concept only1
Forecast only1
No public exploit102
2019251
Protected by Waratek2
No exploit published16
Outside Waratek scope1
Not applicable232
Critical24
High63
Medium158
Low6
blocked by ARMR today2
not blocked249
Exploited3
Working exploit published5
Proof of concept only1
No public exploit242
2020322
Protected by Waratek2
Mitigation candidate5
No exploit published21
Outside Waratek scope1
Not applicable293
Critical36
High102
Medium178
Low6
blocked by ARMR today2
not blocked320
Exploited4
Working exploit published6
Proof of concept only3
Forecast only1
No public exploit308
2021241
Protected by Waratek3
No exploit published32
Outside Waratek scope1
Not applicable205
Critical18
High67
Medium145
Low11
blocked by ARMR today3
not blocked238
Exploited4
Working exploit published2
Proof of concept only1
Forecast only3
No public exploit231
2022269
Protected by Waratek6
Mitigation candidate2
No exploit published40
Not applicable221
Critical35
High72
Medium155
Low7
blocked by ARMR today6
not blocked263
Exploited2
Working exploit published11
Proof of concept only27
Forecast only3
No public exploit226
2023274
Protected by Waratek1
Mitigation candidate1
No exploit published31
Outside Waratek scope1
Not applicable240
Critical31
High81
Medium154
Low8
blocked by ARMR today1
not blocked273
Exploited7
Working exploit published3
Proof of concept only112
Forecast only4
No public exploit148
2024232
Protected by Waratek1
Mitigation candidate1
No exploit published46
Not applicable184
Critical31
High64
Medium128
Low9
blocked by ARMR today1
not blocked231
Exploited4
Proof of concept only15
Forecast only1
No public exploit212
2025381
Protected by Waratek4
Rule in development1
Mitigation candidate2
No exploit published140
Not applicable234
Critical10
High112
Medium242
Low17
blocked by ARMR today4
not blocked377
Exploited2
Working exploit published3
Proof of concept only28
No public exploit348
2026423
Protected by Waratek1
No exploit published11
Outside Waratek scope2
Not applicable409
Critical33
High176
Medium183
Low31
blocked by ARMR today1
not blocked422
Exploited7
Proof of concept only64
No public exploit352
1999200220052008201120142017202020232026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-16255 | High | 2026-10-22 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 12.0 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, when the instance-wide SAML or LDAP membership lock was enabled, an authenticated user could have granted or accepted project and group membership outside the identity provider's control, due to incomplete enforcement of the membership lock on requests created before the lock was enabled. |
| CVE-2026-15723 | High | 2026-10-22 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 10.1 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, when OmniAuth SAML and LDAP auto-linking were both enabled, an authenticated user could have taken over an existing LDAP-backed account without any interaction from the targeted user, due to improper input sanitization in the LDAP email lookup path used during OmniAuth identity linking. |
| CVE-2026-14288 | Low | 2026-10-22 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 17.4 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that under certain conditions could have allowed an authenticated to bypass a required merge request approval policy on a protected branch due to improper access control during approval rule synchronization. |
| CVE-2026-13319 | Medium | 2026-10-22 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.10 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, could have allowed an authenticated to read milestone metadata, including titles, descriptions, and full project paths, from arbitrary private projects across the instance without any project membership, due to missing authorization checks on a user-supplied project filter parameter in the group milestones API. |
| CVE-2026-12664 | Medium | 2026-10-22 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.2 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, could have allowed an authenticated user with a read_api-scoped token to retrieve a project's incoming email address and create work items, bypassing the token's restrictions, due to insufficient scope enforcement on a GraphQL field. |
| CVE-2026-112378 | Medium | 2026-10-22 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 17.8 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that under certain conditions could have allowed an authenticated user to access paid AI features without a valid subscription due to insufficient server-side validation in billing eligibility checks. |
| CVE-2026-112326 | Low | 2026-10-22 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 17.8 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, could have allowed an authenticated user with read-only permissions to permanently delete existing vulnerability records due to improper cleanup logic that failed to distinguish between pre-existing records from newly created ones during error handling. |
| CVE-2026-112212 | High | 2026-10-22 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.3 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, an unauthenticated user could have poisoned a shared cache's OAuth/OIDC discovery document to redirect certain flows to an externally controlled server, due to improper trust of user-supplied values when constructing endpoint URLs in cached discovery responses. |
| CVE-2026-111497 | Critical | 2026-10-22 | Outside Waratek scope | Exploited | A buffer overflow vulnerability in the Brotli decoder (c/dec/decode.c) in Google Brotli versions 1.0.3 through 1.2.0 on all platforms allows a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code using a crafted Brotli-compressed stream. Users need to update any Brotli libraries or binaries between 1.0.3 through 1.2.0 to the latest available version: 1.0.10 or 1.1.1 or 1.2.1. |
| CVE-2026-110264 | Critical | 2026-10-22 | Not applicable | No public exploit | An issue has been discovered in GitLab CE/EE affecting all versions from 7.0 before 18.11.13, 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to integer overflow when compiling a specially crafted regular expression. |
| CVE-2026-105777 | Medium | 2026-10-22 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.6.5 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, an unauthenticated user could have retrieved sensitive internal server credentials due to improper filtering of internal response headers. |
| CVE-2026-105711 | Low | 2026-10-22 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.0 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, when a merge request in a public project referenced a confidential issue from a private project, an authenticated user with no project membership could have read the confidential issue's title, due to a viewer-independent fragment cache key that incorrectly shared per-user-redacted rendered content across all users. |
| CVE-2026-103515 | Low | 2026-10-22 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 19.2 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, when an instance administrator locked a group's Duo availability, an authenticated user with group Owner permissions could have re-enabled AI-backed data egress to a third-party service for that group and its descendant projects, due to insufficient granularity of the admin-lock enforcement controls. |
| CVE-2026-97229 | Critical | 2026-10-13 | Not applicable | Exploited | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration, due to insufficient regular expression validation. |
| CVE-2026-96893 | High | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 19.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user to inject specially crafted content into AI agent instructions, potentially causing unintended command execution attributed to other users, due to improper neutralization of special elements in AI conversation context construction. |
| CVE-2026-92883 | High | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user to execute arbitrary JavaScript in the context of other users' browser sessions via a specially crafted repository, due to improper sanitization of HTML attributes in syntax-highlighted output. |
| CVE-2026-9268 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 13.6 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with limited permissions to modify project CI/CD deployment rollback settings without proper authorization, due to insufficient access control checks. |
| CVE-2026-92528 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 16.11 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user to approve a merge request despite having contributed commits to it, due to improper identity resolution. |
| CVE-2026-85529 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an unauthenticated user to read internal notes and confidential system notes on public projects due to improper authorization in the GraphQL API. |
| CVE-2026-84284 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.11 before 19.2.8, 19.3 before 19.3.6, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an unauthenticated user to read work item contents from private groups and projects due to incorrect authorization checks. |
| CVE-2026-82632 | Low | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.9 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with a fine-grained Personal Access Token scoped only to user-boundary import permissions to import projects into group namespaces beyond the token's intended scope, due to incorrect authorization of the import target namespace. |
| CVE-2026-81839 | High | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 18.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user to execute arbitrary CI/CD pipelines in a transferred project with the new group's privileges due to improper cleanup of scheduled pipeline execution policy records. |
| CVE-2026-78335 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user holding a project-scoped fine-grained Personal Access Token to modify integrations belonging to a group outside the token's scope, due to incorrect authorization checks. |
| CVE-2026-7767 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.11 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user controlling a Kubernetes agent to cause sensitive authentication tokens to be sent to an unintended server due to improper redirect validation in the Kubernetes proxy. |
| CVE-2026-6567 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.8 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with reporter role to access restricted CI artifact report content they were not authorized to, due to missing authorization checks. |
| CVE-2026-5954 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed a user to download package files from a public project due to improper authorization checks. |
| CVE-2026-16301 | High | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.7 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with Developer role to execute CI/CD pipelines on protected branches without authorization due to improper authorization checks in the downstream pipeline creation service. |
| CVE-2026-16275 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.4 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an unauthenticated user to read confidential notes on public projects due to incorrect authorization checks. |
| CVE-2026-14814 | High | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed a user to poison cached responses for raw repository files, causing targeted users' CI/CD pipelines to execute specially crafted content and potentially exposing protected environment variables, due to improper validation of repository references. |
| CVE-2026-14552 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.0 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with Guest access to read confidential epic content meant to be restricted by external authorization, due to incorrect authorization checks. |
| CVE-2026-14210 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.11 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with a project-scoped fine-grained Personal Access Token to permanently delete or modify group-level labels, due to incorrect authorization logic on label ownership scope validation. |
| CVE-2026-105458 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 19.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user holding a specific granular permission to obtain a GitLab Duo Agent Platform token that bypasses governance controls, due to reliance on untrusted input in a security decision. |
| CVE-2026-104661 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 17.0 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user holding a custom role with compliance framework administration permissions to configure and execute a specially crafted compliance pipeline across group projects due to improper privilege assignment. |
| CVE-2026-103549 | Low | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.6 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with maintainer-role permissions to remove certain package registry metadata that package protection rules restrict to higher roles, due to improper authorization checks. |
| CVE-2026-101168 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 12.0 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with access to GitLab Pages log data to obtain access tokens and other secrets, due to insertion of sensitive request data into log files and error tracking events. |
| CVE-2026-100755 | Medium | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 16.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain deployment configurations, could have allowed an authenticated user to poison cached page content served to other users due to improper cache key construction. |
| CVE-2026-100104 | Low | 2026-10-13 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 10.3 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user to perform server-side request forgery and reach internal network resources due to a time-of-check to time-of-use race condition in URL validation during repository import operations. |
| CVE-2026-97208 | Medium | 2026-10-06 | Not applicable | No public exploit | The Gitea API endpoint for creating push mirrors (`POST /api/v1/repos/{owner}/{repo}/push_mirrors`) checked only whether mirroring was enabled and not the `[mirror] DISABLE_NEW_PUSH` setting that the web interface enforces. A repository administrator could therefore create new push mirrors on instances where the site administrator had disabled them. A push mirror pushes all refs of the repository to a remote chosen by the caller, on each commit or on a schedule. |
| CVE-2026-96594 | Medium | 2026-10-06 | Not applicable | No public exploit | The Gitea API endpoint `GET /api/v1/repos/{owner}/{repo}/media/{filepath}` wrote files of up to 1 KiB that are stored directly in Git, not in LFS, to the response without the content type and disposition headers Gitea uses for user content. An HTML file committed to a repository was therefore rendered by the browser on the Gitea origin. A user who can push to a repository could run JavaScript in the session of a victim who opens the media URL and act with the victim's permissions. |
| CVE-2026-96589 | Medium | 2026-10-06 | Not applicable | No public exploit | When a private repository is transferred to a user who lacks access, Gitea grants that recipient temporary read access as a collaborator so they can review the repository. Rejecting or cancelling the transfer did not revoke this collaboration, so the named recipient kept persistent read access to the private repository, including its code, issues, pull requests and wiki, and could clone it. The repository owner was not notified. Transfer-granted access is now removed while collaborations that existed before the transfer are preserved. |
| CVE-2026-96580 | High | 2026-10-06 | Not applicable | No public exploit | Gitea expanded a workflow's static `strategy.matrix` into its full Cartesian product without a size limit when creating a run, before the fork pull request approval gate applied. A user who can open a pull request from a fork could submit a small workflow file whose matrix expands to a very large number of jobs, consuming server memory and potentially terminating the Gitea process. No runner is required. Static matrices above 256 combinations are now rejected before expansion. |
| CVE-2026-96404 | High | 2026-10-06 | Not applicable | No public exploit | When Gitea's web installer is reachable against a database that already contains users, such as after `INSTALL_LOCK` has been reset to `false`, submitting the install form with an administrator username matching an existing account issued an authenticated session for that account without verifying its password. If the account is an administrator, the session grants full administrative access, including changing the account's password. Databases with a single user also did not require the reinstall confirmation. |
| CVE-2026-96400 | Medium | 2026-10-06 | Not applicable | No public exploit | With `[migrations] ALLOWED_DOMAINS` set to a matching entry such as `*` or a hostname wildcard, Gitea's migration URL validation could permit reserved and link-local addresses, such as `169.254.169.254`, even when `ALLOW_LOCALNETWORKS = false`. The local-network block list did not cover these ranges, and a hostname matching the allow list was accepted regardless of its resolved address. A user who can start migrations on such an instance could reach these addresses from the Gitea server; the default empty `ALLOWED_DOMAINS` configuration is not affected. |
| CVE-2026-96399 | High | 2026-10-06 | Not applicable | No public exploit | A repository's external issue tracker regular expression containing alternating capture groups could produce invalid slice indexes when Gitea rendered issue references, causing a runtime panic that terminated the Gitea process. A user who can edit a repository's external issue tracker settings could make any later rendering of matching content, such as viewing a README, crash the instance for all users. |
| CVE-2026-95112 | Medium | 2026-10-06 | Not applicable | No public exploit | When processing issue and comment bodies, Gitea scanned the entire preceding text for action keywords such as "closes" or "fixes" once per Markdown link, giving processing time quadratic in the input size. An authenticated user able to submit issue or comment content could send a crafted body of about 1 MB that keeps a CPU core busy for several minutes while holding a database transaction open. |
| CVE-2026-95106 | Critical | 2026-10-06 | Not applicable | No public exploit | Gitea accepted pushed Git trees containing two entries with the same name, which Git's own consistency checks reject. Gitea's web views resolved such a path to the first entry, while `git checkout`, Gitea Actions, and release archives use the last. A contributor could open a pull request whose diff and file views show benign content while CI and checkouts at the same commit use different, attacker-controlled content. Incoming objects are now checked for consistency; objects already stored in existing repositories are not rescanned. |
| CVE-2026-94205 | Critical | 2026-10-06 | Not applicable | No public exploit | Gitea Actions decided whether a fork pull request run needed approval based on the user who triggered the event rather than the pull request author. For `pull_request` activity triggered by a maintainer during ordinary triage, such as adding a label, the run was created without requiring approval, while the workflow definition was still taken from the fork head. Where Actions is enabled and a matching runner is registered, fork-controlled workflow code could run on the base repository's runners without an explicit approval. |
| CVE-2026-89430 | High | 2026-10-06 | Not applicable | No public exploit | Gitea validated a push mirror's remote address against the `[migrations]` allow and block lists only when the mirror was created. Each synchronization passed the stored address directly to `git push`, so a name that later resolved to a blocked or internal address was still reached. A user with administrator access to a repository, which includes repositories they create themselves, could aim push mirror synchronization at internal Git services and force-push the repository's contents to them. |
| CVE-2026-89182 | Medium | 2026-10-06 | Not applicable | Proof of concept only | With `[repository] FORCE_PRIVATE = true`, Gitea creates new repositories as private, but the post-receive hook still applied the `repo.private=false` push option to an empty repository created by push. Any user who can create repositories could make their new repository public in violation of the instance policy. The default configuration is not affected. |
| CVE-2026-86684 | High | 2026-10-06 | Not applicable | No public exploit | The Gitea push mirror API checked whether the repository owner, instead of the requesting user, may use local file system paths. On instances with `[security] IMPORT_LOCAL_PATHS = true`, a repository administrator who is not allowed to import local paths could add a push mirror to a local path on the server when the repository owner has that permission. Gitea then pushed the repository's refs into an existing Git repository at that path with the permissions of the Gitea process. |
| CVE-2026-79960 | High | 2026-10-06 | Not applicable | No public exploit | When a push was authenticated with a deploy key, Gitea recorded the repository owner as the pusher, so permission checks in the push hook pipeline evaluated the owner instead of the deploy key. A holder of a writable deploy key could create protected tags without being on the tag allow list and change repository visibility through push options, for example making a private repository public. Pull requests created through the AGit flow with a deploy key were also attributed to the owner. |
| CVE-2026-73278 | Critical | 2026-10-06 | Not applicable | No public exploit | Gitea's OAuth2 and OpenID Connect sign-in paths do not require a WebAuthn challenge when WebAuthn is the account's only configured second factor. A party able to authenticate through the affected external identity flow can obtain a full session without the passkey verification enforced during password login. One affected path can also persist an external identity link, extending the compromise beyond the initial session; accounts with TOTP configured are outside the reported WebAuthn-only scenario. |
| CVE-2026-70357 | High | 2026-10-06 | Not applicable | No public exploit | Gitea validates a repository migration hostname against its network allow and block lists before invoking Git, but the Git subprocess independently resolves the hostname when connecting. An attacker who can start a migration and control the destination's DNS can change the address between validation and connection to reach a blocked internal address. The affected path is the Git clone operation; validation in the migration HTTP client's dialer does not protect the independently connecting Git subprocess. |
| CVE-2026-57554 | High | 2026-10-06 | Not applicable | No public exploit | Memory Corruption when asynchronous threads access shared performance counter data simultaneously during FastRPC invocations. |
| CVE-2026-57545 | High | 2026-10-06 | Not applicable | No public exploit | Memory corruption when processing draw objects of incorrect type during graphics command list execution. |
| CVE-2026-25302 | High | 2026-10-06 | Not applicable | No public exploit | Cryptographic Issue when processing non-ELF partitions, authentication and signature checks are bypassed, allowing unsigned or corrupted images to be mounted and processed. |
| CVE-2026-25291 | High | 2026-10-06 | Not applicable | No public exploit | Memory corruption when performing concurrent operations on shared memory page lists due to lack of proper synchronization mechanisms. |
| CVE-2026-25272 | Medium | 2026-10-06 | Not applicable | No public exploit | Memory Corruption when processing camera CRE driver operations with improper handling of buffer limits during hardware update preparation. |
| CVE-2026-25270 | Medium | 2026-10-06 | Not applicable | No public exploit | Memory corruption when processing command buffer requests with invalid length parameters in the Android Camera driver. |
| CVE-2026-25269 | Medium | 2026-10-06 | Not applicable | No public exploit | Memory corruption when processing camera requests with excessive batch and IO buffer configurations exceeds allocated memory size. |
| CVE-2026-106463 | Medium | 2026-10-06 | Not applicable | No public exploit | Backstage is an open framework for building developer portals. Prior to 0.8.7, the @backstage/plugin-catalog-backend-module-gitlab package is affected by improper authorization in gitlab organizational user ingestion. Deployments that enable GitLab organization event ingestion and rely on scoped catalog users as an access boundary may admit an unintended catalog identity. Depending on sign-in and permission configuration, this may allow unauthorized access with the permissions of a standard authenticated user. This issue is fixed in version 0.8.7. |
| CVE-2026-106462 | Medium | 2026-10-06 | Not applicable | No public exploit | Backstage is an open framework for building developer portals. Prior to 1.54.6, scaffolder source-control actions may not consistently enforce intended credential boundaries. An authenticated user could cause an affected action to fall back to broader integration credentials and perform operations with more access than intended. This issue is fixed in 1.54.6 when operators also enable scaffolder.requireScmUserCredentials after upgrading. |
| CVE-2026-105268 | Medium | 2026-10-06 | Not applicable | No public exploit | The Gitea API routes for issue attachments (`/api/v1/repos/{owner}/{repo}/issues/{index}/assets/{attachment_id}`) also accepted attachments that belong to comments on the issue. Because the author of an issue may edit and delete the issue's attachments, a user who opened an issue could rename or delete attachments that other users had posted in comments on that issue. The contents of the attachments could not be changed. |
| CVE-2026-105267 | High | 2026-10-06 | Not applicable | No public exploit | The Gitea web route for deleting tags (`POST /{owner}/{repo}/tags/delete`) requires only write access to the Code unit, but shares its handler with release deletion and did not check that the target was a plain tag. A collaborator with Code write access and without Releases write access could permanently delete published releases of that repository, including their attachments. Protected tag rules covering the release tag still blocked the deletion. |
| CVE-2026-104636 | High | 2026-10-06 | Not applicable | No public exploit | Gitea validated the initial remote URL for push mirrors, wiki remote checks, and fetches of migrated pull request heads, but the subsequent raw Git operations followed HTTP redirects without revalidating the destination. A repository administrator using a policy-allowed endpoint that redirects could make Gitea's Git client send requests to an address that the outbound host policy would otherwise block. The impact depends on the configured policy and the internal services reachable from the server. |
| CVE-2026-104633 | Medium | 2026-10-06 | Not applicable | No public exploit | When migrating a repository from another Gitea instance, Gitea used the page size reported in the source server's API settings to end its paginated downloads. A source that reported `max_response_items` as `0` made these loops run indefinitely and grow server memory until it was exhausted. Any user who can migrate repositories could point a migration at a server they control and cause a denial of service. |
| CVE-2026-104632 | High | 2026-10-06 | Not applicable | No public exploit | Gitea Actions blocks the jobs of workflow runs from first-time fork pull request contributors until a maintainer approves the run. The rerun path only required a run to be finished and built the new attempt's jobs without considering the pending approval, so when a user with Actions write access cancelled a run that was awaiting approval and then re-ran it, the new jobs were created as waiting rather than blocked while the run still recorded that approval was required. Cancelling and re-running stale fork checks is a routine action that does not involve the approval control, so where Actions is enabled and a matching runner is registered, workflow code taken from the fork pull request head could run on the repository's runners without an explicit approval. |
| CVE-2026-104626 | High | 2026-10-06 | Not applicable | No public exploit | A user who can open a fork pull request can place workflow content with a shared run-level concurrency group into a Gitea Actions run that is awaiting approval. When a later run in that group cancels the blocked job, the run becomes terminal while still marked as needing approval. If a maintainer later approves the run, Gitea passed the already-cancelled job back through concurrency preparation, set it to waiting, and made it claimable by a matching runner, executing fork-controlled workflow code. Exploitation requires the maintainer's later approval action, Actions to be enabled, and a runner that accepts the repository's jobs. |
| CVE-2026-103670 | High | 2026-10-06 | Not applicable | No public exploit | When a Gitea Actions run was inserted, older runs in the same workflow-level concurrency group were cancelled without checking whether the new run still needed approval. Because fork pull request runs are inserted under the base repository, a user who can open a pull request from a fork could cancel trusted in-progress runs that share a concurrency group with `cancel-in-progress` enabled, without approval and without running any code. On self-hosted runners this can interrupt deployments and leave partial state behind. |
| CVE-2026-103667 | Medium | 2026-10-06 | Not applicable | No public exploit | Gitea's container registry served blob downloads with a `Content-Type` taken from the media type declared in pushed image manifests, without a `Content-Disposition` or restrictive content security policy. A user who can push container images can publish a blob containing HTML and JavaScript with a `text/html` media type. When a victim who is authenticated to the instance opens the blob URL in a browser, the script runs on the Gitea origin and can perform actions as the victim, such as creating API tokens. |
| CVE-2026-103059 | Critical | 2026-10-06 | Not applicable | No public exploit | When Gitea's built-in SSH server is enabled (`START_SSH_SERVER = true`), the presented public key was looked up with an SQL `LIKE` comparison of its encoded content, which is case-insensitive on some databases, including the default SQLite. An attacker who can construct a case variant of another user's registered RSA public key for which they can derive the private key could have that key matched to the victim's account and authenticate over SSH as that user. Keys are now looked up by fingerprint. |
| CVE-2026-101029 | Medium | 2026-10-06 | Not applicable | No public exploit | Gitea's repository migration and pull mirror egress checks could be bypassed with a hostname that returns multiple DNS answers, because the address that was validated was not necessarily the address Git later connected to. A low-privileged user who can create migrations or mirrors could direct the server to internal services, reading from and writing to reachable internal Git or HTTP endpoints. Content from internal responses could additionally be disclosed through migration and mirror error messages. |
| CVE-2026-101027 | High | 2026-10-06 | Not applicable | No public exploit | When `[migrations] ALLOWED_DOMAINS` was configured, a hostname matching the allow list was accepted without checking its resolved address against the local-network restrictions. A user who can start repository migrations and control the DNS of an allowed hostname could make it resolve to loopback or private addresses and bypass `ALLOW_LOCALNETWORKS = false`, reaching internal services from the Gitea server. Instances without `ALLOWED_DOMAINS` configured are not affected by this specific bypass. |
| CVE-2026-101023 | Critical | 2026-10-06 | Not applicable | No public exploit | Gitea's OAuth2 token endpoint verified the signature and grant of a token submitted with the `refresh_token` grant type, but not that the token was a refresh token. An unexpired access token for the same OAuth2 application and grant could be exchanged for a new access token and refresh token. Whoever holds such an access token could keep access beyond the token's original lifetime. |
| CVE-2026-8937 | Medium | 2026-09-29 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.0 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an authenticated user to read private child issue contents, including titles and descriptions, from projects they had no access to, due to missing authorization checks on linked work items within visible epics. |
| CVE-2026-84739 | High | 2026-09-29 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.11 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an authenticated user to execute arbitrary JavaScript in the context of another user's browser session due to improper sanitization of path components in the merge request diff viewer. |
| CVE-2026-4523 | Low | 2026-09-29 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.11 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an unauthenticated user to read CI/CD job trace contents containing sensitive variable values due to improper authorization enforcement in the GraphQL API. |
| CVE-2026-10518 | Medium | 2026-09-29 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 17.9 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an authenticated user with guest-level permissions to read private security policy content they were not authorized to access due to improper authorization enforcement. |
| CVE-2026-102828 | Critical | 2026-09-29 | Not applicable | No public exploit | simple-git, an interface for running git commands in any node.js application, enables applications to execute Git operations from JavaScript. From 3.15.0 until 4.0.1, the default blockUnsafeOperationsPlugin does not classify trailer.<token>.cmd as unsafe configuration. An application that passes attacker-controlled values through SimpleGitOptions.config or inline -c arguments can therefore allow Git to invoke an attacker-selected shell command when git interpret-trailers processes the configured trailer. The command executes with the operating-system identity and permissions of the Node.js process. This issue is fixed in 4.0.1. |
| CVE-2026-102827 | Critical | 2026-09-29 | Not applicable | No public exploit | simple-git, an interface for running git commands in any node.js application, enables applications to execute Git operations from JavaScript. Prior to 4.0.0, the default blockUnsafeOperationsPlugin compares parsed option names with literal dangerous option spellings while Git accepts unambiguous long-option abbreviations. Attacker-influenced push arguments such as abbreviated --receive-pack or --exec forms can therefore bypass detectVulnerableFlags, reach git push against a local or file remote or an attacker-influenced receive-pack target, and cause Git to invoke an attacker-selected command in consumers that expose those arguments. The clone-side abbreviation handling does not protect the push path. This issue is fixed in 4.0.0. |
| CVE-2026-102826 | High | 2026-09-29 | Not applicable | Proof of concept only | simple-git, an interface for running git commands in any node.js application, enables applications to execute Git operations from JavaScript. Prior to 4.0.0, the default blockUnsafeOperationsPlugin does not completely reject configuration includes supplied through customArgs to git.clone(). The missing include.path classification permits Git to load an attacker-controlled configuration file, and the initial remediation does not cover includeIf.<condition>.path, allowing the same file-loading primitive through a conditional include. A loaded configuration can set an executable Git option such as core.sshCommand, which Git invokes during the clone operation with the privileges of the Node.js process. Exploitation requires the application to pass attacker-influenced custom arguments and requires an attacker-controlled file that the process can read. This issue is fixed in 4.0.0. |
| CVE-2026-93577 | Critical | 2026-09-24 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.2 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an authenticated user to execute arbitrary code on the GitLab server due to an integer overflow issue when compiling a specially crafted regular expression in a CI/CD configuration. |
| CVE-2026-92874 | Medium | 2026-09-24 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.3 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an authenticated user with an MCP-scoped token to perform actions beyond the intended scope of that token due to improper authorization checks. |
| CVE-2026-92628 | Low | 2026-09-24 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.6 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under a race condition, the MCP search tool's shared state handling could have caused search results to be returned under an incorrect user context. |
| CVE-2026-92530 | Medium | 2026-09-24 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.1 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an authenticated user to spoof merge request authorship and attribute content to arbitrary existing users on the target instance due to improper reliance on ephemeral cache state during Direct Transfer imports. |
| CVE-2026-92529 | Medium | 2026-09-24 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 19.1 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an authenticated user with developer-role permissions to bypass admin-configured AI tool governance controls for workflows in namespaces they do not control due to improper authorization checks. |
| CVE-2026-92470 | High | 2026-09-24 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 18.7 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an authenticated user to access sensitive CI/CD variable values from debug-mode job traces through the Duo AI troubleshooting feature due to missing authorization checks. |
| CVE-2026-89078 | Critical | 2026-09-24 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.2 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under certain conditions could have allowed an authenticated user to execute arbitrary code on the GitLab server due to a double free issue when parsing a specially crafted regular expression in a CI/CD configuration. |
| CVE-2026-25278 | High | 2026-09-17 | Not applicable | No public exploit | Memory Corruption when processing I2C transfer requests due to a race condition between memory allocation and data copying. |
| CVE-2026-25275 | High | 2026-09-17 | Not applicable | No public exploit | Transient DOS when processing authentication frames with invalid FILS information element header lengths. |
| CVE-2026-86341 | Medium | 2026-09-16 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 17.1 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that, under certain conditions, an authenticated user with Owner or Maintainer permissions could have silently disabled protected environment deployment approval requirements, allowing unapproved deployments to reach production, due to improper access control checks performed after the protected resource was modified. |
| CVE-2026-8030 | Medium | 2026-09-16 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.0 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that under certain conditions could have allowed an authenticated user to prevent another user from modifying their group settings due to improper validation of group URL slugs during namespace transfers. |
| CVE-2026-79708 | High | 2026-09-16 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 19.0 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that, under certain conditions could have allowed an authenticated user with developer permissions to execute a policy test pipeline on projects within their group and access protected CI/CD variables restricted to higher-privileged roles, due to insufficient scope validation. |
| CVE-2026-78252 | High | 2026-09-16 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.3 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that, under certain conditions, an authenticated user could have induced a targeted user to perform unintended state-changing HTTP requests due to improper sanitization of user-controlled data in the Markdown JSON table renderer. |
| CVE-2026-7514 | Medium | 2026-09-16 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.9 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that an authenticated user with developer-role permissions could substitute package file content and hide packages from their owners due to improper authorization checks in the Generic Package Registry. |
| CVE-2026-3855 | Medium | 2026-09-16 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.2.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that under certain conditions could have allowed an authenticated user with project-level permissions to access restricted file contents on the server or cause denial of service due to improper validation of parameters in the Terraform state upload functionality. |
| CVE-2026-19619 | Medium | 2026-09-16 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.0 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that under certain conditions could have allowed an unauthenticated user to execute arbitrary JavaScript in the context of a targeted user's session due to improper sanitization of pasted HTML content in the Content Editor. |
| CVE-2026-16794 | Medium | 2026-09-16 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab EE affecting all versions from 18.11 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that under certain conditions could have allowed an authenticated user with the Security Manager role to execute arbitrary CI/CD jobs and access protected variables within group projects due to improper authorization controls on compliance framework management. |
| CVE-2026-1168 | High | 2026-09-16 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.4.6 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that under certain conditions could have allowed an unauthenticated user to cause denial of service due to improper resource allocation limits in the GraphQL complexity calculation logic. |
| CVE-2025-14871 | High | 2026-09-16 | Not applicable | No public exploit | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.4.6 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that under certain conditions could have allowed an unauthenticated user to cause denial of service due to improper resource allocation limits in the GraphQL complexity calculation logic. |