Two Victims in Every Message: Barracuda Finds Phishing That Attacks the Reader and the AI Summarizer

2026-10-11 Agent & Supply Chain Security by al-ice.ai Editorial

On 7 October 2026, Barracuda Research published a Threat Spotlight by Guruprasad Kenja with an unusually honest title: Email attacks target both humans and AI in the same message. The campaign it analyzes pairs the oldest email trick in the book — a password-protected attachment with the password helpfully included in the body — with prompt injection hidden in the same message, aimed at the AI assistant that summarizes, prioritizes, and acts on the victim’s inbox. One email, two victims: the reader, and the software the reader trusts to pre-read mail for them.

Barracuda’s key takeaways, paraphrased: attackers are combining tactics to manipulate both human users and their email AI assistants in a single phishing email. Humans get social engineering such as password-protected attachments; AI assistants get prompt injections designed to influence or override user behavior. And the defensive conclusion follows directly: organizations must secure not only users and inboxes, but the AI systems that consume and act on email data.

The sample looked like internal mail

The dissected sample is built to survive reputation filtering. The “From” and “To” addresses match the same mailbox, the message carries a trusted spam confidence score, and it originates from a public sector domain. Each property lends perceived legitimacy, and together they help the message pass the reputation checks that would otherwise be the first line of defense. Nothing about the envelope asks the recipient to be suspicious — which is exactly what makes the second layer viable.

Layer one: the human gets the attachment

The first attack vector is familiar to email security professionals. The message appears routine and trustworthy: a legitimate-looking domain, a reference to a business process, a document attachment. The attachment is password-protected, and the password is conveniently provided in the email body — a tactic Barracuda flags as creating a blind spot for traditional email security controls, which cannot scan inside the encrypted file. If the user opens the attachment with the supplied password, the attack progresses to credential theft or malware delivery. This half of the campaign needs no AI involvement at all, and it would work in 2016 as well as 2026.

Layer two: the assistant gets the instructions

The second layer is the one that changes the economics. The email carries hidden malicious instructions — prompt injection — aimed at the AI assistant, not the human. If the user overlooks the email, the attacker does not lose: the injection manipulates the summary the assistant presents so that the phishing email is marked as legitimate or urgent, pushing the human to open the email and click. Read that twice. The assistant becomes a re-delivery mechanism for mail the human already ignored. The ignored phish gets a second hearing, this time vouched for by trusted software.

Barracuda describes a harder variant of the same layer: injection that hijacks the assistant’s response outright — instructing it to ignore its previous directions and instead send an urgent request to wire funds to a specified account, leak data, or surface a fake urgent action. None of these instructions are visible to the user. The human sees a helpful summary; the attacker sees an agent with mailbox context and, in the worst configurations, the ability to act on it.

Four ways to hide text from the human but not the model

According to Barracuda’s analysis, four concealment techniques recur in these attacks:

Hidden text in HTML comments. Instructions sit inside comment tags that never render in a mail client but remain in the raw source the AI parses.
Invisible CSS text. Zero-pixel font sizes, white-on-white color, or fully hidden styling: no visible space occupied, still present in the document the model reads.
Base64-encoded data. Instructions buried inside encoded blocks — Barracuda cites image data strings as an example — that an automated pipeline may decode and extract as text.
Zero-width characters. Invisible Unicode layered with normal text to smuggle or obfuscate content.

The concealment layer is converging across independent observations. On 3 September 2026, Microsoft Security Blog (research by Noam Kochavi and Sarah Wolstencroft) documented a high-volume phishing campaign repurposing invisible Unicode tag characters — the ASCII-smuggling technique popularized in AI prompt-injection research — for phishing evasion, emerging from Defender for Office 365 prompt-injection protection work. That is a distinct observation from Barracuda’s, not the same campaign, but it points the same direction: techniques developed to fool models are being operationalized against the mail pipeline, and techniques built for mail are being aimed at models. The hiding places overlap because the reader — human visual system versus tokenizer — is the only thing that differs.

Barracuda says this is already beyond the inbox

The post’s most consequential section is its set of real-world examples, because three of the four are not email triage at all:

