GitHub Issue Tricks Google Bot Into Privileged Fix

Researchers found that a public GitHub issue in Google’s ADK repository could be written in a way that manipulated an AI “triage” bot into posting a privileged command. Because the command appeared to come from a trusted bot collaborator, it could trigger a higher-privilege workflow that could run code and access sensitive credentials in CI.

Key findings

• A public GitHub issue could be used to prompt-inject an AI triage agent into posting a privileged workflow command.
• The privileged workflow gate validated the commenter identity (trusted bot) rather than whether the bot was manipulated by untrusted issue content.
• Researchers demonstrated CI runner code execution and token/credential exposure in a proof-of-concept, but did not claim in-the-wild exploitation.
• Google removed the affected workflows after the report, noting they processed untrusted issue/PR content using broad repository credentials.

Who’s being targeted

• Commonly targeted roles: Software Engineering, DevOps/CI-CD Owners, Open-source Maintainers, Security Engineering, Platform Engineering.
• Affected industries: Software development, Open-source / developer tooling, CI/CD and DevOps.
• Attack channels: github.
• Impersonated: A normal external contributor opening a GitHub issue (untrusted public user), `adk-bot` (trusted collaborator identity).

Awareness takeaways

• Treat public issues/PRs as untrusted input, don’t let them directly drive privileged automation without strong controls.
• Don’t rely solely on “who posted the command” checks when bots can be manipulated; add safeguards that untrusted content cannot generate.
• Minimize bot and CI credentials (separate identities, narrow scopes) so a single workflow can’t expose high-impact secrets.
• Assume agent tools can be abused for code execution even when command allowlists exist; restrict write capabilities and review tool configs.

Red flags to watch for

• A public issue can trigger automation that has powerful credentials.
• Workflow authorization is based on who posted a command (a bot) rather than who influenced it.
• Untrusted text is being fed directly into an agent that can take actions.
• Privileged workflows can be triggered by simple comment commands.
• Bot accounts may be treated as trusted collaborators without additional verification.
• CI jobs may carry cloud keys/tokens that are exposed if the job is abused.