Notifications
Clear all
Topic starter
10/06/2026 11:58 pm
TL;DR: A Cursor vulnerability, CVE-2026-22708, lets trusted shell built-ins like export, typeset, and declare poison environment variables, bypass an empty allowlist, and turn benign commands into sandbox escape and remote code execution paths, according to Pillar Security researchers.
NHIMG editorial — based on content published by Pillar Security: The Agent Security Paradox, focusing on trusted commands in Cursor becoming attack vectors
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
Questions worth separating out
Q: What breaks when agentic IDEs rely on command allowlists for safety?
A: Command allowlists break when the dangerous behaviour sits in the environment, not in the visible command.
Q: Why do shell built-ins create a governance problem for AI agents?
A: Shell built-ins create a governance problem because they mutate process state without looking like ordinary external commands.
Q: How can security teams reduce environment poisoning risk in agent workflows?
A: Security teams should isolate agent execution state, monitor inherited variables, and treat runtime context as part of the approval decision.
Practitioner guidance
- Audit shell built-ins as privileged operations Inventory where agentic IDEs, shells, or automation layers allow export, typeset, declare, readonly, and unset to run without separate review.
- Separate command approval from environment approval Require explicit controls for inherited variables such as PATH, PAGER, PYTHONWARNINGS, BROWSER, and PERL5OPT before any trusted tool runs.
- Isolate agent execution state between steps Reset or sandbox process state between agent actions so one approved operation cannot prepare the next one.
What's in the full article
Pillar Security's full research covers the operational detail this post intentionally leaves for the source:
- Proof-of-concept command chains for zero-click and one-click exploitation across shell built-ins
- The exact environment variables and interpreter behaviours used in the attack paths
- Responsible disclosure timeline and the vendor's fix boundary
- Mitigation guidance on when allowlists still leave exposure open
👉 Read Pillar Security's research on trusted shell commands becoming agent attack vectors →
Agentic IDE shell built-ins: why allowlists are failing?
Explore further
12/06/2026 6:27 am
Agentic IDE trust models fail because they validate commands, not execution context. Cursor's allowlist logic focused on what the user could see, but the exploit lived in the shell state that built-ins silently changed. That means the control model was aimed at syntax while the attack used environment inheritance as the payload path. The implication is that agent security cannot be judged by command approval alone; runtime context is part of the identity surface.
A few things that frame the scale:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- Another 80% of organisations report their AI agents have already acted beyond intended scope, including unauthorised systems access, sensitive data sharing, and credential exposure.
A question worth separating out:
Q: What is the difference between approving a command and approving its runtime context?
A: Approving a command means the syntax is acceptable. Approving runtime context means the surrounding variables, shell state, and inherited execution conditions are also safe. In agentic systems, those are separate decisions, because a benign command can still become malicious when the environment has been poisoned beforehand.
👉 Read our full editorial: Agentic IDE trust assumptions collapse under shell built-ins
