Critical GitLab Vulnerability: Attackers Can Run Pipelines as Any User. Here is what to know, A Quick look.

GitLab, a widely used platform for DevOps lifecycle tools, recently disclosed a critical vulnerability that affects both its Community Edition (CE) and Enterprise Edition (EE). This flaw, identified as CVE-2024-5655, allows attackers to execute pipelines as any user. In this article, we’ll explore the details of this security issue, its impact, and recommended actions.

The Vulnerability in GitLab

CVE-2024-5655: Run Pipelines as Any User

The vulnerability arises from GitLab versions 15.8 onwards. Under specific conditions, attackers can trigger pipelines as another user. This poses a significant security risk, potentially compromising internal repositories and private projects. The flaw undermines the integrity of GitLab’s scan execution policy feature, allowing unauthorized access to sensitive resources.

Mitigation Measures

Immediate Action Required

While there’s no evidence of active exploitation in the wild, the severity of this vulnerability demands urgent attention. GitLab strongly recommends the following steps:

1. Upgrade GitLab Instances: Users of GitLab CE and EE should promptly upgrade to one of the following versions: 17.1.1, 17.0.3, or 16.11.5. These releases contain essential security fixes.
2. Manual Pipeline Start: The patch modifies the Merge Request (MR) re-targeting workflow. Users must now manually initiate pipelines when a target branch is merged.
3. GraphQL Authentication Changes: GraphQL authentication using CI_JOB_TOKEN is disabled by default. Alternative authentication methods are now required.

Additional GitLab Vulnerabilities Addressed

Apart from CVE-2024-5655, GitLab’s recent updates tackle several other vulnerabilities:

• Stored XSS in Imported Project’s Commit Notes (CVE-2024-4901): Malicious commit notes in imported projects could execute arbitrary scripts within a user’s session.
• CSRF on GraphQL API IntrospectionQuery (CVE-2024-4994): Allows unauthorized GraphQL mutations, potentially compromising the GitLab instance.

Conclusion

GitLab’s swift response in releasing critical updates demonstrates their commitment to security. Users must act promptly to safeguard their installations. By staying informed and taking necessary precautions, organizations can mitigate risks and maintain the integrity of their DevOps workflows.

Remember, security is a shared responsibility. Let’s keep our pipelines secure and our code repositories protected.

You think you have a story worth everyone’s time? SUBMIT A STORY and we will publish it.