Check Point says a ChatGPT HTML preview popup got past Lockdown Mode, with zero clicks in ChatGPT Classic

Seven restrictions, and a popup that was not one of them

Check Point Research's post of 5 November 2026 describes Lockdown Mode, OpenAI's optional security setting for ChatGPT, in one sentence that lists seven restrictions (derived count): live web access limited to cached content, no images loaded from the internet, no network requests from Canvas code, and Deep Research, Agent Mode, live connectors and file downloads all turned off. The bypass Check Point reports went through none of those seven. It went through a popup window opened from ChatGPT's HTML page preview, a feature the post dates to February 2026, which could get outside both the preview's sandbox and Lockdown Mode. In the Electron based app the post calls ChatGPT Classic, Check Point says the data theft needed no user interaction at all.

The post says OpenAI told Check Point on 18 September 2026 that a fix was deployed, and that Check Point retested and found the technique no longer works. From that fix notice to publication is 48 days (derived: 18 September to 5 November). This briefing rests on the post, read in full at about 11:58 UTC on Saturday 7 November 2026 from a copy saved that morning.

What that does not establish. The post gives no date for the report to OpenAI, so the time OpenAI took to fix it cannot be computed. It does not say when the weak setting first shipped, so nobody can say from the post how long Lockdown Mode users were exposed. It reports no count of affected users and says nothing about anyone using the flaw outside Check Point's own demonstrations: the four videos it describes are Check Point's. It names no CVE, severity or bounty. It does not quote OpenAI, beyond relaying what OpenAI told Check Point about the fix. And it does not test any other assistant.

Check Point sells security products. OpenAI sells ChatGPT. Neither interest changes the mechanism the post describes, but the only account of the flaw, its reach and its fix comes from the finder.

What Lockdown Mode is meant to do, in the post's words

The post introduces Lockdown Mode as "an optional advanced security setting for logged-in ChatGPT users". Its stated purpose is to reduce the risk that a prompt injection attack makes ChatGPT, or one of its tools, send private data out through "outbound web, app, connector, or file-download requests". The post gives OpenAI's own example from a write-up on link safety: an attacker tricks the assistant into loading a web address that carries private data in it, so the data lands in the attacker's server logs while nothing suspicious appears in the chat.

Prompt injection here means instructions hidden in content the assistant reads, such as a page, a file or a custom GPT, that the model follows as if the user had typed them. The post accepts that this risk does not go away: it says prompt injection "remains a persistent risk regardless of implemented guardrails". Lockdown Mode therefore does not try to stop the model being fooled. It tries to make sure a fooled model has no way to send anything out.

That is a sound design, and it is also where the friendly name does more work than it should. Lockdown suggests a building with every door shut. What the post describes is a list of seven switches. A channel that is not on the list is not locked down by the name. The HTML page preview is not among the seven; the post's Figure 1 shows a Lockdown Mode notice when Canvas tries to reach an external resource, and the preview relied on its own sandbox to raise the same kind of warning. When that sandbox could be stepped around, the setting's name did not close the gap.

OpenAI's announcement of Lockdown Mode, which the post links, was not read for this briefing, so its launch date, the plans it covers and any admin controls are not stated here. Where this briefing describes the setting, it describes it as Check Point does.

How the bypass worked, at the level the post gives it

ChatGPT can render an HTML code block as a small working page, the HTML page preview. Because that page runs code written by whoever wrote the HTML, the post says OpenAI built safeguards around it. The rendered page sits in a sandbox, two nested frames kept apart from the main ChatGPT page, so it cannot read the conversation, the interface state, cookies or stored data for chatgpt.com. Any attempt to send data out, load remote images or scripts, follow a link or open an outside address is intercepted and shown to the user as an approval dialog, which the post's Figure 3 shows.

The weakness, as the post describes it, was in how popups were handled. The sandbox itself was set to allow popups, and to let a popup leave the sandbox's rules. OpenAI did not rely on the sandbox to stop popups; its own scripts replaced the browser's popup function so that a popup needed the user's approval, and a popup with an empty address was silently refused. Check Point found a way for a page in the preview to reach a working popup function that the replacement did not cover. Because the sandbox let popups escape, whatever the attacker put in that new window ran outside the sandbox, and, the post says, outside Lockdown Mode's restrictions as well. The post prints the code for that step; this briefing does not reproduce it.

Zoom

From that one opening, the post describes three kinds of harm. Data theft: the window could send out "entire chat history and uploaded files". Phishing and credential theft: in ChatGPT Classic, Check Point says it could reload the main window and perform actions as the user, such as forcing a sign out, then show a convincing sign in page on an attacker's site to collect the password. Malware delivery: the popup kept the ChatGPT application icon while the attacker set its title, so a fake update download looked like part of the app.

