ChatGPhish: When the AI Assistant Becomes the Phishing Surface

Most phishing research asks how to make a message convincing. The work that Permiso Security published in May 2026 asks a stranger question: what if the message does not need to be convincing at all, because it appears inside software the user has already decided to trust?
The researchers called the technique ChatGPhish. The name is a pun, but the finding is not a joke. It describes a repeatable way to get phishing content, including live links, spoofed security warnings and scannable QR codes, to render inside a ChatGPT response. The user never receives a suspicious email. They ask their assistant to summarise a web page, and the summary quietly carries the attacker's payload.
What ChatGPhish is
ChatGPhish is a disclosed attack technique in which hostile content placed on a web page is carried into an AI-generated summary of that page, causing attacker-controlled links, images and alerts to appear inside the trusted assistant interface. Permiso's principal researcher, Andi Ahmeti, described it as a cross-site prompt injection attack. Permiso reported the underlying issue to OpenAI through the Bugcrowd programme on 29 April 2026 and published its analysis on 29 May 2026.
The distinction that matters is where the phishing content ends up. A traditional phishing email has to move the target from a place they half-trust, their inbox, to a place they do not trust at all, an unfamiliar domain. ChatGPhish removes that journey. The lure is rendered on chatgpt.com, a surface the user opened deliberately and associates with a reputable company.
How the technique works
When you ask ChatGPT to summarise a page, it fetches that page and processes its content. The problem Permiso identified is in how the response is then displayed. The interface trusts Markdown links and Markdown image references that came from the summarised page, treats them as part of its own output, automatically fetches the images, and presents the links as live, clickable elements.
An attacker who controls a page can therefore embed instructions and formatting that the assistant passes through into its answer. The result is not the model hallucinating. It is the model faithfully relaying attacker-authored links and images, which the interface then dresses up to look like its own trustworthy output.

Permiso demonstrated four separate outcomes from this single weakness:
- A spoofed OpenAI security alert, complete with a phishing link, appearing inside the response as though the assistant itself had issued a warning.
- An inline QR code that moves the attack onto the victim's phone, where corporate controls are weaker and a small screen hides the destination.
- A tracking pixel that leaks the victim's internet protocol address and device details every time the response renders, giving an attacker reconnaissance without a single click.
- General injection of attacker-controlled hyperlinks that are indistinguishable from links the model generated itself.
Each of these lives inside the assistant window. None of them arrives through email.

