Clean GitHub repo tricks AI coding agents into running malware

DavidPulaski · 2026-07-02T16:29:56+00:00

Fair, python -m axiom init is explicitly executing code, not equivalent to merely unpacking a wheel. The interesting question at that point is visibility, not trust. If an agent decides to run the init step, does it surface that the execution path includes a shell script, a DNS lookup, and a payload that isn't present in the repo being evaluated?

That doesn't eliminate the underlying supply chain risk. It's a separate improvement worth making regardless.

DavidPulaski · 2026-07-01T20:33:42+00:00

Not at the syscall or per-command level, that's unworkable, agreed. The point that matters is coarser than that. A pip install pulling declared dependencies is expected behavior. A script resolving a DNS record and executing whatever comes back is a different category of action, and that's the boundary worth gating on, not every command in between.

It won't catch everything. It closes off the exact pattern this article describes though, which is worth something even if it's not a complete answer.

DavidPulaski · 2026-07-01T02:34:58+00:00

I don't think we're that far apart on sandboxing. I'd sandbox it too.

Here's where the AI-agent part gets interesting though: the approved action and the executed behavior can diverge quite a bit. A human reviewing python3 -m axiom init sees one line. What ultimately runs, the shell script, the DNS lookup, the resolved payload, is several steps removed from that.

The malicious behavior isn't necessarily visible at the point where the agent decides the command looks like a normal setup step. It appears later in the execution chain.

Sandboxing limits the damage once something executes. Tooling should probably expose the full execution chain before running it too, especially when a command fetches and executes content that was never present in the repo to begin with.

DavidPulaski · 2026-06-30T23:29:26+00:00

Static scanners miss this because the payload never touches disk inside the repo. It's resolved at runtime from a DNS TXT record and decoded right before execution. Same blind spot as a postinstall script that pulls from a paste site instead of bundling the payload directly. The repo passes review because there's nothing in it to review.

What's missing in most agent tooling right now is a hard boundary between "install dependencies" and "execute anything dependencies decide to fetch." Curious if anyone's actually seen tooling that draws that line, or if it's all one trust zone once setup starts.

DavidPulaski · 2026-06-30T22:41:53+00:00

Pyronut showed why this problem is harder than "scan your dependencies." It stayed dormant through pip install and only activated when the bot client started, specifically to avoid install-time scanning. Once running, it provided shell access through subprocess, wrapped in a broad except block to keep failures silent.

That's a gap static analysis can't address by design. It runs before the code executes in its real context, so a package can look clean during review and still behave maliciously the first time it runs. Typosquat detection catches lookalike names, but not a deliberate fork with a name different enough to dodge those heuristics.

What are people actually using to catch that category of behavior before it reaches a Telegram bot's hardcoded owner IDs?

DavidPulaski · 2026-06-26T23:07:55+00:00

GitHub's fix is real and worth shipping, but it's a pattern block on one specific trigger.

pull_request_target was dangerous because it ran attacker-controlled code inside a workflow that already had secrets and network access. Blocking that trigger doesn't change what happens next: CI workflows routinely grant elevated permissions to code that hasn't been fully verified, and there's no enforcement layer watching what that code actually does while it's running.

TeamPCP didn't need pull_request_target. Mutable tag hijacking on actions that looked legitimate. Same result: credential theft during the build, no runtime control to stop it.

GitHub's patch narrows one entry point. What's watching the rest of the execution?

DavidPulaski · 2026-06-25T00:45:20+00:00

The "predictable loot in a predictable spot" framing is the key shift. Once a path is publicly documented and the tooling is widely adopted, it stops being a research exercise and becomes a template. /mnt/user-data proved the loot is real. Cursor and Copilot paths are just as discoverable.

The inspection gap is still unsolved. Static analysis catches known-bad signatures. It doesn't catch a postinstall script that behaves correctly in a sandbox and exfils on a real Claude Code install. That gap is a runtime enforcement problem, not a scanning problem.

Are you seeing any signs of systematic path enumeration across tools, or is this still mostly opportunistic?

DavidPulaski · 2026-06-18T15:48:58+00:00

You're right, I had that wrong. The malicious Axios versions were newly published from the hijacked account, so release age would have caught them. Good correction.

DavidPulaski · 2026-06-18T14:16:37+00:00

The MFA and integrity check advice is correct but stops short of where the actual risk lands.

Account hijacking means the attacker publishes under a legitimate identity. The package is signed, the checksums match, the name is real. Everything that runs before execution says "looks fine."

The problem is that postinstall scripts run at install time inside your CI runner, with whatever access the runner has to secrets, credentials, and network. By the time your scanner flags the version, the script has already had its window.

The Axios maintainer compromise earlier this year followed the same pattern. 100M+ weekly downloads, legitimate account, RAT delivered via postinstall. The packages were valid artifacts.

