ChatGPT Is Becoming a Browser Surface, and Attackers Noticed

A phishing email used to arrive as an email.

That sounds too obvious to be useful, but it mattered. The old security model had a fairly clear shape: the attacker sent a message, the message had headers, attachments, URLs, sender reputation, delivery infrastructure, and a mailbox full of controls built specifically to distrust it. Secure email gateways, DMARC, link rewriting, attachment detonation, user training, abuse desks, reporting buttons — imperfect controls, but controls designed around the idea that the inbox is hostile.

This week showed something different. Attackers are starting to move the phishing surface into places users have been taught to trust more than email: AI assistants, shared ChatGPT pages, browser-rendered summaries, and agent-driven workflows.

That is the part worth paying attention to. Not because every ChatGPT link is dangerous. Not because AI tools are uniquely evil. Because the browser and the assistant are merging into a new trust surface, and attackers are already adapting faster than most organizations are updating their assumptions.

The Shared ChatGPT Page That Became a Malware Landing Page

BleepingComputer reported on a campaign Push Security calls LLMShare. The technique is simple enough to be uncomfortable: attackers buy search ads for ChatGPT-related queries, send victims to a legitimate chatgpt.com shared conversation URL, and use the rendered content of that shared page to display a fake outage notice.

The message claims the web version is unavailable because of high traffic and tells the user to download the desktop application instead. The download is malware dressed as ChatGPT.

The clever part is not the fake outage message. Fake outage pages are old. Fake desktop-app downloads are old. Search ads leading to malware are painfully old.

The clever part is the hosting context. The victim lands on chatgpt.com, not on a newly registered phishing domain with a misspelled brand. A corporate proxy, browser reputation system, or human glancing at the address bar sees OpenAI's domain. The page is not exploiting a browser memory corruption bug. It is abusing a legitimate product feature: share a conversation, render it nicely, and let anyone view it.

That creates a strange failure mode for security controls. The malicious content is not on evil-chatgpt-download.example. It is content rendered inside a legitimate AI product's sharing surface. The domain reputation belongs to OpenAI; the intent belongs to the attacker.

This is a pattern we should expect to see again. Any product that lets users publish branded, trusted-looking pages on a high-reputation domain will eventually be used this way. GitHub Pages, Google Docs, Notion, Microsoft forms, and countless SaaS invite pages have lived with this problem for years. ChatGPT share links are simply joining the club, with one extra psychological advantage: people are currently primed to believe that AI tools are where software recommendations, summaries, and next actions come from.

ChatGPhish: When a Summary Becomes the Delivery Mechanism

The second report is more subtle. Permiso Security disclosed a technique they call ChatGPhish, covered by The Hacker News. The issue is not merely that prompt injection exists. We already know that an attacker-controlled web page can include instructions that influence a model summarizing it.

The more interesting problem is the renderer.

According to the report, ChatGPT's web response renderer trusted Markdown links and image URLs that originated from third-party pages the assistant had summarized. If a malicious page included the right payload, the assistant could render live links, remote images, fake account alerts, or QR codes inside the trusted ChatGPT interface.

That matters because the output is no longer just text. It is a mini web surface inside a trusted application.

A victim asks ChatGPT to summarize a page. The page contains hidden or low-visibility instructions. The model incorporates those instructions into the answer. The UI then turns attacker-provided Markdown into clickable links and fetched images. In one scenario described by Permiso, simply rendering attacker-hosted images could leak IP address, User-Agent, and Referer data. In another, the answer could display a QR code that pushes the user onto a mobile device, bypassing some desktop URL controls and enterprise inspection.

This is not the same as a malicious email attachment. The user did not receive a phishing message in the inbox. The user performed ordinary research. The attacker supplied a page that looked worth summarizing. The assistant became the thing that presented the lure.

That is a different security model.

Traditional web security assumes the browser renders a site with that site's origin, permissions, scripts, and reputation. AI summarization breaks that visual intuition. The user is looking at ChatGPT, but some of the semantic content came from an untrusted page. The assistant's tone, formatting, and brand trust wrap the attacker's instruction in a calmer voice.

This is why indirect prompt injection is not just a model-safety curiosity. It is a UI security issue. If an assistant can fetch, transform, and render untrusted content, then the assistant needs a threat model closer to an email client or browser than a text box.

The LLM Agent After Initial Access

The third story is where this becomes operational rather than theoretical. Sysdig documented an incident, reported by The Hacker News, in which an attacker exploited CVE-2026-39987 in an internet-exposed Marimo notebook, then used what appears to have been an LLM agent for post-exploitation.

The chain was familiar at first: exploit a public notebook, extract cloud credentials from the host, use AWS Secrets Manager to retrieve an SSH private key, connect to a downstream bastion, and dump an internal PostgreSQL database.

The unusual part was the command style. Sysdig identified several signs of LLM-driven activity: machine-oriented command output, delimiter-separated results, value handoffs from one command into the next, and even a Chinese-language planning comment leaking into the command stream. The attacker did not need to know the environment in advance. The agent improvised from what it found.

That sentence is doing a lot of work: the attacker no longer needs to see your environment to operate inside it.

