Notifications
Clear all
Topic starter
20/08/2026 5:59 pm
TL;DR: Attackers can hide malicious logic in source code and prompts using Unicode variation selectors, private-use characters, bidi controls, and tag characters, making the bytes differ from what reviewers see, according to Cycode. The core security issue is not exotic encoding, but the collapse of human review assumptions when scanners and policies do not inspect raw text.
NHIMG editorial — based on content published by Cycode: Invisible Code & Hidden Prompts - How Attackers Weaponize Unicode in Repos (and How SAST Can Help)
Questions worth separating out
Q: How can security teams detect invisible Unicode abuse in development workflows?
A: Run Unicode scanning in pre-commit and CI, render non-printing characters during review, and block files that contain bidirectional overrides or unexpected control ranges.
Q: Why do invisible Unicode attacks create risk for AI-assisted development?
A: AI systems consume text streams, not the visual appearance of a file, so hidden characters can change the effective prompt or instruction set.
Q: What breaks when code review relies only on rendered text?
A: Rendered text can hide bidi controls, zero-width characters, and private-use bytes that alter meaning without changing appearance.
Practitioner guidance
- Enforce Unicode character allowlisting Block bidirectional controls, variation selectors, zero-width characters, and private-use code points in source, markdown, and prompt files before merge.
- Add raw-byte inspection to code review Require diff tooling that shows both rendered text and underlying bytes for high-risk file types, especially agent instructions, configuration, and copied snippets.
- Scan prompt repositories like application code Treat agent prompts, instruction files, and repository markdown as controlled assets with the same scanning, approval, and change tracking expected for code.
What's in the full article
Cycode's full blog post covers the byte-level examples and scanner behaviour this post intentionally leaves for the source:
- Hexdump walk-throughs that show exactly how variation selectors, PUA code points, and bidi controls appear in raw file content
- Concrete examples of how invisible characters behave in editors versus compilers and tokenizers
- The SAST detection approach Cycode describes for flagging suspicious Unicode sequences in repositories and pipelines
- Manual viewer and detector references for confirming whether a suspicious file contains hidden text
👉 Read Cycode's analysis of invisible Unicode attacks in repositories and prompts →
Invisible code and hidden prompts: are your repo controls keeping up?
Explore further
20/08/2026 6:38 pm
Invisible text is a supply chain control problem, not a formatting oddity. The article shows that attackers can weaponize the gap between rendered text and raw bytes to change what reviewers think they approved. That makes source repositories, prompt files, and markdown assets part of the software supply chain attack surface. The practical conclusion is that byte-level inspection belongs in the same control set as code review and dependency checking.
A question worth separating out:
Q: What should teams do when invisible Unicode is found in prompts or repo files?
A: Quarantine the file, inspect the raw bytes, and confirm whether the characters are intentional and documented. If the content is meant for production, require re-creation from a trusted source rather than hand-editing around hidden characters. Then update pipeline checks so the same pattern is blocked automatically next time.
👉 Read our full editorial: Invisible Unicode attacks in repos expose a new review blind spot
