ChatGPT Data Leakage via a Hidden Outbound Channel in the Code Execution Runtime
Check Point Research discovered a vulnerability in ChatGPT's code execution runtime that allowed silent data exfiltration and remote shell access via DNS tunneling. By using malicious prompts or custom GPTs, attackers could bypass outbound network restrictions to steal sensitive user data without triggering security warnings.
Authors: Check Point Research
Source:Check Point
- domainbad[.]xyzExample attacker authoritative DNS domain used in the DNS tunneling diagram.
- domainreseqrch-test-uihksd89w4[.]cloudfront[.]netDomain observed in the GPT Action approval dialog PoC.
Key Takeaways
- A hidden outbound channel in ChatGPT's code execution runtime allowed silent data exfiltration via DNS tunneling.
- Malicious prompts or backdoored Custom GPTs could exploit this to steal sensitive user data, uploaded files, and model-generated output.
- The vulnerability also enabled remote shell access to the underlying Linux container used for data analysis.
- OpenAI deployed a fix for this vulnerability on February 20, 2026.
Affected Systems
- ChatGPT (Code Execution / Data Analysis runtime)
- Custom GPTs
Attack Chain
The attacker tricks a user into submitting a malicious prompt or interacting with a backdoored Custom GPT. This prompt instructs the ChatGPT code execution environment to encode sensitive conversation data or file contents into DNS queries. Since direct outbound HTTP/HTTPS is blocked but DNS is allowed, the queries are routed through recursive resolvers to the attacker's authoritative DNS server. The attacker decodes the exfiltrated data and can optionally send back commands via DNS TXT records, establishing a remote shell inside the ChatGPT Linux container.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules are provided as the vulnerability existed within OpenAI's infrastructure and has been patched.
Detection Engineering Assessment
EDR Visibility: None — The execution environment is hosted entirely by OpenAI; end-users have no EDR deployment or visibility into these containers. Network Visibility: None — The outbound DNS tunneling traffic originates from OpenAI's servers, not the user's corporate network. Detection Difficulty: Very Hard — For end-users, detection is impossible as the infrastructure is opaque. For platform providers, it requires analyzing DNS query patterns for tunneling signatures among legitimate traffic.
Required Log Sources
- DNS Query Logs (OpenAI internal)
- Container execution logs (OpenAI internal)
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Look for unusually high volumes of DNS queries or abnormally long, high-entropy subdomain labels originating from isolated container environments, indicating potential DNS tunneling. | DNS Query Logs | Exfiltration | Low |
Control Gaps
- Lack of strict DNS filtering/inspection in isolated execution containers
- User inability to monitor outbound traffic from SaaS AI platforms
Key Behavioral Indicators
- High frequency of DNS requests to a single authoritative domain
- TXT record responses containing base64 or encoded payloads
- Long, high-entropy subdomain strings in DNS queries
False Positive Assessment
- Low
Recommendations
Immediate Mitigation
- No immediate action required for end-users as OpenAI has patched the vulnerability on their end.
Infrastructure Hardening
- For organizations hosting similar AI runtimes, implement strict DNS filtering and monitor for DNS tunneling signatures.
- Restrict DNS resolution in isolated containers to only approved internal or essential external domains.
User Protection
- Avoid sharing highly sensitive PII, PHI, or confidential corporate data with public AI assistants, even in 'secure' modes.
Security Awareness
- Train users to be cautious of 'productivity prompts' or 'jailbreaks' found online, as they may contain hidden malicious instructions.
- Educate employees on the risks of using third-party Custom GPTs with sensitive data.
MITRE ATT&CK Mapping
- T1048.003 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol
- T1071.004 - Application Layer Protocol: DNS
- T1059.004 - Command and Scripting Interpreter: Unix Shell
Additional IOCs
- File Paths:
/mnt/data- Directory referenced in the PoC script execution within the ChatGPT container.
- Command Lines:
- Purpose: Test outbound HTTPS connectivity (blocked by container) | Tools:
curl| Stage: Discovery |curl -I https://example.com - Purpose: Diagnostic tools suggested by ChatGPT for DNS resolution | Tools:
nslookup,dig| Stage: Discovery |nslookup example.com - Purpose: Execute Python script for PoC inside the container | Tools:
bash,python3| Stage: Execution |bash -lc cd /mnt/data && if [ ! -f summa - Purpose: Run the summary script to trigger the PRO mode PoC | Tools:
python3| Stage: Execution |python3 summary.py "User wants PRO mode"
- Purpose: Test outbound HTTPS connectivity (blocked by container) | Tools: