New Vulnerability in GitHub Copilot, Cursor: Hackers Can Weaponize Code Agents

Nature of the exploit

• Core concern: attackers can hide arbitrary instructions in plain text (e.g., “rules” files) using invisible or bidi Unicode so that GitHub UI and typical editors don’t show them.
• LLM-based code agents still “see” and follow these hidden instructions, letting attackers steer generated code (e.g., injecting script tags, insecure patterns).
• Some argue the real root issue is the ability to hide text in files; others say that even without Unicode tricks, prompt injection against agent systems is inherent and will just find other vectors.

Are LLMs “vulnerable” or just script engines?

• One view: this isn’t an LLM bug; feeding malicious prompts and getting malicious output is analogous to running an attacker’s shell script with bash.
• Another view: LLMs fundamentally lack separation between “data” and “commands,” so they are intrinsically risky when exposed to untrusted input.
• Some compare this to past data/command-channel confusions (e.g., modem escape sequences).

Human vs LLM susceptibility and context

• Several commenters note LLMs are far easier to “socially engineer” than humans: they follow quoted or hypothetical instructions that humans would ignore.
• Suggested reasons: LLMs are optimized to be maximally helpful, have short “context windows,” and lack stable long-term context or meta-awareness of “this is just an example.”

Trust, review, and real-world practice

• One camp: the scenario is overblown—no one should merge AI-generated code without careful review; AI output should be treated like untrusted code from the internet.
• Others respond that in reality many developers commit/merge with cursory review, large diffs, time pressure, and hidden or subtle issues often slip through anyway.
• Concern: adding a “malicious actor on the developer’s shoulder” will statistically increase bad code in production, even with scanners and reviews.

Adoption and hype of AI coding tools

• Article’s “97% of developers use AI coding tools” is criticized as misleading: the underlying survey only says they’ve tried them at some point.
• Commenters note some companies force-install AI assistants, inflating “adoption,” while many hands-on developers either rarely use them or don’t trust them for serious work.
• Debate over whether AI coding is truly “mission-critical” or mostly autocomplete-plus.

Who counts as a developer?

• Long subthread on whether “vibe coders” who mostly prompt LLMs are real developers, paralleling “is a person who commissions art an artist?” or “bridge via LLM → structural engineer?”
• Some emphasize outcomes and tool use (“if you ship software, you’re a developer”), others distinguish professional responsibility/credentials from merely orchestrating tools.

Mitigations and tooling ideas

• Proposed defenses:
  • Preprocess/sanitize inputs to agents; restrict to visible/ASCII characters for some use cases.
  • IDEs, lexers, or languages that explicitly reject or flag control characters and tricky Unicode.
  • Repo tooling / GitHub Actions to scan for invisible Unicode in rules/config files.
• Recognition that any “instruction hierarchy” or sandbox approach can only partially help; in security, less than 100% robustness is still exploitable.

Vendor responses and security discourse

• GitHub and Cursor’s “user responsibility” stance is seen by some as technically correct but practically weak, given they market “safe” AI coding environments.
• Others argue this is an attack vector, not a vulnerability in their products per se.
• Some criticism that the security blog hypes the risk to promote its own relevance, reflecting a broader trend of sensationalism in security marketing.

Broader reflections

• Several commenters are happy to see more fear around AI coding, hoping it keeps developers skeptical and preserves demand for people who can actually read and reason about code.
• Worries about long-term bloat and quality: if AI makes it trivial to generate boilerplate and mediocre code, codebases may get larger, slower, and harder to secure.
• Miscellaneous gripes about the article’s UX (hijacked scrolling, floating nav) reinforce the sense that modern tooling often prioritizes flash over usability and robustness.