NewApp Monitoring is liveSign up free
AgentbeamBeta
Open-source package vulnerability · GitLab

CVE-2026-12664: GitLab CE/EE improper access control in GraphQL work item email address field

mediumCVSS 3.1 6.8

A GraphQL field for work items in GitLab CE/EE did not enforce token scope. An authenticated user holding only a `read_api` token could read a project's incoming email address and create work items, which a read-only token should not allow. Affected: 18.2 before 19.3.6, 19.4 before 19.4.3 and 19.5 before 19.5.1. Upgrade to 19.3.6, 19.4.3 or 19.5.1.

Published Oct 21, 2026 · Analysis Oct 22, 2026

What an attacker can do

GitLab Personal Access Tokens carry scopes, and read_api is meant to allow reads only. The GraphQL work item email address field checked the user but not that scope. A holder of a read_api token could therefore fetch a project's incoming email address, the address that turns emails into issues or work items, and then create work items with it, bypassing the token's restrictions. GitLab calls the cause insufficient scope enforcement on a GraphQL field.

The CVSS 3.1 vector scores it 6.8 (medium) with high confidentiality and high integrity impact but high attack complexity. The attacker needs an account with access to the project and a read_api token. That makes leaked or shared read-only tokens, such as CI integrations, dashboards and third-party tools, the main exposure: they become able to write.

GitLab does not describe how far the created work items can go or whether the email address allows more than creating items. It reports no exploitation. The reporter is credited as go7f0.

Who is affected

GitLab CE and EE, all versions from 18.2 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1. The risk is higher on instances that hand out read_api tokens to scripts and integrations. Check your version in the Admin Area, on the /help page, or on the host:

dpkg -l gitlab-ee gitlab-ce

For tokens, list them under each user's access token settings or through the admin token view.

How to fix it

Upgrade to GitLab 19.5.1, 19.4.3 or 19.3.6, released October 21, 2026. The bulletin lists no workaround and recommends upgrading self-managed installations right away; GitLab.com is patched.

How to tell if you were hit

Look for work items created by accounts or tokens that normally only read, using audit events and the project's work item history, and for GraphQL queries that request the work item email address field from tokens with the read_api scope. The bulletin gives no log signature. Review items created through incoming email addresses for senders you do not recognize.

Original advisory

From the National Vulnerability Database. This product uses the NVD API but is not endorsed or certified by the NVD.

Under certain conditions, an authenticated user with a read_api-scoped token could have retrieved a project's incoming email address and created work items, bypassing the token's restrictions, due to insufficient scope enforcement on a GraphQL field. Impacted versions: GitLab CE/EE all versions from 18.2 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1. Fixed in GitLab CE/EE 19.5.1, 19.4.3 and 19.3.6, released October 21, 2026.

Credited to go7f0.

Questions

Can a read_api token create things in GitLab?

On affected versions, yes through this GraphQL field: the token could get a project's incoming email address and create work items. The fixed versions enforce the token scope.

Which versions fix CVE-2026-12664?

GitLab 19.5.1, 19.4.3 and 19.3.6. Releases from 18.2 before those versions are vulnerable.

Why is the score medium if confidentiality and integrity are high?

The vector sets high attack complexity and requires low privileges, which brings the score to 6.8. The attacker needs a valid account and a read_api token.

References

How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. The analysis is written by an AI model from the sources listed above and checked by automated rules before it is published. Check versions against the vendor's advisory before you act. Methodology

Coverage on the Beam blog

More GitLab vulnerabilities

All GitLab entries