Gitlab fixes bug that exploited internal policies to trigger hostile pipelines

Gitlab has released two patched releases, 16.2.7 and 16.3.4 for the Enterprise (EE) and Community (CE) editions of the DevOps platform in response to a critical severity bug discovered through its HackerOne bug bounty program.

Dubbed CVE_2023-5009, with a CVSS score of 9.6, the vulnerability allows an attacker to pose as an arbitrary user to run pipelines via scheduled scan policies.

“An issue has been discovered in GitLab EE affecting all versions starting from 13.12 before 16.2.7 and all versions starting from 16.3 before 16.3.4,” Gitlab said in a statement. “We strongly recommend that all installations running a version affected by these issues are upgraded to the latest version as soon as possible.”

The flaw is a bypass of another bug from July, tracked under CVE-2023-3932, which allowed similar attacker activities.

Vulnerability exploits scheduled security scan policies

It was possible for an attacker to run pipelines as an arbitrary user via scheduled security scan policies, Gitlab said. A pipeline in Gitlab is a series of automated steps or jobs that are executed whenever changes are pushed to a Git repository.

The vulnerability could be triggered via the scan execution policy on the basis of who last made a commit on the policy.yml file. The pipeline is triggered through a commit by an attacker who uses a victim username to push changes to policy.yml as a victim.

As the author of the triggered pipeline, the attacker has access to all of the victim’s repositories and private codes. All this is done without any user interaction and the only pre-requisite is the victim’s Gitlab username and names of the internal or member-only projects with codes.

Trigger has configuration needs

Instances running versions starting from 13.12 before 16.2.7, and all versions starting from 16.3 before 16.3.4 are vulnerable given two features are enabled at the same time on the DevOps platform — Direct transfers and Security Policies, according to Gitlab.

“In order to mitigate this vulnerability in situations where it’s not possible to upgrade, it is required to disable one or both features,” Gitlab added.

Gitlab has advised users to quickly update to security releases 16.3.4 and 16.2.7 which also include a few non-security patches. GitLab.com is already running the patched version, the company added.

Vulnerabilities