A recently resolved security flaw in Google Cloud Composer could have allowed adversaries with limited access rights to escalate their privileges dramatically — ultimately seizing control of powerful service accounts and unlocking broad access across a GCP project.
The issue was rooted in Google Cloud Composer, Google’s managed workflow orchestration platform built atop Apache Airflow, widely used for automating and scheduling complex data pipelines.
At the heart of the vulnerability was the way Cloud Composer handled its integration with Google Cloud Build, GCP’s native CI/CD tool. Specifically, the risk emerged from Composer’s mechanism for installing custom Python (PyPI) packages within its environments — a process that, if exploited, opened the door to privilege escalation.
GCP Cloud Composer Privilege Escalation Risk Uncovered
When users configured custom PyPI packages, Cloud Composer would quietly trigger a build workflow, during which the Composer service account spun up a Cloud Build instance inside the user’s project without additional user interaction.
According to researchers at Tenable, who shared their findings with Cyber Security News, this automation exposed a gap:
“An attacker with the composer.environments.update permission could manipulate this process to escalate their privileges within the environment,” they noted.
The exploitation method revolved around crafting a malicious PyPI package and embedding it into the target’s Composer custom package setup, enabling unauthorized control during the build phase.
GCP Composer Privilege Escalation
Deep Dive Into the Technical Attack Chain
The attack strategy took advantage of Pip — Python’s package manager — and its behavior of running scripts automatically during the installation and setup of packages.
Tenable’s researchers showed that, by leveraging these scripted hooks, an attacker could run arbitrary code inside the Cloud Build environment. This execution was possible even without having direct access to the Composer service account itself, creating a powerful escalation opportunity.
Privilege Escalation Mechanics in GCP Composer
The escalation vector was triggered when the malicious code tapped into the Cloud Build metadata API to retrieve an access token tied to the service account.
Because Cloud Build instances operate under a default service account with expansive access — including permissions across Cloud Storage, Artifact Registry, Container Registry, and other critical resources — attackers could leverage this token to move laterally and escalate privileges across the compromised GCP project.
To address the issue, Google revised Cloud Composer’s approach to handling custom PyPI package installations.
“Following the fix, Composer no longer relies on the Cloud Build service account for these operations. Instead, it now utilizes the environment-specific Composer service account,” Tenable’s researchers explained.
The mitigation has already been applied to newly created Composer environments, and existing ones are slated for automatic updates by April 2025.
In tandem with the patch, Google has enhanced Composer’s documentation, offering clearer guidelines around Access Control, Python Dependency Management, and Airflow CLI usage to boost user awareness and tighten operational security.
This vulnerability fits into what Tenable terms a “Jenga” class of attacks — a category that builds on previous GCP privilege escalation flaws like “ConfusedFunction,” also uncovered by Tenable.
These types of exploits highlight the risks associated with complex service orchestration and underscore how misconfigured or overly permissive service accounts can create dangerous openings across automated cloud systems.
Ultimately, the findings reinforce the need for strict identity and access management (IAM) practices in cloud environments, particularly within pipelines where numerous interconnected services are operating behind the scenes.