Invoice fraud via summary. A hidden block in an invoice email instructs the summarizing model to add a fake priority action changing vendor payment details. The compromised summary nudges an employee toward wiring money to the attacker. The payload is a business-email-compromise outcome without any account takeover.
Resume screening. A candidate embeds hidden text telling the screening AI to rate them 10 out of 10 and recommend an immediate interview regardless of qualifications. An unqualified — or malicious — applicant advances. The target here is a hiring pipeline, and the attacker is the applicant.
Support bots. The attacker frames a request as an authorized maintenance or admin mode and asks the bot to reveal its own configuration. Same confused-deputy shape, different uniform.
Code assistants. Poisoned documentation on a webpage the assistant reads instructs it to insert a credential-exfiltration line every time it generates authentication code. This one lands closest to home for this site: it is the same failure mode as the Copilot CLI cryptographic-context-injection case, where hidden instructions the agent itself decodes survived validation and stayed reproducible — except here the injection ships inside third-party docs rather than ciphertext.

Our reading, not Barracuda’s claim: the mailbox is just the first host. The pattern is any AI that reads untrusted third-party content and acts on it — the inbox, the applicant tracker, the helpdesk, the IDE. Defenses scoped to “email security” will miss three of the four examples in Barracuda’s own post. Note the inverse symmetry with the Talos UAT-11985 campaign, where AI sat at the front (lure production) and humans operated the back (live MFA relay). Here the human is the front and the AI is the back — the assistant is the thing being socially engineered, at machine speed, inside infrastructure the victim owns.

What Barracuda does not claim

Carrying this correctly means noting its boundaries. The post names no threat actor, gives no campaign size or prevalence figures, publishes no IOCs, and assigns no CVE — there is none to assign. It is an analyzed campaign plus observed examples, not a measured trend, and should not be cited as one. The defenses section closes with a product pitch for Barracuda’s own layered controls; the research content stands without it, and so does our summary. The examples beyond email — hiring, helpdesk, code generation — are presented as attacks Barracuda has seen, but the post does not quantify them either.

What to do

Sanitize at ingestion, before the model. Strip HTML comments, hidden and invisible spans, and zero-width characters, and decode-and-inspect Base64 blobs in the pipeline — not via prompting. A control the attacker’s text can argue with is not a control.
Treat AI summaries of untrusted mail as untrusted content. Summary urgency must never substitute for opening the original. Flag cases where the summary’s priority contradicts headers and reputation signals — that contradiction is the detection.
Keep money and vendor-detail changes behind human approval outside the assistant loop. Any wire instruction or payment-detail change arriving via a summary gets verified through a second channel. The invoice example is BEC without the break-in; approve accordingly.
Sandbox the assistant to the task. A summarizer needs read access, not the ability to send mail, move money, or change records. Bind capability to the job, per task, and the wire-funds variant fails closed.
Validate outputs before they trigger actions, and log the attempts. Review AI-generated responses before they cause effects, and treat repeated injection attempts — especially retries against the same mailbox — as signal, not noise.
Enforce the data-only rule structurally. External content of any kind is data, never instructions. Where the platform allows it, that separation belongs in architecture — roles, schemas, tool permissions — not in a system prompt the next email can override. This is the same boundary EchoLeak violated in Copilot and Reprompt chained through deep links; the venue changed, the missing boundary did not.

Verification note: the campaign structure, the From/To and spam-score sample details, the two attack vectors, the four concealment techniques, the four real-world examples, the six defensive measures, and the data-only principle were read first-hand from Barracuda’s 7 October 2026 Threat Spotlight (page marked updated 6 October 2026). The Microsoft ASCII-smuggling details — 3 September 2026 post, the Kochavi and Wolstencroft bylines, the high-volume invisible-Unicode-tag phishing observation, and its Defender for Office 365 research origin — were read first-hand from the Microsoft Security Blog. The Infosecurity Magazine piece of 7 October was used only as a secondary pointer. The observations about re-delivery economics, the beyond-the-inbox pattern, and the Talos inverse symmetry are our editorial analysis. We executed no samples and reproduced no attacks. Unit 42’s March documentation of the first large-scale indirect prompt injection attacks in the wild remains the baseline this campaign extends: from live web content to the inbox itself.

Sources: