ConfusedComposer: GCP Cloud Build vunerability via PyPI Packages • William OGOU Cybersecurity Blog

Cloud services offer incredible power and flexibility, but their complexity can also hide serious security risks. Tenable recently discovered a major vulnerability in Google Cloud Platform (GCP), called ConfusedComposer.

This wasn’t just a small bug—it was a privilege escalation flaw. It allowed attackers with limited access in Cloud Composer to take control of the powerful default Cloud Build service account. From there, they could potentially access sensitive data and critical systems in a GCP project. Surprisingly, the trigger could be something as simple as updating Python packages.

This issue highlights how hidden, automated interactions between GCP services can create unexpected security threats.

Setting the Scene: Understanding Cloud Composer and Cloud Build

To grasp the ConfusedComposer vulnerability, we first need to understand the players involved:

Google Cloud Composer: This is GCP’s fully managed workflow orchestration service, built upon the popular open-source Apache Airflow project. It allows users to schedule, monitor, and manage complex data pipelines and workflows using Python. A key feature is its ability to install custom Python Package Index (PyPI) packages to extend functionality.
Google Cloud Build: GCP’s fully managed continuous integration and continuous delivery (CI/CD) platform. It executes builds based on provided configurations, pulling source code, running tests, building artifacts (like container images), and deploying them. Cloud Build is a powerful automation engine used extensively within GCP.

The vulnerability arises precisely at the intersection where Cloud Composer utilizes Cloud Build for a seemingly routine task.

ConfusedComposer Explained: The Anatomy of the Privilege Escalation

Tenable Research dubbed this vulnerability “ConfusedComposer,” classifying it as a variant of another GCP flaw they found (“ConfusedFunction”) and an example of the “Jenga” concept – where security issues in one service can be inherited or triggered by another service built atop it. Here’s how the attack chain worked:

The Entry Point: The composer.environments.update Permission

The attack begins with an adversary already possessing a specific, non-administrative IAM permission: composer.environments.update. This permission allows a user to modify settings within a Cloud Composer environment, including the crucial ability to specify custom PyPI packages that should be installed into that environment. While seemingly restricted, this permission became the key to unlocking much higher privileges.

The Hidden Interaction: Composer Delegating to Cloud Build

Here’s where the automated, behind-the-scenes interaction occurs. When a user specifies a custom PyPI package to be installed in their Composer environment (using that update permission), Cloud Composer doesn’t install it directly. Instead, it automatically triggers a Cloud Build process within the user’s project to handle the package installation. This delegation is intended to provide a robust and scalable way to manage dependencies.

The Core Flaw: The Over-Privileged Default Cloud Build Service Account

This was the critical misstep. Prior to Google’s fix, the Cloud Build instance initiated by Cloud Composer for PyPI installation did not run using the identity (service account) of the user making the request, nor did it use the specific service account assigned to the Composer environment itself. Instead, it executed under the identity of the default Cloud Build service account ([PROJECT_NUMBER]@cloudbuild.gserviceaccount.com).

Why is this problematic? The default Cloud Build service account, by default, possesses highly privileged IAM roles within a GCP project. It often has permissions not just to execute builds but also extensive access to services like:
- Cloud Build itself (potentially modifying other build processes)
- Cloud Storage (reading/writing to buckets across the project)
- Artifact Registry / Container Registry (pulling/pushing images and artifacts)
- And potentially many other services depending on project history and configuration.

This meant a process triggered by a relatively low-privileged action (updating Composer packages) was suddenly executing with broad, project-spanning permissions.

The Weapon: Crafting a Malicious PyPI Package

The attacker leverages their composer.environments.update permission to tell Cloud Composer to install a custom PyPI package they control. This isn’t a legitimate package from the public PyPI repository; it’s one specifically crafted by the attacker and likely hosted in a private repository or even just defined inline if the configuration allows.

The malicious payload isn’t necessarily in the Python code within the package itself, but rather in its installation scripts. Standard Python packaging allows developers to define scripts (often within setup.py) that run automatically before or after the package is installed by tools like pip (which Cloud Build uses under the hood).

The Exploit Chain: Code Execution -> Metadata -> Token Theft

Trigger: Attacker updates the Composer environment to install their malicious PyPI package.
Delegation: Composer triggers Cloud Build to perform the installation.
Privileged Context: Cloud Build starts the installation process running as the default Cloud Build service account.
Code Execution: pip begins installing the malicious package, triggering the attacker’s embedded pre- or post-installation script. This script now executes within the Cloud Build environment.
Metadata Access: Code running inside a standard Cloud Build environment can query the instance metadata server (specifically the Cloud Build metadata API).
Token Theft: The attacker’s script queries the metadata API for the access token associated with the service account running the build – the default Cloud Build service account’s token.
Exfiltration: The script sends this stolen access token to an attacker-controlled server.
Escalation Complete: The attacker now possesses a short-lived but powerful OAuth2 access token belonging to the highly privileged default Cloud Build service account. They can use this token to interact with GCP APIs according to the service account’s extensive permissions.

