ConfusedComposer: How a GCP Privilege Escalation Flaw Exposed Cloud Composer to Takeover

A Critical Orchestration Misstep in Google Cloud. In March 2025, Tenable Research uncovered ConfusedComposer, a privilege escalation vulnerability in Google Cloud Platform (GCP) that allowed attackers to hijack the default Cloud Build service account via malicious PyPI packages in Cloud Composer. This flaw, now patched, could have enabled threat actors with basic permissions to seize control of entire GCP projects, escalating privileges to critical services like Cloud Storage, Artifact Registry, and Container Registry.

For DevOps and cloud security teams, ConfusedComposer underscores the risks of overprivileged service accounts in automated workflows a growing attack vector as enterprises adopt CI/CD pipelines, according to Tenable. Below, we dissect the exploit, Google’s response, and 10 critical mitigation strategies to prevent similar breaches.

Technical Breakdown: How ConfusedComposer Works

1. Cloud Composer & Cloud Build: A Primer

• Cloud Composer: A managed Apache Airflow service for orchestrating data pipelines.
• Cloud Build: GCP’s CI/CD platform for building, testing, and deploying applications.

2. The Vulnerability

Attack Vector:

1. Initial Access: An attacker needs only the composer.environments.update permission (common among DevOps roles).
2. Malicious PyPI Package: Attacker injects a rogue Python package into Composer’s environment configuration.
3. Abusing Pip Scripts: Pip automatically executes pre-/post-installation scripts in the package, allowing arbitrary code execution.
4. Token Theft: The code accesses the Cloud Build metadata API to exfiltrate the default Cloud Build service account token.

Impact:

• Full control over the Cloud Build service account (roles like cloudbuild.builds.editor, storage.admin).
• Lateral movement to other GCP services (e.g., deploying malicious containers, exfiltrating sensitive data).

3. Attack Workflow (Diagram Analysis)

1. Step 1: Attacker updates a Composer environment with a malicious PyPI package (e.g., malicious-package==1.0.0).
2. Step 2: Cloud Composer triggers Cloud Build to install the package.
3. Step 3: Pip executes attacker-controlled scripts during installation.
4. Step 4: Scripts extract the Cloud Build service account token via http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token.
5. Step 5: Attacker uses the token to impersonate the privileged service account.

4. Google’s Fix & Timeline

• Patch: Composer now uses the Composer environment service account (not Cloud Build’s) for PyPI installations.
• Rollout:
• New Environments: Patched as of March 2025.
• Existing Environments: Mandatory update by April 30, 2025.
• Documentation Updates: Revised guidance on Access Control and Python Dependency Management.

Broader Implications: The “Jenga” Attack Class

ConfusedComposer is part of Tenable’s Jenga® attack class, exploiting hidden misconfigurations in cloud service orchestration. Similar to 2024’s ConfusedFunction, it highlights how attackers abuse:

• Overprivileged Default Service Accounts: Cloud Build’s default account had excessive permissions.
• Implicit Trust in Automation: CI/CD pipelines often lack safeguards against dependency poisoning.

10 Mitigation Strategies for Cloud Security Teams

1. Enforce Least Privilege on Service Accounts

• Remove cloudbuild.builds.editor from default Cloud Build accounts.
• Assign custom service accounts to Composer with minimal permissions.

2. Audit PyPI Dependencies

• Use Artifact Registry or private PyPI repositories for internal packages.
• Scan public packages with Snyk or Dependabot.

3. Disable Metadata API Access

• Block metadata API access in Cloud Build via VPC Service Controls.
  “`bash
  gcloud compute instances add-metadata [INSTANCE] –metadata=block-project-ssh-keys=TRUE

4. Monitor Cloud Build Activity

– Enable **GCP Audit Logs** for `cloudbuild.builds.create` and `storage.objects.create`.
– Set alerts for unexpected builds or storage bucket changes.

5. Restrict Composer Permissions

– Limit `composer.environments.update` to trusted users via **IAM Conditions**. yaml
members: user:trusted-admin@domain.com
role: roles/composer.environmentUpdater
condition:
expression: resource.name.startsWith(‘projects/secure-project’)

6. Use Pip’s `–no-install` Flag

– Disable installation scripts in untrusted packages: bash
pip install –no-install malicious-package==1.0.0

7. Implement CI/CD Pipeline Guardrails

– Use **Binary Authorization** to block unsigned container deployments.
– Require **code reviews** for Composer environment changes.

8. Rotate Service Account Keys

– Rotate keys for default Cloud Build accounts monthly: bash
gcloud iam service-accounts keys rotate [KEY_ID] –iam-account=cloudbuild@project.iam.gserviceaccount.com
“`

9. Train DevOps Teams

• Educate on dependency confusion attacks and malicious PyPI packages.
• Simulate attacks via red team exercises.

10. Adopt Zero Trust for CI/CD

• Treat builds as untrusted; isolate them in Google Kubernetes Engine (GKE) sandboxes.
• Enforce VPC-SC perimeters around Cloud Build and Composer.

Conclusion: Securing the Automation Backbone

ConfusedComposer is a wake-up call for organizations relying on cloud orchestration tools. While Google’s patch mitigates this specific flaw, the broader Jenga attack class demands proactive defense:

1. Assume Defaults Are Dangerous: Always restrict service accounts.
2. Monitor the Unmonitored: CI/CD pipelines are prime targets—log aggressively.
3. Shift Left, But Verify: Automate security into DevOps workflows, but audit dependencies.

Final Checklist:

• [ ] Update all Cloud Composer environments by April 30, 2025.
• [ ] Audit service account permissions using IAM Recommender.
• [ ] Conduct a dependency review for PyPI/Artifact Registry.

🔗 Resources:

• GCP Composer Security Best Practices
• Tenable’s Jenga Research