Google Cloud Build Vulnerability Enables Data Destruction Across Projects

Researchers at Cisco Talos have uncovered a critical vulnerability in Google Cloud Platform's Cloud Build service that could allow attackers to delete or encrypt data across multiple projects with minimal permissions.

The flaw stems from overly permissive default settings, which is how many public cloud vulnerabilities start.

In a detailed blog post published today, Talos researchers demonstrated how an attacker with only the ability to create and run Cloud Build jobs could potentially delete entire storage buckets or encrypt objects using customer-provided keys. The attack leverages the default service account permissions granted to Cloud Build, which allow it to execute any gcloud command the service account has access to.

"There are legitimate business use cases for every capability and default permission that we utilized for malicious intent," the researchers noted. "This research should be taken as an instructive illustration of the risks posed by these capabilities for cloud administrators who may be able to limit some of the features that were misused if they are not needed in a particular account."

The vulnerability can be triggered through seemingly innocuous actions like creating a pull request on a connected GitHub repository. In their proof-of-concept, the Talos team was able to delete a Google Cloud Storage bucket and all its contents by simply submitting a malicious Cloud Build configuration file via a GitHub pull request.

"A threat actor could perform these techniques either by obtaining credentials for a GCP user or service account or by pushing or merging code into a repository with a Cloud Build pipeline configured," the researchers explained.

I’ve seen this sort of attack before, my friend Marcus Young was printing bug bounty checks with his method a few years ago even on sites as big as Facebook. You can read how he abused Github Actions to get full root into the PyTorch ci runners.

While Google has not classified this as an official vulnerability, the potential for abuse is there. An attacker exploiting this flaw could destroy or hold for ransom large amounts of data across multiple projects and applications tied to the same Cloud Build pipeline.

Attack Scenarios:

1. Data Destruction: By leveraging the “storage.*” permissions family, an attacker could delete entire storage buckets and their contents. They could even bypass Google's "Soft Delete" feature by immediately recreating a bucket with the same name after deletion.

2. Data Encryption: In buckets without object versioning enabled, an attacker could encrypt objects using a customer-provided key they control, effectively holding the data for ransom.

Google's documentation does warn users about some of these risks, recommending manual approval for builds triggered by pull requests. However, the Talos team found that many organizations may not be following these best practices.

"There may be real world scenarios where a valid business case exists to allow automatic build events when a PR is created," the researchers noted. "This is why a proper defense in depth strategy should include monitoring the events performed by any Service Accounts assigned to Cloud Build."

How to mitigate:

1. Create anomaly detection models for unusual actions performed by the default Cloud Build service account.

2. Apply the principle of least privilege by assigning Cloud Build a lower-privileged service account with only necessary permissions.

3. Review configurations for repositories that can trigger Cloud Build jobs.

4. Require manual approval for builds triggered by pull requests.

5. Avoid allowing direct commits to repositories without pull requests.

6. Enable object versioning and soft delete features for Google Cloud Storage buckets.

What to Look For in Google Operations Logs:

One of the most straightforward ways to spot suspicious or malicious activity related to Cloud Build is by monitoring Google Operations Logs. Even when an attacker leverages default permissions to perform destructive or otherwise unauthorized actions, Google Cloud still generates logs that defenders can examine. Here are the key log events and their significance:

1. google.devtools.cloudbuild.v1.CloudBuild.RunBuildTrigger

   • What it means: A build was created automatically in response to some kind of trigger, such as a pull request (PR) or commit to a repository.

   • Why it matters: Although this is common in normal CI/CD workflows, it is useful during investigations to identify when, how, and by which repository or branch a build was triggered. On its own, this event is usually not a sign of malicious activity, but it’s a critical log for tracing the chain of events if something suspicious occurs later.

2. google.devtools.cloudbuild.v1.CloudBuild.CreateBuild

   • What it means: A build was created manually—often via a direct command using the gcloud CLI or the Cloud Console. This log will typically show which user or Service Account initiated the build.

   • Why it matters: A threat actor may trigger builds manually if they have compromised credentials. You can use this event to see if a large number of build-creation attempts were made (potentially suggesting an attacker testing different commands or permissions). It can also help detect if logs are being sent to a suspicious external bucket (e.g., a bucket you don’t recognize).

3. storage.buckets.delete

   • What it means: A Cloud Storage bucket was deleted.

   • Why it matters: Malicious actors frequently destroy data to cover their tracks or cause impact. If the entity performing the bucket deletion is the default Cloud Build Service Account—or any unexpected Service Account—this should raise a red flag. While some automated processes may legitimately delete temporary buckets, defenders should monitor for unusual patterns or timings (especially if a deletion is followed by a re-creation of the bucket).

4. storage.buckets.create

   • What it means: A new Cloud Storage bucket was created.

   • Why it matters: On its own, creating a new bucket is routine. However, if it directly follows a storage.buckets.delete event for the same bucket name, it could indicate an attempt to bypass “Soft Delete” or “Object Versioning” protections. Attackers may delete a bucket, then immediately create a new one with the same name to prevent the old data from being recovered.

The discovery of this vulnerability follows similar research by Orca Security earlier this year, which identified a related "Bad.Build" attack vector in Cloud Build. While Google addressed some specific issues raised by Orca, the broader risks associated with CI/CD pipelines in cloud environments remain a concern for security professionals.

Google has not yet issued an official response to the Talos findings. However, the company typically encourages responsible disclosure and works to address security concerns raised by researchers. Cloud administrators are advised to review their Cloud Build configurations and implement the recommended mitigations ASAP.