Borrowed Trust.
Three stories this week, one shape. A single GitHub issue, filed by a stranger with no write access, turns the official Claude Code Action into code execution on a CI runner and a write-scoped token on the targeted repo. A command channel riding out through an on.aws Lambda URL that reads like every other AWS call on the wire. And an experimental policy layer that now intercepts a coding agent's tool calls before they run. The primitive you already trust is the attack path.
> New here? Get next Tuesday's issue in your inbox.
🎯 Attack of the Week: one GitHub issue against your Claude Code action
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 into running attacker commands (it took extra prompting to make reliable). Indirect prompt injection, except the sink is a privileged CI runner. 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 back 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.
- Pin
claude-code-actionto@v1.0.94or later. The patched trigger runs acheckHumanActorcheck that drops GitHub App actors. - Strip
issues: write,contents: write, andid-token: writefrom 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.
In-issue poll: Does an issue or PR comment trigger an AI coding action anywhere in your repos? (Yes / No / Not sure)
🔧 Defender's Corner: put a gate in front of your coding agent
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
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) · 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.
Both listings verified open as of 2026-06-09. Roles can close anytime. No affiliation or payment. Found one already closed? Reply and tell me.
Closer
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.
Agent Bench and Recon Roles are the two newest sections here. What would you want more of from them? Reply and tell me, I read every one.
Know someone who'd want this in their inbox? Forward it to them.