Critically, the attacker never needed direct permissions for Cloud Build or the default service account; they merely needed the permission to tell Composer to install a package. Composer’s automated use of Cloud Build, combined with Cloud Build’s use of the over-privileged default service account for this task, created the escalation path.

The Impact: Why ConfusedComposer Mattered

Successful exploitation of ConfusedComposer wasn’t trivial; it granted attackers significant capabilities, potentially including:

Data Exfiltration: Reading sensitive data from Cloud Storage buckets across the project.
Artifact Theft/Tampering: Accessing and potentially modifying container images or software packages stored in Artifact Registry or Container Registry.
CI/CD Pipeline Poisoning: Abusing Cloud Build permissions to inject malicious code into other build processes, compromising the software supply chain.
Service Disruption: Interfering with Cloud Build operations or potentially other services accessible by the default service account.
Backdoor Deployment: Using obtained privileges to establish persistent access mechanisms within the GCP project.
Full Project Compromise: Depending on the specific permissions held by the default Cloud Build SA (which can sometimes include overly broad roles like Editor), attackers might have achieved near-full control over the GCP project.

Google’s Response: Fixing the Flow

Following responsible disclosure by Tenable, Google addressed the ConfusedComposer vulnerability swiftly and decisively, primarily by changing how Cloud Composer handles PyPI installations:

The Fix: Composer stopped using the default Cloud Build service account for PyPI installations. Instead, it now uses the Composer environment’s service account. This aligns with the principle of least privilege, ensuring the installation process only has the permissions explicitly granted to the Composer environment itself, not the broad permissions of the default Cloud Build SA.
Rollout: This fix was implemented for new Cloud Composer 2 environments created in versions 2.10.2 and later, and for all Cloud Composer 3 environments (which already used this correct behavior).
Update Mandate: Existing Cloud Composer 2 environments that previously used the vulnerable flow were required to be updated by April 2025 to adopt the new, secure behavior.
Documentation Updates: Google also updated relevant documentation concerning Access Control, Installing Python Dependencies, and Accessing the Airflow CLI to reflect best practices and the corrected service account usage.

Conclusion: Lessons from the Composer’s Confusion

ConfusedComposer serves as a potent case study in cloud security, highlighting several critical lessons:

Hidden Interactions Matter: Automated processes and interactions between cloud services, while convenient, can create non-obvious attack surfaces. Understanding how services delegate tasks and which identities they use is crucial.
Default Permissions are Dangerous: Default service accounts (like the Cloud Build SA) often possess overly broad permissions. Applying the principle of least privilege rigorously to all service accounts, including defaults, is paramount.
Supply Chain Risks Extend to Dependencies: Exploiting package installation mechanisms (like PyPI install scripts) is a classic supply chain attack vector, applicable even within cloud build processes.
Patching and Updates are Non-Negotiable: Google’s fix required users to update existing Composer environments. Delaying such updates leaves systems exposed to known, high-impact vulnerabilities.
Continuous Scrutiny is Needed: Even mature cloud platforms require ongoing security research to uncover these kinds of complex, inter-service vulnerabilities.

While Google has effectively patched ConfusedComposer, the underlying principles – understanding service interactions, minimizing default privileges, and securing dependency management – remain vital for maintaining a robust security posture in any cloud environment.

To further enhance your cloud security, contact me on LinkedIn Profile or [email protected]

Frequently Asked Questions (FAQ)

What was the ConfusedComposer vulnerability? ConfusedComposer was a privilege escalation vulnerability in Google Cloud Platform where an attacker with permission to update a Cloud Composer environment could install a malicious PyPI package, whose installation scripts would execute under the highly privileged default Cloud Build service account, allowing token theft and unauthorized access to GCP resources.
Why was the default Cloud Build service account involvement critical? The default Cloud Build service account often holds broad permissions across a GCP project (e.g., access to Cloud Storage, Artifact Registry, Cloud Build itself). By exploiting ConfusedComposer, attackers gained the privileges of this powerful account, far exceeding their initial limited permissions in Cloud Composer.
How did the attacker execute code? The attacker embedded malicious commands within the installation scripts (e.g., setup.py) of a custom PyPI package. When Cloud Build (triggered by Composer) used pip to install this package, these scripts were automatically executed within the Cloud Build environment.
When was ConfusedComposer fixed by Google? Google addressed the vulnerability by changing Cloud Composer’s behavior (using the environment SA instead of the default Cloud Build SA) as of April 13, 2025. The fix was rolled out to newer Composer versions, and existing environments were required to update by April 2025.
Who discovered the ConfusedComposer vulnerability? The ConfusedComposer vulnerability was discovered and responsibly disclosed by security researchers at Tenable, specifically credited to Liv Matan in the reports.

Resources