For years, defenders have relied partly on the friction of post-exploitation. A human intruder has to enumerate, understand naming conventions, choose commands, make mistakes, adapt, and decide where to go next. Good attackers can do that quickly, but it still takes skill and attention.

LLM agents reduce that friction. They can read a directory listing, infer that .pgpass is interesting, extract a database password, test the connection, inspect the schema, and dump the data in a format useful to the operator. They do not need to be brilliant. They need to be good enough to turn commodity initial access into competent follow-through.

That changes the economics of compromise. The scarce resource is no longer only skilled hands-on-keyboard time. A lower-skilled operator can rent or wire together an agent that performs enough reconnaissance and exfiltration to be dangerous.

Three Stories, One Direction

These incidents look separate if you read them as headlines:

• ChatGPT share links abused to deliver malware.
• ChatGPT summaries can render phishing material from untrusted pages.
• An LLM agent appears in post-exploitation after a Marimo RCE.

I think they are the same story.

AI systems are moving into three positions security teams historically treated separately:

1. A trusted presentation layer — the assistant renders information, links, images, alerts, and recommendations.
2. A workflow broker — the assistant decides what the user should do next, often with a confident and helpful tone.
3. An operator — the agent can take actions across filesystems, shells, cloud APIs, and internal systems.

Attackers do not need to compromise the model weights to abuse those positions. They can abuse legitimate sharing features, untrusted content ingestion, Markdown rendering, search ads, OAuth grants, exposed notebooks, and poorly scoped agent permissions.

This is why I dislike the comforting phrase "AI phishing." It makes the problem sound like ordinary phishing with better grammar. The more important shift is not the prose. It is the relocation of trust.

The lure is no longer necessarily in the inbox. It may be inside the tool the user asked to help them think.

What Organizations Should Change Now

There are practical things to do. None of them require panic. They do require admitting that AI assistants are now part of the browser and SaaS attack surface.

1. Treat AI-rendered links as untrusted links. If ChatGPT, Copilot, Claude, or another assistant shows a link, button, QR code, or download recommendation based on third-party content, it should be treated like a link in an email from an unknown sender. The assistant is not the origin of truth. It is a renderer.

2. Block software installation from AI share pages and search ads. If someone wants the ChatGPT desktop app, Claude desktop app, or any other AI client, they should get it from a managed software portal or a verified vendor download page typed directly or reached through a known bookmark. Search ads and shared conversations are not software distribution channels.

3. Add AI share links to phishing training without making it silly. Users do not need a theatrical warning that "AI is dangerous." They need one concrete rule: a legitimate-looking chatgpt.com/share/... page can still contain attacker-authored content. The domain proves where the page is hosted, not that the content is safe.

4. Sanitize assistant rendering. Product teams building AI summaries should separate untrusted source content from trusted assistant UI. Remote images should not auto-fetch from arbitrary attacker infrastructure. Markdown links should be visibly attributed to their source. QR codes generated from summarized content should be treated as high-risk, because they move the user onto a less-inspected device.

5. Put agent tools behind least privilege. If an LLM agent can run shell commands, read cloud credentials, call AWS APIs, or open SSH sessions, it is not a chatbot. It is an automation principal. Give it scoped credentials, network restrictions, audit logging, and a kill switch. Do not let the browser session of a knowledge worker become a bridge into production.

6. Inventory exposed notebooks and vibe-coded apps. The Marimo case is a reminder that notebooks, internal tools, and AI-built apps often become internet-facing before anyone thinks of them as production systems. Scan for them. Put them behind SSO. Remove public access unless there is a deliberate reason.

7. Watch for machine-shaped post-exploitation. Delimiter-heavy command streams, repeated bounded-output patterns, explicit planning comments, and unusually fast schema discovery are worth alerting on. They are not proof of LLM use by themselves, but they are signals that the operator may be automating reconnaissance and exfiltration.

The Browser Was Already Too Trusted

Browsers have been expanding for years. They run office suites, IDEs, design tools, password managers, video editors, banking portals, and admin consoles. Help Net Security also covered new research this week on FROST, a browser-based side channel that uses Origin Private File System timing and SSD contention to infer activity elsewhere on a user's system. That is a very different technical issue, but it rhymes with the same broader point: the browser is no longer a document viewer. It is an operating environment.

AI assistants are being grafted onto that environment. They summarize pages, open links, render content, generate code, connect tools, and increasingly act with delegated authority. The old line between "reading the web" and "doing work" is getting thin.

Attackers noticed.

Defenders should update the mental model before the tooling catches up. The safe assumption is not that AI assistants are malicious. The safe assumption is that they are powerful rendering and action surfaces that consume untrusted input all day.

That makes them more like browsers, email clients, and automation platforms than like calculators.

And we know what happens to those. Eventually, someone sends them a link.

Sources: BleepingComputer — ChatGPT share links abused to host fake outage pages, The Hacker News — ChatGPhish vulnerability, The Hacker News — LLM agent used after Marimo exploitation, The Hacker News — exposed vibe-coded apps, Help Net Security — FROST browser SSD timing research