ASCII smuggling: invisible Unicode characters now fooling anti-spam filters

From prompt injection to email campaigns

ASCII smuggling, already associated with prompt injection attacks against artificial intelligence systems, is now being used to reduce the effectiveness of anti-spam and anti-phishing filters.

The technique inserts normally invisible Unicode characters into words that remain readable to the recipient. Security software, however, may process a sequence that differs from what appears on screen. A suspicious word looks intact to a person but is split or altered during automated analysis.

Microsoft observed this evasion technique in Microsoft Defender for Office. Detections associated with ASCII smuggling rose rapidly: on a day in early February, they increased from roughly 21,000 to more than 1.3 million. Four days later, they had reached 2.5 million.

The activity continued for months before falling sharply in mid-May. The data also includes daily detections of Unicode signatures linked to finance-themed sender domains, monitored between February 9 and June 18, 2026.

The campaign has not been attributed to a specific group. The operators are described generically as spammers, with no indication of their origin or the infrastructure they used.

How invisible Unicode tags work

The method exploits a block of 128 Unicode tag characters that almost perfectly mimics a portion of the American Standard Code for Information Interchange, or ASCII.

These characters can be interpreted by computer systems but were designed to be almost completely invisible to humans. For example, code point U+E0041 represents the uppercase letter “A,” while U+E0061 corresponds to the lowercase “a.”

In attacks against applications based on large language models, tags can conceal instructions embedded in emails, documents, or other untrusted content. The user cannot see the command, but an AI agent may still process it and act on it.

In spam, the principle is reversed. The goal is not to hide an instruction from a person, but to prevent a filter from correctly recognizing a word that the user can still see.

The manipulated terms include dollar amounts and English words commonly found in financial offers, such as “credit,” “term,” and “funding.” These expressions can contribute to the risk score assigned to a message.

By inserting an invisible tag in the middle of “funding,” the word may appear normal on screen. The filter, however, may treat it as two separate segments: “fun” and “ding.”

One character cited in this context is U+E0020. When placed inside a string, its effect depends on how the system performs parsing, normalization, and tokenization.

Why AI classifiers can get it wrong too

ASCII smuggling does not challenge only regular expressions or checks based on exact string matching. It can also interfere with classifiers that use machine learning, natural language processing, and language models.

These systems do not necessarily analyze a sentence as a person sees it. Text is often split into tokens or sub-tokens, numerical units that the model uses to classify content.

An invisible character inserted in the middle of a word can produce several outcomes. The tokenizer might split “funding” into “fun,” the unexpected Unicode tag, and “ding.” It might also generate rare or unknown tokens that the model encountered infrequently during training.

In either case, a useful classification feature is lost. The model no longer receives the expected term, but an anomalous representation that may carry less weight in the risk assessment.

The result changes if the system normalizes the text before tokenization. By removing the invisible character, the filter may correctly reconstruct “funding.” Incomplete normalization, or normalization applied at the wrong point in the pipeline, leaves the evasion intact.

This is the central problem: the visual content and the underlying content do not match.

A defense based exclusively on the Unicode string analyzes what is encoded in the message. A recipient, by contrast, responds to what the email client displays. Comparing the two layers may require rendering the content and subjecting it to optical character recognition rather than relying solely on extracted text.

An evolution of techniques used for decades

Hiding words in unwanted messages is not new. For decades, spammers have inserted zero-width spaces, non-breaking spaces, and other special characters to alter the sequences examined by regular expressions.

Unicode tags, however, add a variant that some defenses may be less familiar with. Filters designed to catch more common forms of manipulation may not treat these codes as suspicious or removable elements.

The advantage is not limited to legacy text-based rules. Inserting tags can directly alter the representation supplied to ML and NLP models, shifting the problem from finding words to ensuring the robustness of the entire language-processing pipeline.

The same property had already made ASCII smuggling useful in indirect prompt injection. An AI application may ingest content from emails, websites, or documents and interpret instructions that the user cannot see. In anti-spam evasion, by contrast, the text is meant to be seen but not correctly recognized by the machine.

These are two different uses of the same discrepancy.

Impact and affected products

Microsoft Defender for Office is the product in which Microsoft detected the sharp increase in signatures. The issue, however, may affect email platforms, anti-phishing gateways, tokenizers, text analyzers, and ML- or NLP-based classifiers more broadly.

No other specific products or vendors have been identified. No affected versions, vulnerable builds, or particular exposed configurations have been disclosed.

This is also not a formalized vulnerability. There is no known CVE identifier, CVSS score, or severity classification; consequently, it does not have an entry in CISA’s Known Exploited Vulnerabilities catalog or a federal update deadline.

The impact depends on the role obfuscated terms play in the overall classification. ASCII smuggling does not by itself guarantee that an email will pass every check, but it can remove linguistic signals used to identify spam, financial scams, and phishing.

For recipients, the risk is tangible: fraudulent messages could reach the inbox even though they contain expressions that, without obfuscation, would have contributed to blocking them.

Making filters more resilient

Microsoft has provided design guidance to developers, but no specific software update or workaround for Microsoft Defender for Office is known.

Filters should first identify Unicode tag characters and other invisible elements, recording their presence as a possible obfuscation signal. Relying on a list of suspicious words is not enough.

Normalization must be controlled and consistent. Comparing the original text with the text obtained after removing or transforming invisible characters can be useful, but the process must not introduce new ambiguities.

The tokenizer’s behavior should also be verified. An increase in unknown, rare, or unexpected tokens inside common words may be a useful indicator, especially in finance-themed messages.

In higher-risk systems, comparing the underlying text with the content actually displayed may include rendering and OCR. This approach requires more resources but reduces the gap between what the filter analyzes and what the recipient sees.

Finally, rules should not focus only on individual words. The repeated presence of Unicode tags, combined with financial domains, payment requests, links, or other suspicious signals, provides a more robust basis for detecting abuse.

The wave observed by Microsoft shows that the technique is no longer confined to LLM security. It has become an operational tool in email campaigns, exploiting the same weakness: a machine can read text differently from the way it is displayed to a person.