PyTorch AI PR review can treat attacker filenames as system text

PyTorch's automated AI pull-request review pipeline had a prompt-injection flaw: filenames chosen by a fork contributor could be echoed, unbound and unsanitized, into a channel the model treats as a system message.

The post-write validation hook builds an "additional context" block for the reviewer model. That block included a list of paths taken straight from the PR diff. Those names were not neutralized the way other dropped findings were, and there was no tight length bound on the joined text. A contributor can legally use long, sentence-like filenames (spaces, quotes, colons, and similar characters are allowed under the path checks). With a high cap on changed files, that adds up to tens of kilobytes of attacker-chosen prose framed as trusted hook output rather than untrusted PR data.

The injection path does not need the model to cooperate. Certain review drops, including findings about deleted, binary, or otherwise rejected paths, force the hook to print the full changed-file list. That stderr is captured and injected as system context for the next model turn. In effect, opening a pull request from a fork was enough to place chosen text outside the prompt's normal treatment of PR content as data.

Jean Schmidt flagged the issue for a fix. The practical risk is not remote code execution in the classical sense; it is subversion of an AI reviewer that maintainers may trust when triage and merge decisions lean on automated findings. Hardening would mean treating diff-derived paths as untrusted input: sanitize or drop them before they enter system-level context, and keep attacker-controlled bulk out of instruction channels.