Noma Security researchers just demonstrated something that should unsettle any engineering org running autonomous coding agents: a single public GitHub issue, containing nothing but ordinary-looking text, can trick GitHub Agentic Workflows into leaking the contents of an organization’s private repositories. No stolen credentials. No insider access. No exploit chain. Just an issue, opened by anyone, on a public repo the attacker doesn’t even need permission to write to. It’s the kind of finding that should reframe how security teams think about cybersecurity as agentic tooling spreads through the software supply chain, because the vulnerability isn’t a bug in the traditional sense. It’s the permission model working exactly as designed.

The Incident: A Text Box Became an Exfiltration Channel

Here’s the mechanics, and they’re worth sitting with. GitHub Agentic Workflows let organizations wire up AI agents to read across their repositories, often to triage issues, summarize pull requests, or answer questions using context pulled from the codebase. Convenient. Also, apparently, catastrophic when the agent has been given read access across an org’s entire repo footprint and can’t reliably tell the difference between “content to summarize” and “instructions to follow.”

An attacker opens a completely public, completely mundane issue on a repository the org already exposes. Buried in that issue is prompt injection: text crafted to manipulate the agent into pulling data from private repositories it has access to and posting it somewhere the attacker can retrieve it, often right back into the public issue thread or a comment. The agent isn’t compromised. It’s doing exactly what it was told, by a source it had no reason to distrust, because nothing in its threat model separates “trusted maintainer instruction” from “arbitrary public text.”

This is the same failure mode threat researchers have been flagging for months in MCP tool poisoning and agentjacking cases, but this one is notable because the attack surface is a public GitHub issue. It’s about as close to zero-cost, zero-skill exploitation as this class of attack gets. Anyone with a browser and a free GitHub account can attempt it against any org running an over-permissioned agent.

Why Your Perimeter Never Saw This Coming

Traditional threat detection is built around a fairly simple assumption: bad things arrive from outside, and good things happen from inside. A firewall watches for anomalous connections. Brute-force protection watches for repeated failed logins. Incident response playbooks assume a compromise event, a foothold, lateral movement. None of that applies here. The “attacker” never authenticates as anything other than a public GitHub user filing an issue, which is a completely legitimate, expected action on a public repository. The exfiltration happens over an API call the agent was authorized to make, using credentials the agent was authorized to hold. There’s no anomaly to catch because nothing about the request pattern looks wrong from the outside.

That’s the uncomfortable throughline connecting this to Cisco Talos’ latest research on UAT-7810, a threat actor that’s been steadily building out custom malware for its ORB (Operational Relay Box) network rather than relying on off-the-shelf tooling. Different attack, same underlying shift: adversaries are increasingly building infrastructure and techniques that live inside the trust boundary instead of trying to smash through it. UAT-7810 doesn’t need to beat your firewall if it can route traffic through a chain of relay boxes running its own malware and blend in with what already looks like normal network noise. The GitHub issue attacker doesn’t need to beat your access controls if the agent will happily hand over the data on request. Defense in depth stops meaning “more layers at the edge” and starts meaning “assume every internal actor, human or agentic, needs its own scoped, monitored trust boundary.”

Security Hardening for Agentic Workflows: What Actually Works

If your org has any agentic workflow with cross-repository or cross-system read access, treat that agent like a privileged service account, because that’s exactly what it is. A few concrete steps that hold up regardless of which agent platform you’re running:

• Scope agent permissions to the specific repository or workflow context that needs them; never grant org-wide read access by default just because it’s the easiest checkbox.
• Treat any externally-sourced text, issues, PR descriptions, comments, commit messages, as untrusted input, and configure agents to flag or refuse instructions embedded in that content rather than executing them silently.
• Log every agent action with the same rigor you’d apply to a human admin account: what was read, what was written, and where the output landed.
• Route agent output through a review or approval step before it reaches anywhere externally visible, especially public issues, comments, or repos.
• Run periodic access reviews on agent tokens and integrations the same way you audit human offboarding, because agent permissions rot and expand quietly over time.

None of this requires exotic tooling. It requires treating agentic access as a first-class identity in your incident response and security hardening program instead of a background convenience feature nobody reviewed after initial setup. If your team already runs brute-force protection on exposed admin panels or self-hosted CI runners, something like IPBan Pro handles that layer well, but it’s worth being honest that this particular attack sails past brute-force defenses entirely. The problem here isn’t unauthorized login attempts. It’s authorized access being manipulated into doing the wrong thing.

The Broader Pattern Security Teams Keep Missing

Zoom out and the pattern is consistent across both stories: attackers are getting better at operating entirely within systems that were built to trust them, whether that’s an ORB network hiding inside legitimate-looking relay traffic or an AI agent following instructions it was never supposed to trust. Threat detection tuned for external compromise indicators is going to keep missing both. The fix isn’t a better firewall rule. It’s rebuilding the assumption that internal actors, human, service account, or agentic, deserve unconditional trust just because they’re already inside the perimeter.

Cybersecurity teams that treat agent permissioning as an afterthought are going to keep finding out about incidents like this one from a researcher’s writeup instead of their own logs. The organizations that get ahead of it are the ones auditing agent scope now, before the next public issue turns into the next disclosure.

Sources

• Public GitHub Issue Could Trick GitHub Agentic Workflows Into Leaking Private Repo Data
• UAT-7810 continues building ORB networks using new malware