GitLab Forking Restriction Bypass (CVE-2025-3396): Anatomy of an Authorization Flaw

Introduction

In July 2025, GitLab patched a flaw in its group forking restrictions that let project owners fork projects outside their organization's boundaries, with the risk of code leakage and compliance failures. Many security teams rely on GitLab's group-level policies to contain sensitive projects. For them, the flaw shows that an intellectual property control is only as strong as its weakest enforcement point, and that API endpoints need the same rigorous protection as the UI.

About GitLab: GitLab is a DevOps platform used by millions of developers and thousands of organizations worldwide. It ships as an open-source Community Edition and a commercial Enterprise Edition, and enterprises and startups use it for CI/CD pipelines, code collaboration, and secure software delivery.

Technical Information

Vulnerability Mechanism

CVE-2025-3396 comes from an incorrect authorization check on GitLab's project forking API endpoint. When a group enables the Prevent project forking outside current group setting, forks are supposed to stay inside the group hierarchy, which is how the setting contains intellectual property. The API endpoint:

POST /api/v4/projects/:id/fork

did not properly validate the namespace parameter when a project owner called it. An attacker with project owner privileges could craft a request that names a destination namespace outside the allowed group (a personal namespace, for example) and create the fork there, bypassing group policy.

Exploitation Flow

1. Attacker Requirements:
   • Must be an authenticated project owner within a group that has forking restrictions enabled.
   • Must have API access (personal access token or session).
2. Attack Steps:
   • Craft a POST request to /api/v4/projects/:id/fork with a namespace parameter pointing to an external or personal namespace.
   • The server does not check authorization properly, so it creates the fork outside the group.

Root Cause: The authorization logic did not enforce group-level forking restrictions on API requests. In particular, it did not validate the destination namespace against group policy. The flaw is classified as CWE-863 (Incorrect Authorization).

Affected Configurations:

• GitLab EE and CE with group-level forking restrictions enabled.
• Project owner roles with API access.

The attack needs no user interaction (UI:N), can be run remotely (AV:N), and has low complexity (AC:L).

Patch Information

The latest GitLab patch release (versions 18.1.2, 18.0.4, and 17.11.6) fixes several critical security vulnerabilities.

Authorization Bypass Prevention

Under CVE-2025-3396, authenticated project owners could bypass group-level forking restrictions by manipulating API requests. The fix strengthens the permission checks in the API endpoints so that group-level policies are enforced consistently, whatever the source of the request.

Other Notable Fixes in This Release:

• XSS mitigation (CVE-2025-6948)
• Additional authorization fixes (CVE-2025-4972, CVE-2025-6168)
• rsync utility update

Patch Source: GitLab Patch Release Advisory (2025-07-09)

Detection Methods

Detecting vulnerabilities like CVE-2025-3396 takes both automated tools and manual verification:

• Automated Scanning: Run a vulnerability scanner such as Nessus. Nessus Plugin ID 241691 detects GitLab instances vulnerable to CVE-2025-3396 by checking version numbers.
• Manual Verification:
  • Review the GitLab instance version and the group forking settings.
  • Audit API logs for suspicious fork requests that specify external namespaces.
• Monitoring: Log and alert on API activity related to project forking and group-level permissions.

Affected Systems and Versions

• Products: GitLab Community Edition (CE) and Enterprise Edition (EE)
• Vulnerable Versions:
  • 13.3 up to (but not including) 17.11.6
  • 18.0 up to (but not including) 18.0.4
  • 18.1 up to (but not including) 18.1.2
• Vulnerable Configurations:
  • Groups with Prevent project forking outside current group enabled
  • Project owner users with API access

Vendor Security History

GitLab has a well-established record of responding to security issues. It:

• Maintains a public bug bounty program (HackerOne)
• Typically releases patches within weeks of disclosure
• Has had similar authorization and access control vulnerabilities before, and fixed them in regular patch cycles
• Publishes transparent advisories and detailed documentation for each security release

References

• NVD: CVE-2025-3396
• HackerOne Report
• GitLab Patch Release Advisory (2025-07-09)
• Nessus Plugin 241691
• CWE-863: Incorrect Authorization

Source: This report was created using AI

If you have suggestions for improvement or other feedback, email us at [email protected]