Join our Newsletter — 33% off our NHI Course

Bidirectional Text Attack

A bidirectional text attack is the use of Unicode bidirectional control characters to make text display differently from how it is stored. Attackers can hide malicious code, alter file names or make source text look benign while preserving a different underlying sequence for parsers and reviewers.

What makes bidirectional text attacks deceptive

Unicode bidirectional control characters change the order in which text is rendered, so a string can look harmless to a reviewer while still containing a different underlying sequence for a parser, compiler, or file system.

This is not a formatting quirk, it is a trust problem. The same source can be interpreted one way by a human and another way by tooling, which makes the attack useful for hiding malicious logic, disguising file extensions, or making code review and approval decisions less reliable.

Where the attack shows up

Bidirectional text abuse is most often seen in code repositories, issue trackers, chat messages, and document workflows where plain text is copied into systems that later execute, parse, or display it. The danger rises when reviewers rely on what they see rather than verifying the raw bytes or Unicode code points.

Attackers may place control characters inside comments, identifiers, filenames, or surrounding text so that the visible order no longer matches the stored order. That can make a malicious line appear commented out, make a dangerous filename look like a harmless document, or create subtle review blind spots in pull requests and change-control queues.

Why this matters for security review

The core failure is a mismatch between presentation and substance. Reviewers, approvers, and automated checks may inspect the same artifact but not the same interpretation, especially when tools normalize, highlight, or truncate text differently.

That mismatch can undermine source-code review, incident triage, and content approval. In practice, the attack is most effective where organisations assume a text string is visually trustworthy, or where Unicode handling is not explicitly tested in developer tooling and downstream parsers.

Review pipelines should treat Unicode control characters as security-relevant input, not merely exotic text. The safest assumption is that any place accepting free-form text can become a display-versus-storage boundary.

Detection and prevention patterns

Defensive controls focus on making the invisible visible. Security teams should scan repositories and uploaded content for bidirectional control characters, reject them where they are unnecessary, and ensure editors, diff tools, and preview panes surface them clearly to reviewers.

Normalizing text alone is not enough if the resulting workflow still hides the underlying sequence from humans. Stronger practice is to pair input validation with review-time warnings, syntax highlighting that flags Unicode controls, and secure coding guidance for teams handling filenames, identifiers, or untrusted text.

For organisations that process source code or document attachments, the most useful habit is to verify both the rendered view and the raw representation before approving something that could change program behaviour or mislead operators.

Risk and Threat Considerations

Bidirectional text attacks are dangerous because they weaponize a basic human assumption: that text reads the same way it is stored. That assumption fails in code review, security approvals, and filename inspection, where the attacker benefits from the gap between display logic and parsing logic.

Failure mechanism: Unicode bidirectional controls alter visual ordering without changing the stored byte sequence in the way a reviewer expects, which can conceal malicious code or disguise a filename, comment, or label.

Impact: The result can be code review bypass, malicious file acceptance, hidden configuration changes, or operator misunderstanding that leads to unsafe execution or trust in a benign-looking artifact.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP ASVS V1 — Encoding and Sanitization Bidirectional text attacks exploit unsafe text handling and display encoding.
V16 — Security Logging and Error Handling Logging and review controls help surface suspicious text transformations and parse discrepancies.
Recommendation — Validate and sanitize Unicode input, and flag bidirectional control characters during review. Log rejected Unicode control usage and preserve evidence of malformed or deceptive text input.
NIST SP 800-53 Rev 5 SI-10 — Information Input Validation This attack relies on crafted text entering systems in a misleading form.
SI-7 — Software, Firmware, and Information Integrity Preserving reviewer trust in source text is an integrity concern for code and content workflows.
Recommendation — Reject or normalize hazardous Unicode controls before text reaches parsers or review workflows. Detect and prevent hidden-text manipulation that could alter approved content or code.
CIS Controls v8 CIS-16 — Application Software Security Secure development practices should account for deceptive text and source-review risks.
Recommendation — Add Unicode abuse cases to secure coding reviews and developer testing.

Practitioner Guidance

What to watch for: Treat any workflow that accepts free-form text as suspect when the text can later influence execution, parsing, or human approval. Bidirectional controls are especially important in developer tooling, ticketing systems, document management, and any path where reviewers make decisions from a rendered view.

Governance implication: Define whether Unicode control characters are permitted, where they are blocked, and which review tools must expose them. If a platform cannot make the raw sequence obvious to a reviewer, it should not be the sole source of truth for approval.