[Security] Potential agentic workflow injection risk in `.github/workflows/issue-labeler.yml`

Hi OpenAI team,

I would like to report a potential security issue in the Codex repository's GitHub Actions workflow:

.github/workflows/issue-labeler.yml

I previously submitted this issue through Bugcrowd, but the submission was marked as out of scope. I still believe the issue represents a meaningful security risk, so I am reporting it here publicly through a GitHub Issue. For ethical reasons, I will not disclose a working PoC or detailed exploitation payload in this public issue. However, I believe the issue is relatively easy to understand and verify from the workflow design itself, and I would be happy to provide additional details privately if needed.

Summary

The issue-labeling workflow in .github/workflows/issue-labeler.yml appears to incorporate untrusted GitHub issue content directly into an agentic prompt processed by openai/codex-action.
https://github.com/openai/codex/blob/fa127be25ff547c950240c4bfe6c100c394880b2/.github/workflows/issue-labeler.yml#L75-L79

And this workflow can be trigger by any non-write user.
https://github.com/openai/codex/blob/fa127be25ff547c950240c4bfe6c100c394880b2/.github/workflows/issue-labeler.yml#L26

Since issue titles and bodies are attacker-controlled input, this creates a potential Agentic Workflow Injection risk: an external user may be able to steer the Codex agent away from its intended issue-labeling task and influence its behavior during the GitHub Actions run.

The workflow then consumes the model-generated output and applies labels through an authenticated GitHub CLI step. As a result, attacker-controlled issue content may influence downstream repository automation, including issue classification and label application.

Security Impact

This issue can let an external attacker influence the automated issue-labeling workflow through attacker-controlled issue content. The impact is mainly twofold:

• Sandboxed code execution in the Codex action. The workflow places the issue title/body into the openai/codex-action prompt. In private testing, this allowed the issue content to steer Codex into executing commands inside its sandbox. While currently sandboxed, this is still a trust-boundary violation and could threaten the repository’s integrity if combined with a sandbox escape or runner-side weakness.

• Incorrect labeling and possible DoS. The workflow applies Codex-generated labels using an authenticated gh issue edit step. Therefore, attacker-influenced output can cause incorrect labels. Since the workflow also runs on the codex-label label event, attacker-influenced labeling may trigger repeated workflow runs or unnecessary resource consumption.

https://github.com/openai/codex/blob/fa127be25ff547c950240c4bfe6c100c394880b2/.github/workflows/issue-labeler.yml#L13

Suggested Mitigations

A safer design is to avoid directly interpolating the issue title and body into the Codex prompt. Instead, the workflow can pass only the trusted issue number to Codex and instruct Codex to retrieve the issue content itself through GitHub CLI, for example:

gh issue view "$ISSUE_NUMBER" --json title,body,labels

Responsible Disclosure Note

I am intentionally not including the concrete PoC payload here. My goal is to report the design-level risk without enabling abuse.

If the maintainers would like to investigate further, I can provide more detailed reproduction information privately.

Thanks for taking a look. I believe this is an important class of risk for agentic CI/CD workflows, even when the immediate impact may appear limited under the current sandbox and permission model.

Credit

Security PRIDE Research Group @security-pride