Why the trusted interface is the attack
The reason ChatGPhish is worth attention is not raw technical novelty. Cross-site and indirect prompt injection have been discussed for over a year. The reason is the psychology of the surface.
A traditional phishing email has to move you somewhere you do not trust. ChatGPhish plants the lure somewhere you already do.
People have learnt, slowly and imperfectly, to be wary of links in email. That wariness is tied to the medium. It does not automatically transfer to an AI assistant, which most users experience as a helpful, neutral tool rather than a channel that carries untrusted third-party content. When a warning that reads "OpenAI security notice" appears inside ChatGPT, the interface has done the attacker's credibility work for them.
The difference between the two is worth setting out plainly.
| Traditional email phishing | ChatGPhish | |
|---|---|---|
| Where it arrives | The inbox | Inside the AI assistant |
| Where the link renders | An external site the user must choose to visit | On chatgpt.com, a domain the user already trusts |
| What usually inspects it | Secure email gateway, URL filtering | Often nothing in the mail or web path |
| The trust cue the user reads | "This is an email, be careful" | "This is my assistant's own answer" |
Indirect prompt injection is the mechanism underneath this. In a direct prompt injection, a user types something malicious. In an indirect version, the malicious instruction is planted in content the model later reads, such as a web page, a document or an email, and the model acts on it without the user ever seeing the instruction. ChatGPhish is a specific, visual consequence of that class of problem: the injected content is not just influencing the model's reasoning, it is being rendered to the user as trustworthy interface elements.
Why email and web filtering may not see it
Consider where a conventional security stack is looking. A secure email gateway inspects messages in the mail flow. A web proxy inspects the sites a user browses to. Endpoint tooling watches processes and files. ChatGPhish can sidestep all three in the moment that matters.
There is no email, so mail filtering has nothing to scan. The malicious page the assistant fetched may itself look benign to a proxy, because the harmful behaviour is in how its content is rendered elsewhere, not in the page a human visits. And if the payload is a QR code that the victim scans with a personal phone, the interaction leaves the managed environment entirely.
This does not mean existing controls are useless. It means the interaction is distributed across surfaces that most organisations secure separately, and the attack succeeds in the seams between them.
What security leaders should reasonably conclude
It is worth being precise about the size of this, because precision is what separates useful security guidance from noise. ChatGPhish is a demonstrated technique disclosed responsibly to the vendor, not evidence of a mass campaign. Not every ChatGPT summary is dangerous, and the default assumption should remain that AI assistants are useful tools. OpenAI operates a disclosure programme and can constrain how third-party Markdown is rendered, which is the natural place for the core fix.
The durable lesson is about trust boundaries. As AI assistants gain the ability to browse, summarise and act on external content, they inherit a long-standing web security problem: content from an untrusted source should not be able to present itself as trusted output. The United Kingdom's National Cyber Security Centre has assessed that the clearest near-term uplift attackers gain from artificial intelligence is in social engineering, and ChatGPhish is a good example of that uplift arriving through a channel most defences do not yet watch. Organisations rolling out AI browsers, assistants and copilots should treat those tools as channels that carry third-party content, and apply the same scepticism they would to any such channel.
Practically, that means a few things working together rather than any single control. Browser and endpoint policies should govern which AI browsing tools are permitted and how they handle external content. Awareness guidance should be updated so staff understand that a link, warning or QR code appearing inside an assistant is not automatically safe, and that an alert claiming to come from a vendor is easy to fake. Email security still matters, because most social engineering still arrives by email, and the same attacker running a ChatGPhish experiment is usually running conventional campaigns too.
The broader shift for email defence
ChatGPhish is not an email attack, and it would be a mistake to file it as one. But it points at something that email defence has been moving towards for a while. The signal that tells you a message is hostile is rarely a single obvious payload any more. It is the combination of who is really behind it, what it is asking for, where its links resolve, whether the behaviour fits the recipient's normal patterns, and whether the surface delivering it can be trusted. This is the same shift we unpack in why phishing improved before most organisations changed how they detect it, and it is why so many convincing attacks now look completely routine.
That is the same analysis a modern email security layer has to perform on the messages that do arrive by mail. Judging an email by its attachment or a URL by a static blocklist misses the attacks that are designed to look ordinary, and it certainly misses attacks that have moved to a new surface entirely. Osiris is built around analysing email in that fuller way: sender identity, intent, links, attachments, and the recipient's exposure, rather than a single verdict on a single artefact. ChatGPhish is a reminder that the boundary of that analysis keeps moving, and that the interfaces users trust are now part of the attack surface.
The point is not that AI has made phishing unstoppable. It is that the definition of phishing has widened again. The question defenders should be asking is no longer only "is this email safe?" but "is this thing I am looking at really what it claims to be, and does the surface showing it to me deserve my trust?"
Key takeaways
- ChatGPhish, disclosed by Permiso Security in May 2026, shows how a web page can plant phishing links, fake alerts and QR codes inside a ChatGPT summary.
- The weakness is in how the assistant renders untrusted Markdown links and images from a summarised page as if they were its own trusted output.
- The attack succeeds because the content appears on a domain the user already trusts, not in a suspicious email.
- Email gateways, web proxies and endpoint tools may each miss it, because the interaction is split across surfaces they secure separately.
- The measured takeaway is about trust boundaries in AI tools, not that every AI summary is dangerous.
Frequently asked questions
What is ChatGPhish? ChatGPhish is a disclosed attack technique in which hidden content on a web page is carried into a ChatGPT summary of that page, causing attacker-controlled links, spoofed security alerts and QR codes to appear inside the assistant's interface. It was named and published by Permiso Security in May 2026.
Is ChatGPhish a real, active threat? It is a responsibly disclosed piece of research, reported to OpenAI before publication, rather than evidence of a widespread campaign. It demonstrates a genuine weakness in how AI summaries render third-party content, and it is best treated as an early warning about a growing attack surface.
Can an AI summary really contain a phishing link? Yes. The Permiso research shows that links and images from a summarised page can be rendered as live, clickable elements inside the assistant, including QR codes and content styled to look like an official alert.
How is this different from a normal phishing email? A phishing email has to persuade the target to leave a trusted place and visit an untrusted site. ChatGPhish places the phishing content inside a site the user already trusts, which removes much of the friction that makes email phishing detectable.
What should organisations do about it? Treat AI assistants and browsers as channels that carry untrusted third-party content, govern which tools are permitted, update user guidance so staff do not assume content inside an assistant is safe, and keep conventional email defences in place, since the same attackers still run email campaigns.
See how Osiris analyses email by sender identity, intent and links rather than a single verdict on a single file. Book a walkthrough.
Sources and further reading
- Permiso Security, ChatGPhish disclosure, May 2026 (primary research).
- National Cyber Security Centre, The near-term impact of AI on the cyber threat.
- Cloud Security Alliance, research note on ChatGPhish prompt-injection phishing.
- The Register, ChatGPT prompt injection turns web pages into phishing lures (2026).
- The Hacker News, ChatGPhish vulnerability turns ChatGPT web summaries into a phishing surface (2026).