The proposed fix concerns GitHub Actions privilege separation in a repository for an AI coding tool. A workflow_run job can receive secrets unavailable to a fork pull request, but checking out and executing scripts from that PR inside the privileged job can bridge the boundary. The PR is a source-level warning and mitigation proposal, not evidence that a…
Inspect the ClaimsCase · DiggingBeagle record
Gemini CLI CI workflow proposal flags privileged secrets exposed to fork-controlled build steps
A proposed CI change identifies a workflow path where a privileged job with Gemini API credentials may execute code from an untrusted fork.
An open source PR describes the risk; no verified credential theft or completed fix release is established.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- not established
- Evidence
- Grade D
- AI role
- AGAINST AI
Basis and provenance
The pinned Claim and its primary disclosure support the described controlled result, but do not establish a population-wide rate or calibrated impact. The only available supporting evidence is the reporter's or advisory author's own account; independent reproduction has not been shown. Impact remains unbanded because no calibrated impact rubric for this particular evidence is established.
Assessed Nov 2, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-2026-NOV02-GEMINI-CLI-FORK-WORKFLOW-SECRET-A · Gemini CLI pull request 30090: chained e2e workflow secret boundary
At a glance
Event-level trust does not automatically make checked-out code trusted; secrets must remain outside fork-controlled execution.
Read the implicationsAn open source PR describes the risk; no verified credential theft or completed fix release is established. The supplied PR does not by itself prove that a secret was actually exfiltrated or establish an independently verified fixed release.
Limits and uncertaintyFull account
The proposed fix concerns GitHub Actions privilege separation in a repository for an AI coding tool. A workflow_run job can receive secrets unavailable to a fork pull request, but checking out and executing scripts from that PR inside the privileged job can bridge the boundary. The PR is a source-level warning and mitigation proposal, not evidence that a malicious contributor already exfiltrated a Gemini key. The important approval and executable-bytes distinction applies to agentic project CI as well as conventional automation.
A workflow can be safe at the initial untrusted PR checkout but unsafe when a privileged follow-on job consumes the same fork-controlled code or installation scripts. The linked pull request proposes separating GEMINI_API_KEY from operations that can execute contributor-controlled content. The relevant risk is a crossing between GitHub Actions privilege domains, not a model spontaneously revealing a secret. The PR is evidence of a reported workflow concern and proposed change; it does not establish that an attacker obtained the credential.
Mechanism and trust boundary
- 01
Untrusted contributor opens a PR
A fork supplies repository content and potentially install scripts.
Boundary: Untrusted code into CI trigger
- 02
Privileged follow-up workflow runs
The chained job has access to repository-held Gemini API credentials.
Boundary: Fork context into credentialed runner
- 03
Execute fork-controlled files
Build or install steps may reach code under attacker control.
Boundary: Unchecked source into secret-bearing execution
Claims & evidence
CLM-2026-NOV02-GEMINI-CLI-FORK-WORKFLOW-SECRET-AGemini CLI PR 30090 describes a chained_e2e workflow_run job with GEMINI_API_KEY exposed while checking out or installing fork-controlled PR content.supported
Basis: reported finding
- supportsGemini CLI pull request 30090: chained e2e workflow secret boundaryprimary disclosure
Pull request 30090, workflow_run event and checkout/install order
Implications
Event-level trust does not automatically make checked-out code trusted; secrets must remain outside fork-controlled execution.
Controls and mitigations
- Separate privileged reporting from untrusted builds, pin trusted checkout refs and remove AI API keys from PR-controlled lifecycle steps.
- Run fork-supplied code only without privileged repository secrets, and make the trusted publishing stage consume immutable artifacts rather than executing fork scripts.
Unknowns and contradictions
- An open source PR describes the risk; no verified credential theft or completed fix release is established.
- The supplied PR does not by itself prove that a secret was actually exfiltrated or establish an independently verified fixed release.
Sources and citation
Material revision history
- Nov 2, 2026 · Canonical change recorded · new in release · revision 214