The same preview feature was the starting point for a separate weakness that Parameter Labs reported in October, which this site covered in its briefing on the shared link flaw. That chain used a different route, a message listener in a maths library, and that writeup dates OpenAI's confirmed fix to 26 October. The two are different flaws with different fixes; what they share is that a feature built for convenience gave content from outside a place to run inside the ChatGPT interface.

Where zero clicks applies, and where a click is still needed

The headline claim of "zero user interaction" is narrower than it first reads. The post confines it to the Electron based ChatGPT Classic application, where it says a popup opened even without a user gesture, so "simply having a conversation" with, for example, a malicious GPT was enough to start the data theft. Its first video shows that case. In an ordinary browser, the post says, default settings stop a page opening a popup without a click, so the attacker needed a lure that persuaded the user to click the preview. Downloads differ the other way round: the Classic app does not download files automatically, so a user had to click a link, while in a browser automatic downloads were not blocked.

The post names three ways in: "a malicious prompt, a malicious GPT, or a shared chat". Each is content someone else wrote that the user lets ChatGPT render. A custom GPT has carried a lure before: this site's briefing on the ClickFix incidents found two confirmed cases that came through one, though that campaign used no flaw in ChatGPT at all.

What the post states, and what it does not

Coverage adds little. SecurityOnline's report of 6 November, read for this briefing, restates the post, quotes no one from OpenAI, and says OpenAI fixed the flaw "across all distributions", a phrase the post does not use and does not support. Its closing advice, that security conscious users should still turn Lockdown Mode on, is the outlet's view, not Check Point's.

The dates the post gives, and the ones it leaves out

The post's introduction recalls an earlier Check Point finding this year: a flaw in ChatGPT's code execution runtime that let conversation data leave through DNS tunneling, a hidden outbound channel that got around the runtime's network isolation, for which "a fix for this issue was promptly deployed". It then says OpenAI "later introduced" Lockdown Mode. No briefing on this site covers that earlier finding, and the earlier post was not read for this one, so its dates are not given here.

Zoom

Only three dates in the story are printed: February 2026 for the preview feature, 18 September 2026 for the fix notice and 5 November 2026 for the post. The gap a defender most needs, how long the weakness was live while people relied on Lockdown Mode, is the one the post cannot give, because it says neither when the permissive setting arrived nor when Lockdown Mode did. Publishing 48 days after the fix notice meant the details came out after the gap was closed; it also means anyone who used the preview before 18 September learned of the risk at least 48 days later, and only from the finder.

What to do, in order

The post's own advice is general, and neither it nor any page read for this briefing gives OpenAI's advice. Everything after the first item is this site's suggestion.

Technical details

The post prints HTML fragments and the script that reached the working popup. Those are the bypass itself and are left out here. It prints no indicators of compromise: the web addresses in its examples are placeholders. What a defender can use is below, copied from the post exactly.

First, the post's description of what Lockdown Mode does when it is on. This is the list to check a deployment's expectations against: anything that is not on it, such as the HTML page preview, is protected by something other than Lockdown Mode.

When enabled, it restricts live web access to cached content, blocks the loading and display of images from the internet, disables network requests from Canvas-generated code, and turns off Deep Research, Agent Mode, live connectors, and file downloads.

Second, the three delivery routes. Each is content written by someone other than the user; these are the places to look when reviewing what an account opened before the fix.

The attack could be carried out in several ways: through a malicious prompt, a malicious GPT, or a shared chat.

Third, where the zero interaction claim applies. It names one client, the Electron based ChatGPT Classic application; the post's browser scenarios need a click.

The vulnerability exposes a wide attack surface, enabling silent exfiltration of entire chat history, credential theft via phishing, and malware delivery. In ChatGPT Classic, the attack requires zero user interaction: simply having a conversation is enough to trigger silent data exfiltration.

This makes the vulnerability significantly more dangerous: an attacker could silently exfiltrate data without requiring any interaction from the user, simply having a conversation would be enough to trigger the attack.

Fourth, the fix and the retest. The two names are standard browser sandbox permissions for frames. Anyone running a sandboxed preview of untrusted HTML can check their own frames for the same two permissions; that check is this site's suggestion.

Check Point Research responsibly disclosed this vulnerability to OpenAI. On September 18, 2026, OpenAI informed us that it had deployed a fix by removing the allow-popups and allow-popups-to-escape-sandbox permissions from the outer HTML-preview sandbox iframe. We subsequently retested the issue and confirmed that the exploitation technique described in this article no longer works.

The question the post leaves open

Lockdown Mode was offered to the users who most needed a guarantee, and for some period before 18 September 2026 a popup from a feature not on its list could carry their chat history out, without a click in the Classic app. OpenAI fixed the setting that allowed it. The post cannot say how long that period was, and OpenAI has not said, in anything read here. If your security case for putting sensitive work into ChatGPT rested on Lockdown Mode, which date does it start from, and who will tell you the next time a feature arrives that the list does not cover?

Key facts