AI assistants like ChatGPT have quickly become trusted environments for handling some of the most sensitive data people own. Users discuss medical symptoms, upload financial records, analyze contracts, and paste internal documents—often assuming that what they share remains safely contained within the platform.
That assumption was challenged when new research uncovered a previously unknown vulnerability that enabled silent data leakage from ChatGPT conversations without user knowledge or consent. While the issue has since been fully resolved by OpenAI, the discovery delivers a much broader lesson for enterprises and security leaders: AI tools should not be assumed secure by default.
Just as organizations learned not to blindly trust cloud providers, the same logic now applies to AI vendors. Native security does not equal sufficient security. AI requires an independent security layer on top.
The research showed that a single malicious prompt could turn an ordinary ChatGPT conversation into a covert dataexfiltration channel. Once triggered, selected content from the chat—including user messages, uploaded files, and AIgenerated summaries—could be transmitted externally without any warning or approval.
Figure 1 – Screenshot showing blocked outbound Internet attempt from inside the container.
From the user’s point of view, nothing appeared unusual. The assistant continued responding normally. No alerts were shown. No permission dialogs appeared. Yet sensitive information was quietly leaving the environment.
This is especially concerning given how ChatGPT is used today. Users upload customer data, financial spreadsheets, medical documents, and internal strategy materials every day—often without fully considering where that data could go or who might access it. In an AIdriven workflow, your data is only as safe as the weakest link in your AI stack.
ChatGPT was designed with safeguards intended to prevent unauthorized data sharing. From a user perspective, outbound data sharing is supposed to be restricted, transparent, and consentdriven.
In practice, this means:
The promise is simple: if data leaves ChatGPT, the user will know and approve it. The vulnerability did not break these guardrails directly. Instead, it bypassed them entirely.
Rather than using obvious outbound channels like HTTP requests or external APIs, the attack exploited a hidden side channel inside the Linux runtime ChatGPT uses for code execution and data analysis.
While direct internet access was blocked as intended, DNS resolution remained available as part of normal system operation. DNS is typically treated as harmless infrastructure—used to resolve domain names, not to transmit data. However, DNS can be abused as a covert transport mechanism by encoding information into domain queries.
Because DNS activity was not classified as outbound data sharing:
This created a blind spot. The platform assumed the environment was isolated. The model assumed it was operating entirely within ChatGPT. And users assumed their data could not leave without consent.
All three assumptions were reasonable—and all three were incomplete. This is a critical takeaway for security teams: AI guardrails often focus on policy and intent, while attackers exploit infrastructure and behaviour.
The attack required only a single malicious prompt. From that point forward, every new message in the conversation became a potential source of leakage. Crucially, attackers did not need to steal entire documents. The prompt could instruct the model to extract and transmit only the most valuable information—summaries, conclusions, diagnoses, or strategic insights. In many cases, these AIgenerated outputs are more sensitive than the original inputs.
This approach blended seamlessly into normal usage. Many users regularly copy prompts from blogs, forums, or social media promising productivity boosts or “hidden features.” A malicious prompt presented this way would not appear suspicious, reinforcing why AI security cannot rely on user awareness alone.
The risk increased significantly when the same technique was embedded inside custom GPTs. Instead of relying on users to paste a malicious prompt, attackers could package the logic directly into a GPT’s instructions. Users simply opened the GPT and interacted with it as intended.
In a proof of concept demonstration, researchers built a GPT acting as a personal doctor. A user uploaded lab results containing personal information and asked for guidance. The interaction appeared completely normal. When asked, the assistant confidently stated that no data had been shared externally.
Figure 2 – ChatGPT denies external data transfer while the remote server receives extracted data.
At the same time, an attacker controlled server received the patient’s identity details and the AI generated medical assessment. This exposed a dangerous reality: AI can appear trustworthy while doing something very different under the hood.
The same hidden communication path could be used for more than data leakage. Researchers demonstrated that it could also enable remote command execution inside the ChatGPT runtime. By sending commands through DNS queries and receiving responses the same way, attackers could effectively establish a remote shell inside the Linux environment used for code execution—outside the model’s safety checks and invisible to the chat interface. At that point, the issue extended beyond user privacy into platform level security risk.
For regulated industries, the implications are even more serious. A breach via an AI tool is not just a security incident—it can become:
Healthcare, financial services, and government organizations must treat AI tools as part of their regulated environment, not as consumer apps sitting outside existing controls. CISOs cannot afford to view AI as “someone else’s risk.”
The issue was responsibly disclosed, and OpenAI confirmed it had already identified the underlying problem internally. A full fix was deployed on February 20, 2026, closing the unintended communication path. There is no indication of exploitation in the wild.
But the lesson is larger than one vulnerability.
AI platforms are evolving faster than most organizations can assess their risk. Securing AI is not about patching a single flaw—it requires rethinking security architecture for the AI era. This means assuming that AI systems are full computing environments and securing them accordingly, from application logic down to infrastructure behavior.
AI companies are exceptional at building AI. They are not, by default, security first organizations. This is why independent research matters. Check Point Research’s ability to uncover this vulnerability before bad actors did is exactly the kind of oversight enterprises need. Security leaders should not rely solely on vendor assurances but engage trusted advisors who can validate, challenge, and harden AI deployments.
While the specific DNS-based exfiltration technique used in this research has since been mitigated, the core risk remains: enterprises cannot rely solely on AI vendor security controls to protect sensitive data. Attackers can still leverage social engineering techniques such as phishing or malicious file uploads to trigger prompt injection and gain unintended access to data. This means organizations must add their own security layer.
Check Point addresses this by securing user interactions with generative AI applications (preventing accidental prompt injection), enforcing DLP to stop sensitive data exposure, and providing network and threat prevention to detect covert or emerging exfiltration techniques. For more advanced control, organizations can route AI traffic through an AI security gateway and integrate protections such as Check Point’s Workforce AI solution and Lakera Guard, ensuring inspection, policy enforcement, and real time threat prevention.
Together, these capabilities ensure that even if AI platforms evolve or patch specific vulnerabilities, enterprises remain protected against the broader class of AI driven attacks.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。