CVE-2024-6356 is a newly discovered vulnerability affecting Enterprise Editions (EE) of GitLab, introducing a risk where the Security Policy Bot could interact with more projects than originally intended. This post provides an easy-to-understand breakdown, a demonstration of the vulnerability, and pointers for mitigation.

Component: Security Policy Bot

The flaw allows the Security Policy Bot to access or interact with _other_ GitLab projects in situations where it shouldn’t have permissions, risking both data confidentiality and integrity.

Official Advisory

- GitLab Security Release Details
- GitLab CVE-2024-6356 Issue
- NVD Entry (when published)

How Was It Discovered?

Security researchers analyzing cross-project access controls spotted the Policy Bot acting outside its project boundaries after reviewing audit logs and API calls.

A minimal reproduction, shared by GitLab, showed that under certain configurations, the bot was able to push merge requests or read confidential data from other groups or projects.

Exploit Scenario (Step-by-Step)

Let’s see how the vulnerability could be abused in a realistic setup.

Enable a security policy that uses the Security Policy Bot

# .gitlab/security-policies/policy.yml
type: scan_execution_policy
name: My Test Policy
description: > 
  This is a test policy.
enabled: true
rules:
  - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    branches:
      - main
    branches_to_protect:
      - project-a

Add the Security Policy Bot as a maintainer for project-a only.

3. Improper Cross-Project Token Usage

Due to CVE-2024-6356, the bot receives a token with wider scope than required. It then can be tricked (via a crafted pipeline or API request) to perform an action in project-b, where it should have no access:

Example: Using a pipeline job to access project-b

# In project-a/.gitlab-ci.yml
access_other_project:
  script:
    - |
      curl --header "PRIVATE-TOKEN: $SECURITY_POLICY_BOT_TOKEN" \
           "https://gitlab.example.com/api/v4/projects/<project-b-ID>/repository/files/secret.txt/raw?ref=main";
  only:
    - main

Here, the $SECURITY_POLICY_BOT_TOKEN unintentionally has access to both projects.

### 4. Result: Data Leakage / Modification

The bot can read files in project-b it shouldn’t see or even push changes if the API permissions allow.

Why Does This Matter?

The heart of the problem is that _automation intended to enforce security policies can become a powerful attack tool if not tightly scoped_. Any user with access to policy configurations could potentially leverage the bot for lateral movement between repositories—breaking a foundational principle of DevOps security.

Mitigation

Upgrade Immediately

17.2 users: Upgrade to 17.2.2 or newer

Audit Bot Permissions
Check all Security Policy Bot tokens and assignments.

Review Audit Logs
Look for unexpected cross-project access by security bots.

Use different bots for each sensitive project if possible.

- Periodically review all project maintainer/owner assignments.


## References / Further Reading

- GitLab Release Blog
- GitLab Security Policies Documentation
- Mitre CVE Reference

Summary

CVE-2024-6356 highlights how powerful automation features, such as GitLab’s Security Policy Bot, can become a liability if buggy or over-privileged. The fix is available—every GitLab admin should audit and update now.

If you spot suspicious bot activity between your projects, now you know one more thing to check.


*Stay tuned for more exclusive, reader-friendly vulnerability breakdowns!*

Timeline

Published on: 02/05/2025 10:15:22 UTC