The GitHub CI/CD Time Bomb: Dissecting Cloud Build's TOCTOU Vulnerability

Article illustration 1

When Google Cloud Build introduced its "/gcbrun" comment feature to prevent unauthorized pipeline execution, it seemed like a robust defense against poisoned pull requests. But beneath this safeguard lay a subtle race condition—one that could let attackers execute malicious code in protected CI/CD environments by exploiting milliseconds-long timing windows. This $30,000 vulnerability reveals how interconnected cloud services create novel attack surfaces where traditional security assumptions fail.

Anatomy of a Pipeline Bypass

Google Cloud Build’s GitHub integration uses app webhooks to trigger CI jobs on repository events. For pull requests from untrusted contributors, its "comment-control" feature requires a maintainer to explicitly approve execution via a /gcbrun comment—a guardrail against malicious code injection.

The flaw emerged from Cloud Build’s workflow: When a maintainer commented /gcbrun, the system queried GitHub’s API for the latest commit SHA to build. This created a critical Time-of-Check-Time-of-Use (TOCTOU) gap: An attacker could push malicious code after the approval comment but before Cloud Build fetched the commit, hijacking the pipeline.

Article illustration 5

Diagram showing the race condition between maintainer approval and attacker code injection

Weaponizing Milliseconds

Researcher Adnan Khan proved the exploit by:
1. Creating a benign PR with README changes
2. Configuring a polling script to detect /gcbrun comments every 200ms
3. Preparing a malicious cloudbuild.yaml file with secret-exfiltrating commands

When a maintainer approved the PR:

GH_TOKEN=`gh auth token` python3 actions_toctou.py --target-pr 2 --repo VictimAccount/test \
--fork-repo AttackerAccount/test --fork-branch test3 --mode comment \
--search-string "/gcbrun" --update-file cloudbuild.yaml --update-path cloudbuild.yaml

The script immediately pushed malicious code, and Cloud Build executed it—bypassing review. Attackers could thus steal credentials, abuse IAM roles, or compromise artifact repositories.

Why Google Paid a $30,000 Bounty

The vulnerability struck at Cloud Build’s core security promise. As Khan noted:

"Google uses Cloud Build extensively on public repositories—most projects require comment control by default. A single compromised account could escalate privileges across inner-source ecosystems."

This was especially critical for:
- Organizations using inner-source development models
- Public repos with external contributors
- Pipelines with elevated cloud permissions

Google's Ingenious Fix

The patch addressed both technical and human factors:
1. 5-Second Commit Aging: Cloud Build now only builds commits older than 5 seconds at approval time, nullifying quick pushes
2. SHA Locking: If new commits arrive post-review, maintainers must specify the exact SHA to build, preventing accidental malicious execution

Article illustration 2

Comment-control interface showing SHA verification requirements

Attempts to bypass via sub-second races or Git timestamp forgery failed—the check-binding design resisted manipulation.

The Unseen Risks in CI/CD Choreography

This exploit underscores insidious truths about modern DevOps:
- GitHub’s event limitations (like PR comments lacking commit SHAs) force secondary API calls that introduce risk
- Human approval workflows become attack surfaces when decoupled from immutable artifacts
- Cross-service timing dependencies create vulnerabilities invisible to single-platform testing

As Khan concludes: "Always map approvals to immutable references. Your CI/CD pipelines must withstand both malicious actors and well-intentioned mistakes." For developers, this means auditing pipeline triggers for similar TOCTOU gaps—especially where human interaction meets automated execution.


Source: Cloud Build TOCTOU Vulnerability by Adnan Khan