Notifications
Clear all
Topic starter
05/07/2026 6:57 pm
TL;DR: Hidden prompt injections in GitHub READMEs can steer Cursor into exfiltrating secrets, bypassing denylisted commands, and executing attacker-chosen actions through seemingly ordinary coding workflows, according to HiddenLayer. The core problem is that agentic code assistants can be manipulated through trusted content and permitted tools, so governance must extend beyond prompt hygiene.
NHIMG editorial — based on content published by HiddenLayer: How Hidden Prompt Injections Can Hijack AI Code Assistants Like Cursor
Questions worth separating out
Q: What breaks when hidden prompt injection is allowed in AI code assistants?
A: The assistant can treat attacker-controlled text as instruction, then combine file access, command execution, and output channels to steal secrets or carry out unsafe actions.
Q: Why do AI code assistants create new secret exposure risk for IAM teams?
A: Because they sit close to source code, environment files, local shells, and developer credentials.
Q: How do security teams reduce the impact of prompt injection in code assistants?
A: They should reduce the assistant’s ability to move from reading to executing to sending data.
Practitioner guidance
- Constrain assistant tool paths by capability class Group tools into read, write, execute, and exfiltration-sensitive classes, then require separate approval for any path that crosses classes.
- Treat repository content as untrusted input Review READMEs, comments, issue text, and setup files as potential prompt carriers before an assistant processes them.
- Separate secret discovery from secret exposure Ensure assistants can detect sensitive material without being able to transmit it.
What's in the full report
HiddenLayer's full research covers the operational detail this post intentionally leaves for the source:
- The exact attack chain used to move from hidden README text to secret discovery, blocked-command bypass, and exfiltration.
- The control-token and instruction-hierarchy abuse that let the malicious content override the assistant’s intended behaviour.
- The tool-level analysis showing how permitted functions were composed into a working exfiltration path.
- The disclosure and patch timeline for the reported Cursor vulnerabilities.
👉 Read HiddenLayer’s research on hidden prompt injection against Cursor →
Hidden prompt injection in code assistants: what teams need to know?
Explore further
05/07/2026 7:20 pm
Hidden prompt injection is a governance failure, not just a model safety issue. The article shows that attacker-controlled repository text can become operational input once an assistant is allowed to interpret and act on it. That collapses the boundary between content and instruction, which is exactly where traditional developer-tool trust models become fragile. Practitioners should treat every external project artifact as a potential control input.
A few things that frame the scale:
- 15% of commit authors have leaked at least one secret in their contribution history, according to The State of Secrets Sprawl 2025.
- HiddenLayer’s scenario sits inside a broader secret-exposure problem: 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
A question worth separating out:
Q: How should organisations govern AI assistants that can run local commands?
A: They should govern them like privileged machine identities with bounded authority, not like ordinary productivity software. That means defining who can enable execution mode, which repositories are eligible for tool use, and what evidence is required before an assistant can touch local credentials or system commands.
👉 Read our full editorial: Hidden prompt injection can hijack AI code assistants like Cursor
