Cloud Build TOCTOU Flaw: How a GitHub Race Condition Bypassed CI/CD Security
Share this article
The GitHub CI/CD Time Bomb: Dissecting Cloud Build's TOCTOU Vulnerability
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.
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
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