AI coding-agent workflows built around Anthropic Claude Code, Google Gemini CLI, and OpenAI Codex can turn an outsider’s GitHub issue, pull request, or repository file into code execution or credential exposure when the workflow gives that content access to a trusted runner. The immediate action for administrators is to audit any agent-enabled GitHub Actions job that processes public contributions, then remove write-capable tokens and shared writable workspaces from that path until the workflow has been reviewed.
The research, presented by Novee Security founding engineer Elad Meged in his Black Hat USA 2026 session on August 5, describes a common failure in the harness around an AI model: one component treats repository content as untrusted, while a later component loads the same content as configuration, instructions, or executable state. That finding spans three vendors, but it is not one identical vulnerability with one patch. Google’s issue was patched in April, Anthropic’s assigned CVE describes an information-exfiltration channel rather than the claimed RCE chain, and OpenAI’s reported shared-workspace scenario does not currently have a public CVE or vendor advisory tied to it.
That distinction is more than bookkeeping. It determines whether an organization should upgrade a package, redesign a workflow, or do both.
A malicious issue body does not execute code by itself. The danger begins when a workflow hands that text to an agent that can invoke shell commands, inspect a checkout, call web tools, write files, or use a GitHub token. In the configurations Novee examined, an external contributor needed no repository privileges because the repository’s automation supplied the authority.
This is a familiar CI/CD security problem given a new control surface. GitHub Actions can run in response to issues, comments, pull requests, and workflow outputs. Adding a coding agent means that untrusted natural-language input is now interpreted by a system capable of taking actions. A prompt injection is therefore only the delivery method; the damaging step is a tool call, a configuration file load, a write to shared state, or a secret reaching the agent process.
The vendor documentation now reflects this risk plainly. Anthropic’s Claude Code Action documentation warns administrators against checking out an untrusted pull request into the workspace root before invoking the action in
Those are not theoretical cautions. They acknowledge that an agent can be routed around a narrow prompt-level permission policy by executable configuration and files that the surrounding tools consume.
The affected versions were:
For IT teams, a package upgrade is necessary but insufficient. A workflow that invokes Gemini CLI against fork-controlled code while exposing a powerful
A secure split is straightforward: run issue triage and pull-request analysis in a read-only job with no deployment or publishing credentials, then pass a constrained artifact or an explicitly reviewed result into a separate privileged job. Do not run an agent in the same job that both consumes a fork checkout and can publish a release, alter workflow files, or assume cloud roles.
That is a serious vulnerability, especially where Claude Code can read environment variables, command output, or sensitive files. It is also not described by the public CVE as remote code execution. The NVD description specifies data exfiltration through requests to attacker-controlled Hugging Face repository paths; it does not describe arbitrary runner commands.
There is a second discrepancy in the public record. GitHub, acting as the CNA, assigns CVE-2026-54316 a CVSS 4.0 base score of 6.0, Medium, while NVD lists a CVSS 3.1 score of 9.1, Critical. NVD has not yet issued its own CVSS 4.0 assessment. The scoring gap matters because it illustrates why “critical” cannot simply be copied from a roundup: the underlying advisory’s stated technical effect and NVD’s legacy score do not align cleanly.
Novee’s broader Claude Code Action research included other paths involving permissive command assumptions, file exposure, and workflow-secret handling. Anthropic’s current action documentation confirms that administrators must keep workflow permissions minimal, use scoped and short-lived tokens rather than personal access tokens, and treat an untrusted checkout as hazardous even where configuration files are restored from the base branch. The documentation further warns that project files such as
The practical outcome is that a Claude Code Action deployment should be reviewed as a complete runner program. Restricting
OpenAI’s own Codex technical documentation confirms that
No public OpenAI advisory or CVE located for this research currently establishes the precise reported chain, so the claim that OpenAI hardened its own internal workflow should be treated as Novee’s report rather than a published vendor disclosure. OpenAI’s current Codex Action documentation nevertheless points to the appropriate defensive model: use read-only execution where possible, prevent untrusted users from triggering privileged workflows, and recognize repository instruction files as attacker-controlled when operating on pull requests.
Windows administrators have a special operational concern here. OpenAI’s Codex Action documentation says GitHub-hosted Windows runners do not have a supported Codex sandbox and require
Administrators should immediately inspect for these conditions:
That distinction is more than bookkeeping. It determines whether an organization should upgrade a package, redesign a workflow, or do both.
The attack surface is the CI workflow, not the GitHub issue
A malicious issue body does not execute code by itself. The danger begins when a workflow hands that text to an agent that can invoke shell commands, inspect a checkout, call web tools, write files, or use a GitHub token. In the configurations Novee examined, an external contributor needed no repository privileges because the repository’s automation supplied the authority.This is a familiar CI/CD security problem given a new control surface. GitHub Actions can run in response to issues, comments, pull requests, and workflow outputs. Adding a coding agent means that untrusted natural-language input is now interpreted by a system capable of taking actions. A prompt injection is therefore only the delivery method; the damaging step is a tool call, a configuration file load, a write to shared state, or a secret reaching the agent process.
The vendor documentation now reflects this risk plainly. Anthropic’s Claude Code Action documentation warns administrators against checking out an untrusted pull request into the workspace root before invoking the action in
pull_request_target or workflow_run jobs. It also warns that its environment-secret scrubbing is best effort and does not remove prompt-injection risk. OpenAI’s Codex Action guidance likewise calls repository-controlled AGENTS.md, AGENTS.override.md, and related instruction files part of the untrusted-input surface when Codex works on pull request content.Those are not theoretical cautions. They acknowledge that an agent can be routed around a narrow prompt-level permission policy by executable configuration and files that the surrounding tools consume.
Google’s Gemini CLI flaw had a clear version boundary and a breaking fix
Google’s Gemini CLI case is the most concrete of the three because Novee published an affected-version range and patch levels after coordinated disclosure. According to Novee’s advisory, headless Gemini CLI runs previously trusted the working folder automatically, letting repository-controlled content influence configuration before normal sandbox protections were meaningful. The same research said the--yolo mode could bypass a configured fine-grained tool allowlist.The affected versions were:
- Gemini CLI releases earlier than
0.39.1and preview releases earlier than0.40.0-preview.3were affected. - The
google-github-actions/run-gemini-cliaction was affected before0.1.22.
--yolo.For IT teams, a package upgrade is necessary but insufficient. A workflow that invokes Gemini CLI against fork-controlled code while exposing a powerful
GITHUB_TOKEN, cloud credentials, package-registry tokens, or deployment secrets still has a risky design. The fixed CLI closes the reported automatic-trust and policy-bypass paths; it does not make it safe to give an agent broad credentials while it reads adversarial content.A secure split is straightforward: run issue triage and pull-request analysis in a read-only job with no deployment or publishing credentials, then pass a constrained artifact or an explicitly reviewed result into a separate privileged job. Do not run an agent in the same job that both consumes a fork checkout and can publish a release, alter workflow files, or assume cloud roles.
Anthropic’s CVE does not support the blanket “RCE” label
The Claude Code reporting needs a sharper reading than the headline provides. CVE-2026-54316 is real, affects Claude Code versions0.2.54 through 2.1.162, and is fixed in 2.1.163. But the public NVD record describes a pre-approved huggingface.co hostname in Claude Code’s WebFetch tool that could be abused as a covert out-of-band channel to exfiltrate data accessible to the agent after untrusted content had entered its context.That is a serious vulnerability, especially where Claude Code can read environment variables, command output, or sensitive files. It is also not described by the public CVE as remote code execution. The NVD description specifies data exfiltration through requests to attacker-controlled Hugging Face repository paths; it does not describe arbitrary runner commands.
There is a second discrepancy in the public record. GitHub, acting as the CNA, assigns CVE-2026-54316 a CVSS 4.0 base score of 6.0, Medium, while NVD lists a CVSS 3.1 score of 9.1, Critical. NVD has not yet issued its own CVSS 4.0 assessment. The scoring gap matters because it illustrates why “critical” cannot simply be copied from a roundup: the underlying advisory’s stated technical effect and NVD’s legacy score do not align cleanly.
Novee’s broader Claude Code Action research included other paths involving permissive command assumptions, file exposure, and workflow-secret handling. Anthropic’s current action documentation confirms that administrators must keep workflow permissions minimal, use scoped and short-lived tokens rather than personal access tokens, and treat an untrusted checkout as hazardous even where configuration files are restored from the base branch. The documentation further warns that project files such as
package.json, lockfiles, Makefile, .npmrc, and runtime configuration can still come from the pull request and be consumed by later tools.The practical outcome is that a Claude Code Action deployment should be reviewed as a complete runner program. Restricting
--allowedTools is useful, but it cannot compensate for an agent workspace that contains attacker-controlled tool configuration or a job token that can write to the repository.
Codex turns shared writable state into a trust handoff
The OpenAI Codex case reported by Novee is different again. The reported attack was a persistence chain: an earlier, lower-trust agent stage processes untrusted input and writes anAGENTS.md file into a shared checkout; a later, higher-trust Codex run then loads that file as operating instructions. In other words, the attacker does not have to make the first agent execute the final payload. They only need it to leave behind instructions that a later agent will treat as legitimate.OpenAI’s own Codex technical documentation confirms that
AGENTS.md and AGENTS.override.md files are collected from the project path and inserted into the agent’s user-instruction context. That makes the file a designed feature, not a bug. The security failure arises when one workflow stage is allowed to alter that instruction source and another stage receives more authority without getting a clean workspace.No public OpenAI advisory or CVE located for this research currently establishes the precise reported chain, so the claim that OpenAI hardened its own internal workflow should be treated as Novee’s report rather than a published vendor disclosure. OpenAI’s current Codex Action documentation nevertheless points to the appropriate defensive model: use read-only execution where possible, prevent untrusted users from triggering privileged workflows, and recognize repository instruction files as attacker-controlled when operating on pull requests.
Windows administrators have a special operational concern here. OpenAI’s Codex Action documentation says GitHub-hosted Windows runners do not have a supported Codex sandbox and require
safety-strategy: unsafe; Linux and macOS offer privilege-reduction and read-only options. That does not make Windows runners inherently compromised, but it removes a containment option that exists elsewhere. A Windows-based workflow should therefore avoid running Codex on public issue or pull-request content with credentials present, and privileged follow-on work should occur in a fresh job rather than the same runner session.The repair is architectural: separate authority from interpretation
The common lesson from Anthropic, Google, and OpenAI is that AI agent security cannot be reduced to whether the model rejects a malicious instruction. The agent is embedded in a chain of interpreters: GitHub event payloads, checkout contents, instruction files, package scripts, shell tools, configuration loaders, environment variables, and credentials. Any one of those can convert externally supplied text or files into privileged activity.Administrators should immediately inspect for these conditions:
- Any agent workflow triggered by issues, pull requests, comments, or artifacts from external contributors should run with read-only repository access and no cloud, signing, publishing, or long-lived API credentials.
- Privileged operations should run in a separate job with a fresh checkout, rather than sharing a writable directory, cache, or agent instruction path with an earlier untrusted stage.
AGENTS.md, Claude configuration, Gemini configuration, package-manager files, build scripts, and tool hooks should be treated as untrusted when they come from a pull request or contributor-controlled branch.- Personal access tokens should be removed from agent jobs in favor of narrowly scoped, short-lived credentials, with repository
GITHUB_TOKENpermissions declared explicitly. - Windows runner deployments should be reviewed first if they use Codex Action, because the documented action configuration requires its unsafe strategy on GitHub-hosted Windows.
References
- Primary source: cyberpress.org
Published: August 7, 2026 at 5:42 AM UTC
Loading…
cyberpress.org - Related coverage: novee.security
Loading…
novee.security - Related coverage: help.openai.com
Codex Security | OpenAI Help Center
help.openai.com
- Related coverage: openai.com
Loading…
openai.com - Related coverage: nvd.nist.gov
Loading…
nvd.nist.gov - Related coverage: cdn.openai.com
- Related coverage: deploymentsafety.openai.com
- Related coverage: labs.cloudsecurityalliance.org
Loading…
labs.cloudsecurityalliance.org - Related coverage: cdn.openai.com
- Related coverage: novee.security
Loading…
novee.security - Related coverage: github.com
Loading…
github.com - Related coverage: github.com
GitHub - openai/codex-action · GitHub
Contribute to openai/codex-action development by creating an account on GitHub.
github.com
- Related coverage: openai.com
Running Codex safely at OpenAI | OpenAI
How OpenAI runs Codex securely with sandboxing, approvals, network policies, and agent-native telemetry to support safe and compliant coding agent adoption.openai.com - Related coverage: docs.github.com
About GitHub Agentic Workflows - GitHub Docs
Automate repetitive repository work with natural language instructions executed by AI coding agents in GitHub Actions.
docs.github.com
- Related coverage: openai-codex.mintlify.app
Sandboxing - Codex CLI
Understand Codex's security model and platform-specific isolationopenai-codex.mintlify.app - Related coverage: techradar.com
Google Gemini security flaw could have let anyone access systems or run code | TechRadar
Having an allow-list in Gemini CLI caused a few issueswww.techradar.com - Related coverage: techradar.com
Google Gemini and GitHub are teaming up for AI-powered coding | TechRadar
Gemini CLI gets GitHub integrationwww.techradar.com - Related coverage: itpro.com
Developers warned to avoid 'early-access' Google Gemini tools | IT Pro
Attackers are tempting would-be users into downloading reverse shell malwarewww.itpro.com