ConfusedComposer: A Privilege Escalation Vulnerability Impacting GCP Composer

Tenable Research discovered a privilege-escalation vulnerability in Google Cloud Platform (GCP) that is now fixed and which we dubbed ConfusedComposer. The vulnerability could have allowed an identity with permission (composer.environments.update) to edit a Cloud Composer environment to escalate privileges to the default Cloud Build service account. The default Cloud Build service account includes permissions to Cloud Build itself, as well as to Cloud Storage, Artifact Registry, and more.

What are Cloud Composer and Cloud Build?

Cloud Composer is a fully managed workflow-orchestration service in GCP based on Apache Airflow that is used for scheduling and automating data pipelines.

Cloud Build is a fully managed continuous integration and delivery (CI/CD) service in GCP that builds, tests and deploys applications and containers at scale.

Cloud Composer uses Cloud Build to build packages, and that is exactly where attackers could have abused the process to escalate privileges.

ConfusedComposer vulnerability details

Cloud Composer allows users to install custom PyPI packages in their environments. However, this functionality introduced a privilege escalation vulnerability due to how Composer interacts with Cloud Build. When a user specifies a custom PyPI package, Composer initiates a behind-the-scenes build process, and the Cloud Composer service account automatically provisions a Cloud Build instance in the user's project. This instance is attached to the default Cloud Build service account, a highly privileged identity with broad permissions to GCP services including to Cloud Build itself, as well as to Cloud Storage, Artifact Registry or Container Registry, and more. (Click here to learn more about the default Cloud Build service account permissions).

An attacker with the composer.environments.update permission could have abused the Cloud Composer service orchestration process to escalate privileges. The attack would have been executed by injecting an attacker-controlled malicious PyPI package into the victim’s Composer custom-package configuration: 

When Cloud Build installs this package in an attempt to build the environment, it uses Pip. 

But how would one have executed remote code by adding a package to the Composer service? Turns out that Pip automatically runs pre- and post-package installation scripts. This would have allowed an attacker to execute arbitrary code within the correlated Cloud Build environment by using installation scripts inside their malicious package, despite lacking direct control over Composer’s underlying service account. 

The privilege escalation would have occurred when an attacker injected code that accessed the Cloud Build’s metadata API. Because the build instance runs with the default Cloud Build service account, an attacker could have extracted and exfiltrated its token. With this token, the attacker would have gained control over a privileged service account, allowing further escalation across the victim’s GCP project. This attack was particularly dangerous because the attacker did not need direct access to the Composer’s service account or to Cloud Build’s service account—only the ability to update a Composer environment. By simply adding a PyPI package to Composer, they could have manipulated the trusted automation pipeline to escalate privileges beyond their original access level. To clarify the impact of the now-fixed vulnerability: gaining full ownership of the project from the default Cloud Build service account was well within reach. 

The vulnerability fix and extra steps taken by GCP to enhance overall security

Previously, during update operations to perform PyPI module installations, Composer used the Cloud Build service account, which might have had broader permissions than the user performing the operation. After implementing the fix, Composer stopped using the Cloud Build service account and instead will use the Composer environment service account for performing PyPI module installations.

The fix has been rolled out to new Composer instances already (rel. notes), and existing instances should be updated to exhibit this behavior by April 2025 (rel. notes).

In addition, our findings led GCP to update parts of Composer’s documentation, such as the sections on Access Control, Installing Python Dependencies and Accessing the Airflow CLI.

A new attack class: Following the ConfusedFunction vulnerability

The ConfusedComposer privilege-escalation vulnerability in GCP builds upon a broader attack class of vulnerabilities in cloud services that we call "Jenga®" . This attack vector is a variant of ConfusedFunction, another GCP privilege-escalation vulnerability we discovered last year, and exploits the somewhat-hidden cloud provider misconfigurations related to cloud services permissions to escalate privileges beyond intended access levels. This variant highlights how attackers can abuse interconnected services the cloud provider automatically deploys behind the scenes, as part of a service-orchestration process.

(JENGA® is a registered trademark owned by Pokonobe Associates.)