Loading story…
Aikido Security reported that GitLab's “Email work item to this project” addresses contain a long-lived, account-wide glimt- incoming-email token. An attacker who obtains one of these addresses can submit email as the token owner, create work items and merge requests, and send Git patches for application to repository branches—potentially affecting private projects under that user's permissions. The same token is reportedly embedded in addresses generated for multiple projects and is non-expiring.
A malicious patch modifying .gitlab-ci.yml could trigger attacker-controlled CI/CD jobs and expose source code or secrets; a leaked Maintainer token could also enable changes to protected branches. The inbound-email workflow reportedly bypasses project IP restrictions and does not validate sender addresses. GitLab has characterized the behavior as designed and updated interface wording and documentation, but has not changed the account-wide token model or added granular controls to disable the affected email features.
See affected versions and whether adversaries are exploiting it.
5 events from the most recent confirmed update back to the earliest known activity.
Aikido researcher Joe Leon published research showing that exposed, long-lived GitLab incoming-email addresses can be used under the token owner's permissions to create merge requests and apply emailed patches. The research reported potential commits to protected branches, CI/CD execution and secret exposure, and bypass of project IP restrictions where permissions allow.
After the HackerOne report was closed, the researchers filed a confidential issue directly with GitLab concerning the incoming-email token behavior.
Aikido Security researchers reported GitLab's account-wide incoming-email token behavior through HackerOne, where the report was closed as intended behavior.
GitLab opened an issue to explore verifying that incoming work-item messages originate from an email address associated with the token owner's account.
Following disclosure, GitLab removed interface wording that suggested the token could not access other data and clarified documentation on merge-request use, token secrecy and resets, and the exemption from project IP restrictions. The underlying account-wide incoming-email mechanism was not changed.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
GitLab issued several security patch releases for Community Edition and Enterprise Edition to fix vulnerabilities affecting self-managed deployments, including two **critical pipeline impersonation flaws** that could let an attacker run CI/CD pipeline jobs as another user. The issues were tracked as `CVE-2024-5655` and `CVE-2024-6385`, with the latter included alongside fixes for group URL modification, deploy token creation, package registry manifest confusion, group member banning, and GitLab Pages subdomain takeover. GitLab said **GitLab.com** and **GitLab Dedicated** were already running patched versions and reported no evidence of abuse of `CVE-2024-5655` on GitLab-managed platforms. Subsequent patch releases addressed additional high- and medium-severity weaknesses, including stored cross-site scripting in Asciidoctor rendering (`CVE-2025-0314`), CI/CD variable exfiltration through CI lint (`CVE-2024-11931`), denial of service via cyclic epic references (`CVE-2024-6324`), access token exposure in logs, unauthorized issue status changes in public projects, and an Instance SAML configuration flaw that could expose internal projects or groups. GitLab also changed importer behavior after earlier importer-related problems, adding post-import mapping and user acceptance controls, and warned self-managed administrators using Direct Transfer, GitHub, Bitbucket Server, or Gitea importers to disable those features until upgraded.
Jul 24, 2026
GitLab released patched versions **17.6.1**, **17.5.3**, and **17.4.5** for Community Edition and Enterprise Edition to fix multiple security issues, led by **CVE-2024-8114**, a high-severity privilege-escalation vulnerability involving **LFS tokens**. GitLab said the flaw affects a broad range of GitLab CE/EE versions and can be exploited by an attacker who has access to a victim’s **Personal Access Token**. The company said **GitLab.com** was already running the patched version, while self-managed customers were urged to upgrade immediately. The release also addressed several medium-severity issues, including denial-of-service conditions, unintended access to usage data through scoped tokens, and an authentication weakness in a streaming endpoint. Public references in the vulnerability records include **`CVE-2024-8114`**, **`CVE-2024-8177`**, and **`CVE-2024-8237`**, tying the fixes to GitLab’s broader November security update for both CE and EE deployments.
Jul 24, 2026
Reporting highlighted a **GitLab authentication weakness** in which a *2FA login protection bypass* could allow attackers to take over accounts, enabling unauthorized access to GitLab instances and the ability to act as legitimate users. With access, an attacker could perform source-code actions such as downloading, altering, or deleting repositories, creating direct risks to software integrity and the SDLC. Commentary from SANS Institute’s Johannes Ullrich noted that, in practice, attackers may find **phishing and other social engineering** more efficient for obtaining valid credentials than attempting to forge device credentials to exploit the bypass, but the end-state risk remains the same once passwords are obtained. Recommended defensive measures emphasized **layered identity controls**: enforce long/unique passwords, monitor for anomalous access patterns (e.g., logins without a corresponding MFA challenge), and ensure an incident response plan is ready if account compromise is suspected.
Jun 29, 2026