GitLab Patches Duo AI, DoS, and Authorization Flaws in CE and EE
7 min. read 
Published on
GitLab has released versions 19.0.1, 18.11.4, and 18.10.7 for Community Edition and Enterprise Edition, fixing seven security issues across Duo AI workflows, Wiki, GraphQL APIs, Operations, Pipelines, and authentication endpoints. The GitLab patch release was published on May 27, 2026, for self-managed installations.
GitLab says all self-managed instances running affected versions should upgrade as soon as possible. GitLab.com is already running the patched release, and GitLab Dedicated customers do not need to take action.
Access content across the globe at the highest speed rate.
70% of our readers choose Private Internet Access
70% of our readers choose ExpressVPN
Browse the web from multiple devices with industry-standard security protocols.
Faster dedicated servers for specific actions (currently at summer discounts)
The most serious bug is CVE-2026-4868, a high-severity Duo AI workflow runner issue in GitLab EE. The remaining six issues carry medium severity scores but still affect important areas such as private project visibility, deployment data, CI data, and token enforcement.
What GitLab fixed in this release
The update covers both GitLab CE and EE, although several issues affect Enterprise Edition only. The vulnerabilities are not limited to one subsystem, which means administrators should treat the patch as a broad platform security update.
The GitLab release note lists one high-severity issue and six medium-severity issues. GitLab says vulnerability issue details are made public 30 days after the release in which they were patched.
The release also includes bug fixes and backports for components such as zlib, nginx, Mattermost, GitLab Shell, and the Elasticsearch indexer.
| CVE | Affected area | Edition | Severity | CVSS |
|---|---|---|---|---|
| CVE-2026-4868 | Duo AI workflow runners | GitLab EE | High | 8.2 |
| CVE-2026-1402 | Wiki | GitLab CE/EE | Medium | 6.5 |
| CVE-2026-6713 | GraphQL WorkItem API | GitLab CE/EE | Medium | 5.3 |
| CVE-2026-5296 | Duo Workflows API | GitLab EE | Medium | 4.3 |
| CVE-2026-2601 | Operations | GitLab EE | Medium | 4.3 |
| CVE-2026-8716 | Pipelines | GitLab CE/EE | Medium | 4.3 |
| CVE-2026-2710 | Authentication endpoints | GitLab CE/EE | Medium | 4.3 |
Duo AI workflow runner flaw is the top issue
CVE-2026-4868 affects GitLab EE from 18.8 before 18.10.7, 18.11 before 18.11.4, and 19.0 before 19.0.1. Under certain conditions, an authenticated user could cause specific Duo AI workflows to run under another user’s identity.
The NVD record for CVE-2026-4868 describes the bug as improper user identity resolution when triggering Duo AI workflow runners. GitLab gives it a CVSS 3.1 score of 8.2.
This matters because AI-assisted workflow systems can perform actions tied to user identity and permissions. If a workflow runs under the wrong identity, it can create access-control and auditability problems inside the platform.
Wiki DoS and private project enumeration also fixed
CVE-2026-1402 is a denial-of-service issue in the GitLab Wiki component. It affects GitLab CE/EE from 17.1 before 18.10.7, 18.11 before 18.11.4, and 19.0 before 19.0.1.
The NVD record for CVE-2026-1402 says an authenticated user could trigger resource exhaustion because of insufficient validation. GitLab rates the issue at 6.5 on the CVSS 3.1 scale.
GitLab also fixed CVE-2026-6713, an incorrect authorization issue in the GraphQL WorkItem API. Under certain conditions, an unauthenticated user could enumerate private projects due to incorrect authorization checks.
Other authorization issues affect operations, pipelines, and tokens
CVE-2026-5296 affects the Duo Workflows API in GitLab EE. When foundational flows were enabled at the group level, a developer-role user could bypass flow restrictions under certain conditions.
CVE-2026-2601 affects Operations in GitLab EE and could let a developer-role user access sensitive deployment data because of missing authorization checks. CVE-2026-8716 affects Pipelines and could allow access to CI data from a different ref type than intended.
CVE-2026-2710 affects certain authentication endpoints in GitLab CE/EE. It addresses a case where a blocked Project Access Token could continue accessing private resources because authorization enforcement was incorrect.
| Risk area | Relevant CVEs | Why admins should care |
|---|---|---|
| Duo AI workflows | CVE-2026-4868, CVE-2026-5296 | AI-assisted workflows may run with incorrect identity or restrictions |
| Wiki availability | CVE-2026-1402 | Authenticated users may trigger resource exhaustion |
| Project privacy | CVE-2026-6713 | Private project enumeration may become possible |
| Deployment data | CVE-2026-2601 | Developer-role users may access sensitive deployment information |
| CI data | CVE-2026-8716 | Users may access CI data from a different ref type |
| Project Access Tokens | CVE-2026-2710 | Blocked tokens may retain access to private resources |
Who needs to upgrade
Self-managed GitLab administrators should upgrade to 19.0.1, 18.11.4, or 18.10.7, depending on their supported release branch. GitLab says all installations running affected versions should move to the latest patch release as soon as possible.
GitLab.com users do not need to patch their own environment because GitLab has already updated the hosted service. GitLab Dedicated customers also do not need to take action for this patch release.
Admins should still review their own integrations, runners, API usage, and audit logs, especially if they use Duo workflows, Wiki features, WorkItems, deployment workflows, CI pipelines, or Project Access Tokens.
Upgrade planning and downtime
GitLab says these versions do not include new migrations. For multi-node deployments, the release should not require downtime when teams follow GitLab’s documented upgrade process.
The GitLab zero-downtime upgrade documentation explains that multi-node environments can upgrade nodes sequentially when load balancers and high-availability mechanisms are configured correctly.
Administrators should still test the patch in staging when possible, check backup status, confirm runner compatibility, and schedule the rollout through their normal change process.
Recommended admin checklist
- Identify all self-managed GitLab CE and EE instances.
- Confirm whether each instance runs 19.0, 18.11, 18.10, or older affected versions.
- Upgrade to 19.0.1, 18.11.4, or 18.10.7.
- Prioritize GitLab EE instances using Duo AI workflows.
- Review Wiki usage for unusual activity or resource spikes.
- Audit GraphQL WorkItem API access patterns where logs are available.
- Review Project Access Tokens that were blocked before the patch.
- Check CI data access patterns around protected refs and branch or tag workflows.
Security hardening should continue after patching
Patching closes the known vulnerabilities, but GitLab administrators should also review broader instance security. Self-managed GitLab systems often hold source code, CI secrets, deployment credentials, and project history.
The GitLab hardening guide includes recommendations for self-managed environments, including compliance-related controls and security configuration guidance.
Admins should also review user permissions, project visibility, runner isolation, token lifetime, and access to sensitive deployment data. Medium-severity authorization bugs can become more serious when an instance has broad roles, stale accounts, or weak token controls.
| Control | Why it matters |
|---|---|
| Patch supported branches quickly | Reduces exposure to fixed security issues |
| Limit Developer role assignments | Reduces impact from role-based authorization flaws |
| Review Project Access Tokens | Prevents stale or blocked tokens from retaining access |
| Isolate CI runners | Limits risk from pipeline and job execution paths |
| Restrict private project visibility | Reduces the impact of enumeration bugs |
| Monitor Wiki and API activity | Helps detect abuse of patched areas |
No public exploitation was mentioned
GitLab’s announcement does not state that any of the fixed vulnerabilities are being exploited in the wild. Still, administrators should not delay the update, especially on internet-facing self-managed instances.
The CVE-2026-4868 listing shows why the Duo AI runner issue deserves priority: it affects user identity handling in workflows and carries high confidentiality and integrity impact.
The CVE-2026-1402 listing also shows why availability bugs still matter. An authenticated user who can exhaust Wiki resources may disrupt work for other users on the instance.
The bottom line
GitLab 19.0.1, 18.11.4, and 18.10.7 fix seven security issues across AI workflows, authorization controls, Wiki availability, pipelines, operations, and authentication endpoints. The highest-priority fix is the Duo AI workflow runner identity issue in GitLab EE.
Self-managed administrators should upgrade quickly, then review logs and permissions around Duo workflows, Wiki, WorkItems, Operations, Pipelines, and Project Access Tokens. The zero-downtime upgrade process and GitLab hardening recommendations can help teams apply the patch while improving long-term security posture.
FAQ
GitLab fixed the issues in versions 19.0.1, 18.11.4, and 18.10.7 for Community Edition and Enterprise Edition. Self-managed administrators should upgrade to the fixed release for their supported branch.
The most serious issue is CVE-2026-4868, a high-severity improper access control flaw in GitLab EE Duo AI workflow runners. It could allow an authenticated user to trigger certain Duo AI workflows under another user’s identity.
No. GitLab says GitLab.com is already running the patched version. GitLab Dedicated customers also do not need to take action for this patch release.
GitLab’s patch release does not mention active exploitation. However, self-managed administrators should still upgrade quickly because the release fixes access control, authorization, denial-of-service, and token enforcement issues.
Admins should review Duo workflow activity, Wiki resource usage, GraphQL WorkItem access, deployment data access, CI data access, and Project Access Tokens that were blocked before the patch.
Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more
Improve this guide
User forum
0 messages