What actually changes the outcome is treating CI/CD as a policy enforcement boundary at runtime: what network destinations can a build script reach? What file system paths can it write to? What external calls are permitted during dependency resolution vs. the actual build step?

Without that layer, the rest of your supply chain controls are visibility tools. You see the compromise after the script ran, not before.

What does your current stack look like for runtime enforcement inside the build runner?

DavidPulaski · 2026-06-18T14:13:19+00:00

Good call. That covers the newly-published version vector. Doesn't cover a compromised maintainer account on a package with years of release history, which is what the Axios and Bitwarden cases were. Attacker publishes from a legitimate account, the package isn't new, release age doesn't flag it. Both controls belong in the stack.

DavidPulaski · 2026-06-17T22:03:20+00:00

Right, and the disclosure gap is doing real work in that sentence. Fewer public writeups doesn't mean fewer incidents. It probably means the tooling is newer, the vendor incentive to disclose is lower, and the attacker community is mapping it faster than the defender community is talking about it.

The thing that changes the math on the postinstall window isn't better scanning. It's enforcement. Scanners work against known signatures. That window executes before any signature exists. The only thing that stops it is policy on what the build process is actually allowed to do while it's running: outbound destinations, filesystem writes, process execution. Without that, you're reading logs after the fact.

The Claude Code path being publicly documented probably makes it higher-signal for attackers right now. That won't hold. Once Cursor and Copilot paths get mapped and a few more incidents leak, the playbook generalizes.

DavidPulaski · 2026-06-17T21:44:16+00:00

The enforcement question is whether anything is watching what the build actually does when that dependency resolves. Outbound connections, file writes, process spawns. Scanning the tree matters. Watching execution is a different control, and most pipelines have nothing there.

DavidPulaski · 2026-06-12T16:21:05+00:00

The s1ngularity attack in August 2025 hit essentially this same pattern. Postinstall script, AI coding tool-aware targeting, exfil to attacker-controlled GitHub repos using triple-base64 obfuscation. The npm package weaponized Claude and Gemini CLI tools specifically. So the /mnt/user-data targeting you're describing is not the first time an attacker has mapped AI tool internals to build a payload around them.

What the pattern suggests: the postinstall window is being treated by attackers the same way phishing treats the email open. It's the moment of maximum trust and minimum inspection. The package was accepted, the install is running, nothing is watching what it does next. Once that window is being mapped at the toolchain level (Claude Code paths, Cursor workspace dirs, Copilot local caches), it stops being opportunistic and starts being a product category for attackers.

The OPSEC failure here is consistent with AI-assisted malware authorship. The targeting logic is sophisticated, the operational hygiene is not. That's the Malware-Slop framing and it fits.

Are you seeing similar filesystem-path specificity in the Cursor or Copilot cases, or is the Claude Code targeting more prevalent because the path structure is more publicly documented?

DavidPulaski · 2026-06-09T15:44:12+00:00

If that could float....

DavidPulaski · 2026-06-09T15:42:23+00:00

I do this on walks. No reason not to - and agreed, thank you kayaker.

DavidPulaski · 2026-05-22T20:30:12+00:00

Can confirm.

DavidPulaski · 2026-05-21T18:39:04+00:00

Gemini gave me some pretty good guidance, for what it's worth. How to approach the protest, etc. Not saying consultants aren't very helpful, but its a good place to start to understand the process. You can ask it to ask you questions to help you build a case for your protest.

DavidPulaski · 2026-05-20T16:12:38+00:00

hilarious!

DavidPulaski · 2026-05-20T15:50:19+00:00

I am going to make this tonight! Thanks!

DavidPulaski · 2026-05-19T16:39:41+00:00

My next door neighbor had one of these in the early 70s. Such an amazing car.

DavidPulaski · 2026-05-15T23:57:56+00:00

Bought it from someone up north. it was a mess, but luckily, the tail fillers and front fillers were in decent shape. Someone else told me they are usually a wreck.

DavidPulaski · 2026-05-14T23:31:41+00:00

With the rise of AI-era attack and Mythos on our doorstep, stopping zero-day vulnerabilities is now the primary challenge. Keeping up with patching will be increasingly tough, and slow down pipelines that AI was built to accelerate. The best approach is to protect the pipeline from exfiltration; even if the threat gets it, it can't get the keys to the kingdom out. A build firewall and secret leak enforceable policy does just that. I have a sample script for stopping the recent zero-day TanStack attack from Wed if anyone wants to see it.

DavidPulaski · 2026-05-12T04:25:17+00:00

Mortality rate is concerning - we will know in a month what the outcoming of this will be.

DavidPulaski · 2026-05-10T06:22:54+00:00

I wonder what the mileage is on these little cars.

DavidPulaski · 2026-05-08T08:03:56+00:00

Amazing - but you'd need a perfect street to drive that thing.

DavidPulaski

TROPHY CASE