Weekly Recon #8: Borrowed Trust

🎯 Attack of the Week: one GitHub issue against your Claude Code action

RyotaK at GMO Flatt Security, "Poisoning Claude Code: One GitHub Issue to Break the Supply Chain" [2026-06-01]

How it runs. Plenty of repos wire Anthropic's official claude-code-action into issue triage: tag the bot, Claude reads the issue, Claude replies. RyotaK turned that convenience into remote code execution from the outside, with no write access to the repo.

The opening is the issue body. He plants fake error-message text that reads like instructions, and when the action calls mcp__github__get_issue to fetch it, that text steers Claude toward running attacker commands. Reliable execution took more than the bare issue body, but the sink is a privileged CI runner. Indirect prompt injection, aimed at a build.

Firing the action on an attacker's issue meant beating the trigger guard. In agent mode the checkWritePermissions gate was built to keep untrusted actors out, but it waved through any GitHub App regardless of its real permissions, and a GitHub App can open an issue on a public repo without being installed. The untrusted-actor check passed for an actor holding zero write access.

From execution on the runner, the payload reads /proc/self/environ and lifts the OIDC request token and URL (ACTIONS_ID_TOKEN_REQUEST_TOKEN and ..._URL), then ships them out through mcp__github__update_issue. With those, the attacker runs the OIDC exchange and mints the Claude GitHub App installation token, scoped to the target repo with write to contents, issues, pull requests, and workflows. One issue on one public repo, filed by an actor with no permissions, reaches code-push on that repo; if the target is an action or package others depend on, the write propagates downstream. RyotaK reported around 50 separate vulnerabilities to Anthropic, and the fix shipped in @v1.0.94. CVSS 7.8. He reported it rather than pushing to Anthropic's own repositories.

The action is Anthropic's own, the one you trust to triage your issues. That trust is the entry point: it reads attacker-controlled text and runs on a privileged runner.

Ship This Week.

• Pin claude-code-action to @v1.0.94 or later. The patched trigger runs a checkHumanActor check that drops GitHub App actors.
• Strip issues: write, contents: write, and id-token: write from any workflow an untrusted issue or PR can trigger. An AI action that reads issue text is handling attacker-controlled input.
• Grep your workflows for allowed_non_write_users: "*". That wildcard is the door.

🔧 Defender's Corner: put a gate in front of your coding agent

Deploy a policy layer on your AI coding agent's tool calls. Leonardo Grasso at Falco, "Introducing Prempti: Falco meets AI coding agents" [2026-05-12].

Prempti puts Falco rules between Claude Code and execution. When the agent declares a tool call, Prempti evaluates it first and returns allow, deny, or ask. The default rules cover the moves worth catching: reads of ~/.ssh, ~/.aws, and .env, pipe-to-shell, IMDS access, reverse shells, MCP config poisoning, and git-hook persistence, some denied outright, others held for a prompt. Rules match on fields like tool.input_command and agent.cwd. So a custom rule that denies any tool call where agent.cwd sits outside your project root takes a few lines in ~/.prempti/rules/user/. Start in Monitor mode to watch what your agent does day to day, then flip to Guardrails to enforce the verdicts.

Grasso states the limit plainly: Prempti sees the tool call the agent declares, not the OS-level behavior it produces. A bypass that shells out underneath the declared call gets through. Still, the declaration point is exactly where an agent steered wrong by a poisoned config or a prompt injection shows its hand.

For your engineer: run Prempti in Monitor mode against your daily agent for a week and read what it logs before you enforce anything.

🤖 Agent Bench: hand the first dependency audit to an agent

This week's Attack ran attacker-controlled text straight through a coding agent. The agent you'd point at a sketchy dependency is the same kind of trusted primitive: it reads your creds and runs your shell, so audit the trust you extend to it the same way. You can't read every dependency's source by hand. An agent does the first pass in an hour. Treat the output as a head start and verify every claim before you act on it.

Scope the target precisely: the package, the exact version you install, the language and framework, and the install scripts in scope (preinstall, postinstall, and for Rust, build.rs). An undefined target gives you an undefined audit.

Ask the agent to surface, per dependency:

• Install-time and build-time scripts that touch the network or read ~/.aws, ~/.ssh, or .env. Those scripts are the classic supply-chain execution point, running before you ever import the package.
• A diff between the published artifact (dist/) and the source tag. Code in the package that the repo never had is the signal.
• For every hit, a source-to-sink trace: the entrypoint, the attacker-controlled input, the guard the model thinks is missing. A finding without that trace is a guess.

Run one check deterministically, outside the agent: grep your repos and agent config files (.cursorrules, CLAUDE.md, .claude/) for zero-width Unicode (U+200B, U+200C, U+200D, U+FEFF). The TrapDoor campaign used exactly this trick to smuggle instructions past you while your assistant read them. A grep beats a reading pass for exact-character hunts.

Honest caveat: agents over-report and fabricate reachability. They miss the mitigating check three lines up too. Your manual verification is the gate, never the agent's confidence.

What you walk away with: a ranked list of dependencies whose install path can reach your secrets, every finding at file:line, plus a clean-or-dirty verdict on hidden characters in your agent configs.

This is the oss-security-audit workflow, built for cloud security OSS.

Try it this week: pick one dependency your build pulls that you have never read. Pin the version, run the audit, and verify the top finding's source-to-sink trace yourself.

📡 Also on the Radar

Aniket Harne at Qualys, "The HazyBeacon Protocol: How Malware Weaponizes Amazon Web Services (AWS) Lambda Function URLs" [2026-06-02]. Qualys re-dissected the 2025 HazyBeacon campaign, and one mechanic carries the lesson. The implant beacons to a Lambda Function URL set to AuthType: NONE. That endpoint lives on an on.aws domain, so the channel inherits AWS's reputation and reads as routine encrypted HTTPS on the wire. The relay Lambda logs metadata for the operator and forwards the payload to a backend server. Harne's defender moves: an SCP that blocks creating Function URLs with AuthType: NONE unless policy-approved, org-wide CloudTrail, and a watch on Lambda cost anomalies that flag a function running as a message relay. The uncomfortable part for any AWS shop: your own trusted domains make the best cover for C2.

💼 Recon Roles

Security Infrastructure Engineer, Product Security at Tailscale. Remote, posted as two listings, one for the United States ($163,000 to $226,000 USD) and one for Canada (CA$218,420 to CA$302,840). Scope covers cloud-platform security with an AWS lean, Go preferred, plus Kubernetes, CI/CD, and infrastructure audits that drive remediation. Read it as hands-on infra-and-codebase security. You are expected to write security fixes into the product and audit the cloud underneath it, so it suits an engineer who codes. Two listings with public ranges in both currencies make this a rare opening you can compare straight across the border.

The pattern across the issue: infrastructure you already rely on is carrying authority you granted once and never re-checked. Audit the trust you have already extended.

Know someone who'd want this in their inbox? Forward it to them.

Full post with source links: defensive.works/recon/p/008

// end of issue 008

Sponsored content may appear below.