Invisible Unicode Moves From AI Attacks to Spam Evasion

Introduction

A text-obfuscation technique once associated mainly with prompt-injection attacks against AI systems is finding a new audience: spammers. ASCII smuggling hides characters inside Unicode text that is almost invisible to people but still processed by software. The result is a message that looks normal to a recipient while presenting a very different sequence to an email filter.

Key points

• The hidden characters come from a Unicode tag block. The 128-character range mirrors part of ASCII. For example, U+E0041 represents “A” and U+E0061 represents “a.” Computers can process the characters, while humans generally cannot see them.
• The objective has changed. In earlier AI attacks, the characters concealed instructions intended for a language model reading untrusted content. In spam campaigns, the same mechanism is used to disguise words, currency amounts, and other signals associated with unwanted messages.
• Microsoft saw a substantial spike. Detections in Microsoft Defender for Office rose from roughly 21,000 per day to more than 1.3 million at the start of February 2026. Within four days, they reached 2.5 million, remained elevated for months, and then dropped sharply in mid-May.

Why filters can miss the message

A spammer might insert an invisible character into “funding.” The recipient still sees the complete word, but a literal search could encounter “fun” and “ding” instead. The problem becomes more complicated when the filter relies on machine learning or natural-language processing. Such systems often tokenize text into words or subwords before classification. An unexpected Unicode character can turn a familiar token into several unusual pieces, unknown tokens, or a sequence that the model has not learned to associate with a financial lure.

The general idea is not new. Zero-width spaces and non-breaking spaces have long been used to defeat literal searches and regular expressions. Unicode tags are attractive because some filters may not yet handle them explicitly, and because they can disrupt both exact matching and model input. A system that only analyzes the underlying text may also fail to match what a person actually sees; reproducing the visual message and applying OCR is one possible, though more expensive, defense.

Security implications

The immediate lesson for email-security developers is that character handling must be part of the detection pipeline. Filters should identify invisible and unusual Unicode characters, compare text before and after safe normalization, and examine whether tokenization changes the meaning of important terms. High-risk messages may also require a visual rendering check.

The broader lesson is about technique transfer. A representation trick first used to hide instructions from AI models can be repurposed to hide spam indicators from the systems protecting those models and their users. As machine learning becomes more central to email filtering, defenses must account not only for the character sequence a classifier receives, but also for the message a human ultimately reads.

Source: Ars Technica AI