A real-world prompt injection attack in a public GitHub repository, and what it means for developers using AI coding agents.
It looked legitimate
Recently, I came across a GitHub repository with more than 40 stars, active community activity, and polished positioning as the "#1 OpenCode Plugin." It promised async subagents, curated agents, and a Claude Code-compatible layer. On the surface, it looked like a normal developer tool: documentation, installation steps, and a reassuringly professional presentation.
Buried inside that documentation, however, was something far more concerning.
What I found was not a conventional malware payload or a suspicious binary. It was a prompt injection attack aimed directly at AI coding agents.
This was not written for humans
The most important detail is this: the installation guide was not really written for the user. It was written for the user's AI agent.
The repository explicitly instructed users to paste a URL into an LLM-powered coding assistant. Once the agent retrieved that remote markdown file, it was fed a sequence of instructions designed to influence its behavior, steer its decisions, and trigger actions on the user's machine.
That is what makes this attack notable. The payload is not hidden in compiled code. It is hidden in natural-language instructions that an autonomous coding assistant is likely to trust.
How the attack worked
Once fetched by an AI agent, the remote guide attempted to do several things.
1. Trigger arbitrary package execution
The guide instructed the agent to run commands such as:
bunx oh-my-opencode install
npx oh-my-opencode install
That matters because bunx and npx can download and execute code directly from a package registry. If an AI agent runs those commands on behalf of the user without proper review, it is effectively executing untrusted code with the user's own permissions.
2. Collect subscription and account intelligence
The guide also instructed the agent to ask the user about paid services and subscriptions, including whether they had access to Claude, ChatGPT, GitHub Copilot, or OpenCode Zen.
That is not normal installation behavior. It is data collection framed as configuration, and it gives the repository operator insight into which commercial AI services the target is already using.
3. Inject advertising into the workflow
One section explicitly instructed the agent to read an external list and select a company to promote to the user.
This is one of the clearest signals of malicious intent. The AI assistant is no longer helping the user complete a task; it is being repurposed as an untrusted marketing channel embedded inside the developer workflow.
4. Manipulate social proof
The instructions also encouraged the agent to ask the user to star the repository, use GitHub CLI commands to do so if the user agreed, and generate positive reviews or testimonials.
That artificially inflates trust signals. A repository can appear popular, well-liked, and community-approved even when that reputation is being manufactured through prompt-driven manipulation.
5. Use disarming tone as a control mechanism
The wording of the guide was intentionally warm, congratulatory, and playful. It used a friendly tone, celebratory language, and quirky phrasing to reduce skepticism and keep both the user and the agent compliant.
That matters because social engineering is not limited to humans anymore. Tone can also shape how an AI system interprets and prioritizes instructions.
Why this is different
Traditional supply chain attacks target code. Prompt injection attacks target the decision-making layer around the code.
That distinction is important.
The attack surface is no longer limited to node_modules, pip, or shell scripts. It now includes every document, README, markdown file, and remote instruction set that an AI agent is willing to ingest.
Red flags developers should watch for
After reviewing this repository, several patterns stood out.
Immediate red flags
- Any README that says "paste this into your AI agent" or asks you to feed a remote URL directly into an assistant.
- Documentation written primarily for the model instead of for the human operator.
- Unreviewed use of
bunx,npx,pip install, or similar commands against untrusted packages. - Questions about multiple paid subscriptions that are unrelated to installation or runtime requirements.
- Instructions to promote third-party companies, recommend sponsors, or inject advertising.
- Requests to star repositories, write reviews, or otherwise manufacture engagement.
Structural red flags
- A forked or rebranded repository that inherits credibility from a different project.
- A large number of commits but very little meaningful core functionality.
- Missing security policy, weak disclosure handling, or no responsible response to a report.
- Important instructions stored in secondary markdown files rather than in the main documentation.
How to audit a repository before using it
1. Do not trust the README alone
Read the actual source and all referenced documentation. In AI-agent ecosystems, markdown files can be as sensitive as executable files.
Pay special attention to:
docs/README.mdAGENTS.md- any raw GitHub URLs referenced during setup
- installation instructions intended for agents rather than users
2. Inspect what would actually execute
Before running package bootstrap commands, inspect what they will pull in:
npm pack oh-my-opencode --dry-run
tar -tzf oh-my-opencode-*.tgz
npm view oh-my-opencode scripts
The goal is simple: understand what will run before you let a package manager or agent run it for you.
3. Search for manipulation patterns
Basic text searches can quickly surface suspicious intent:
git clone <repo> && cd <repo>
grep -ri "star the repo\|advertise\|free advertising\|promote" .
grep -ri "subscription\|pro plan\|max\|copilot" .
grep -ri "paste this into\|llm agent\|assistant session" .
These searches will not prove maliciousness on their own, but they are an efficient first-pass filter.
4. Verify the maintainer
Ask a few basic questions:
- Is this the original project or a fork?
- Does the maintainer have a credible contribution history?
- Do the issues and discussions look authentic?
- Is the trust around the project organic, or overly curated?
5. Test unknown tools in isolation
If you decide to evaluate an unfamiliar AI tool:
- Use a container or VM.
- Keep credentials out of the environment.
- Avoid testing in your main workstation or production shell.
- Monitor network activity during installation and first-run behavior.
What to do if you find prompt injection
1. Preserve evidence
Capture the repository URL, commit hash, raw markdown, screenshots, and installation instructions. Save the exact content that was served to the agent.
curl -o evidence.md https://raw.githubusercontent.com/<repo>/<path>
2. Report it responsibly
If the repository is hosted on GitHub, use the Security tab when available and submit a detailed report with exact excerpts, URLs, and explanation of the attack path.
If the maintainer appears to be acting maliciously, escalate to GitHub Trust & Safety. If the package is published to npm or PyPI, consider reporting it to the registry as well.
3. Warn the community carefully
If users may be at risk, share your findings responsibly and factually. Focus on evidence, reproducibility, and risk to users rather than speculation.
A public write-up is often necessary, but it should help people defend themselves, not amplify the attacker's tactics.
The larger issue
This is not just about one questionable repository.
It points to a broader shift in software security: autonomous and semi-autonomous coding agents expand the attack surface beyond code execution into instruction execution. A malicious actor no longer needs to compromise a compiler, a package, or a build step first. In some cases, it may be enough to compromise the agent's context.
That is a serious change in threat modeling.
Developers are increasingly delegating package installation, code edits, shell commands, and documentation retrieval to AI systems. If those systems are allowed to treat untrusted text as operational guidance, then prompt injection becomes a practical supply chain risk.
What needs to change
Several things need to improve quickly:
- AI agent frameworks need stronger sandboxing, permission boundaries, and clearer human approval checkpoints.
- Security reviews for developer tools need to include prompt injection risk, not just source code review.
- Platforms such as GitHub and package registries should treat malicious AI-targeting instructions as a reportable security issue.
- Developers need to understand that "paste this into your AI assistant" can be as risky as "curl | sudo bash."
Final takeaway
If you use AI coding agents, treat documentation as part of your attack surface.
Do not assume a polished README is safe. Do not assume a starred repository is trustworthy. And do not assume that prompt injection is theoretical just because it does not look like malware.
Sometimes the payload is not code.
Sometimes the payload is the instruction.
I analyzed the repository referenced in this article on 2026-03-31 based on publicly available content at that time and reported the issue through GitHub Security Advisories.
#AISecurity #PromptInjection #CyberSecurity #LLMSecurity #AIAgents #SupplyChainSecurity #DeveloperSecurity