Barracuda Research described "double" phishing emails that attack both the human and the AI assistant reading their mail simultaneously: the mailbox owner sees an attachment with a password, while a hidden layer is addressed to the language model, pushing it to present the email as legitimate and urgent, up to false priority actions like changing supplier details. Malwarebytes analyzed this threat in an article dated October 12, 2026, and advises checking the original email before taking any action, limiting assistant permissions, and always having humans confirm payments.

image

What Happened

Barracuda Research published a description of a campaign on October 7, 2026, in which a single phishing email carries two different messages. The first is addressed to the human: the email looks like a standard work message, containing a password-protected attachment, with the password duplicated directly in the email text to make it easier for the recipient to open. The second is addressed to the AI assistant that reads this mail and prepares summaries: the email contains hidden prompt injection instructions placed in HTML comments, invisible CSS text, encoded in Base64, and further obscured by Unicode zero-width characters. The goal of the hidden layer is to make the assistant describe the email as legitimate or urgent and add to the list of priority actions what benefits the attacker, such as changing supplier details. Malwarebytes released an analysis of this threat on October 12, 2026, along with protection recommendations, and the topic is actively discussed on Hacker News.

Context

This technique belongs to the class of indirect prompt injection, where instructions for the model are hidden inside the data it processes: until recently, such attacks remained primarily laboratory demonstrations, and the novelty of the situation is that the mechanics were observed in real email campaigns. The vulnerability here is not in a new capability of models, but in the gap between what a human sees on the screen and what the assistant receives as raw text: ingestion pipelines in many products feed the email to the model as is, along with all invisible markup layers, instead of first converting it to a visible display. In such a configuration, the assistant acts as a trust amplifier: an email that a human would calmly ignore becomes a "recommendation" with a priority action after an AI summary, and the mailbox becomes an entry surface for attacks on agents working with email.

Why This Matters for the Industry

Organizations that have already launched assistants over corporate email should correctly assume that a product without input sanitization and with action permissions is vulnerable by default. The practical minimum, implementable by a team without involving a new vendor: do not feed raw HTML to the model, strip HTML comments and invisible CSS text, normalize Base64 and zero-width characters before feeding them to the model, cancel automatic actions based on emails, and make human confirmation mandatory for any payments using a human-in-the-loop scheme. For assistant and AI summarization vendors, including Copilot, this is a signal that input data sanitization, prompt injection detection, sandboxes, and output validation must be built into ingestion as part of the product itself, rather than remaining a configuration option. In a broader perspective, protecting agents working with email, from middleware using a "email, then cleaned digest for agent" scheme to systems for detecting emails with a dual audience, looks like a forming separate product category.

Why This Matters for Users

If you use an AI assistant for email summaries, the main risk is that phishing you would ignore yourself might be turned by the assistant into a priority "recommendation" with a call to action, and the most dangerous zone here concerns emails about payments and details. Before taking any action with money or data, open the original email, not just its AI summary, and consider the assistant's output a hint, not a verification: the model reads hidden markup that a human cannot see, and that is exactly why it becomes a new target. Confirm changes to supplier and counterparty details through a separate trusted channel, such as a known phone number of the organization. Limit the assistant's permissions: disable automatic actions based on emails if the product allows it, and do not give it the ability to process payments without your confirmation.

What Is Still Unknown / Limitations

Publications by Barracuda Research and Malwarebytes describe a demonstrated case but do not contain methodologies, datasets, or metrics: it is unknown how often models actually execute such injections, which products are affected, and what the accuracy of possible detection is. Available data shows no signs of mass exploitation against products, so this is currently threat research, not a report of a large-scale incident. The claim that detecting specific techniques like zero-width characters or Base64 is technically simple remains a product hypothesis, not an evaluation result, and the fight against hidden layers is adversarial by nature, as attackers can complicate obfuscation. Predictions that vendors will quickly build sanitization and hidden layer detection into ingestion and that public robustness benchmarks for email assistants will appear should be read as the expectations of the analysis authors, not as confirmed facts.

Sources

Author

Look at AI, editorial team