Yes. Researchers showed that Unicode bidirectional control characters can reorder how source code is displayed without changing how it is compiled, so a reviewer sees one thing and the compiler runs another. A pasted snippet or a docs code block can carry such characters unseen.
What the research showed
The Trojan Source research describes attacking the encoding of source files rather than inserting a visible logic bug. The trick is to use Unicode control characters to reorder tokens at the encoding level. Compilers and interpreters follow the logical order of the characters. Editors and review screens may show the visual order. In the project's own example, a comment can be made to look like code, or code can be made to look like a comment, so logic that appears harmless on screen behaves differently when run.
The attack pattern is tracked as CVE-2021-42574. The researchers point out that it matters most in supply chains: if a targeted change slips into open source code past human reviewers, downstream software inherits it.
The defence they recommend is mostly for tool makers. Compilers, interpreters and build pipelines should raise errors or warnings for unterminated bidirectional control characters in comments and string literals, and for identifiers mixing confusable scripts. Editors and repository front ends should make those characters visible.
Why docs and tutorials are a delivery path
A code block in a tutorial is rendered text. A reader copies it with a button or a selection and pastes it into a terminal or editor. If the source of that block contains invisible characters, they travel with the copy. Reviewers of the docs pull request see only the rendered picture.
This is not common, and no one should panic about every snippet. It is cheap to check, so it belongs in the routine for anything copied from outside your own team.
How to check a snippet
- Paste the text into an editor that can display control characters, or a plain text view that shows them.
- Search for characters outside the printable ASCII range in a block that should be plain ASCII. A byte level search flags them.
- Run the same check on files in a sample repository before merging a contribution.
- Be suspicious of identifiers that look identical but differ in script.
- Prefer tools and editors that warn on bidirectional characters, and keep them updated.
# List lines containing any non ASCII byte in a file
grep -nP '[^\x00-\x7F]' snippet.txt
What docs teams can do
| Control | Where it runs | What it catches |
|---|---|---|
| Non ASCII check on code blocks | Docs build | Hidden control characters in examples |
| Visible whitespace and control view | Reviewer's editor | Characters the render hides |
| Warnings in the compiler or linter | Sample project CI | Unterminated bidirectional characters |
| Contributor guidelines | Repository | Sets the expectation up front |
Legitimate non English text is fine in prose. For code blocks that should be plain ASCII, a failing check is a cheap prompt to look closer.
Try it yourself
Static analysis is one place such checks can live. Click through a scan to see what a code finding looks like.
Click through it at your own pace, or open it full screen.
Safeguard's code and dependency scanning, plus policy gates on pull requests, give your team a checkpoint before changes merge. You can also run the free scan at https://gold.safeguard.sh/scan. See also the hidden risk of copy pasted code snippets.
Quick check
Will a code editor always show these characters?
No. That is the point of the research. Some editors and review screens render the visual order, so use a view that shows control characters.
Does this only matter for open source?
No. Any text you copy into code, including docs and chat answers, can carry them.
Sources
Last reviewed: 19 October 2026.
