Check Point Research published a report today demonstrating one of the most consequential AI-assistant attack chains we have seen to date: a single instruction planted inside a ChatGPT conversation could cause the assistant to silently work for an attacker while answering the victim's questions completely normally. In their proof of concept, that hidden work read data from the victim's connected Gmail account and passed it to a second, attacker-controlled ChatGPT account through a hidden channel.
This is not a hypothetical. It is a working, demonstrated exfiltration path that combines three trends we have been warning clients about all year: indirect prompt injection, over-privileged SaaS connectors, and the absence of egress controls on AI assistant traffic. If your organization allows employees to connect ChatGPT (or any LLM assistant) to Gmail, Google Workspace, Outlook, or file storage, you need to treat this class of attack as a data-loss vector today — not a research curiosity.
No CVE identifier has been published for this issue at the time of writing, and the disclosure appears to have been coordinated with OpenAI. The defensive lessons, however, apply regardless of whether this specific flaw is fully patched, because the underlying technique — indirect prompt injection against tool-connected LLM agents — is a structural weakness in how AI assistants consume untrusted content.
Technical Analysis
What Check Point Demonstrated
The attack chain, as described in the report, works as follows from a defender's perspective:
-
Planting the instruction. The attacker gets a malicious instruction into the victim's ChatGPT conversation context. Realistic delivery mechanisms include a crafted email the victim asks ChatGPT to summarize, a shared conversation or document, a web page the assistant browses, or content in a connected data source. Critically, the victim does not need to type the instruction themselves — the model ingests it as part of otherwise benign content.
-
Silent dual execution. While the assistant answers the user's visible question as usual, the planted instruction causes it to execute a second, hidden task in the same session. The victim sees a normal, helpful response. There is no UI indication that additional tool calls or data retrieval occurred.
-
Abuse of the connected Gmail integration. The hidden task leverages the victim's already-authorized Gmail connector — the OAuth-granted access the user approved when they linked their account. The assistant reads mailbox data using the victim's own consent. No credential theft, no MFA bypass, no malware on the endpoint. The legitimate integration is the weapon.
-
Exfiltration via a hidden channel to a second account. The stolen data is passed to a separate, attacker-controlled ChatGPT account through a covert channel embedded in the assistant's normal traffic. Because the egress flows to OpenAI's own domains over TLS, it blends into traffic most organizations explicitly allow and rarely inspect.
Why This Is Structurally Hard to Defend
Three properties make this attack class dangerous:
- Consent laundering. The data access rides on OAuth grants the user legitimately approved. From Google's perspective, the API calls are authorized. Traditional CASB/SWG alerting on "suspicious OAuth apps" won't fire because ChatGPT is a sanctioned, well-known application.
- Egress camouflage. Exfiltration goes to
chatgpt.com/ OpenAI infrastructure — domains on nearly every corporate allowlist. Volume-based DLP rarely profiles per-account behavior on these endpoints. - No endpoint footprint. There is no binary, no persistence, no process execution. Endpoint-focused Sigma and EDR detections have essentially nothing to see. Detection must shift to identity logs (Google Workspace token grants), network analytics (anomalous sessions to AI endpoints), and policy.
Exploitation Status
- Public proof of concept: Yes — Check Point Research demonstrated end-to-end Gmail read and cross-account exfiltration.
- Confirmed in-the-wild abuse: Not reported at time of publication.
- CISA KEV: Not listed (no CVE assigned).
- Vendor response: The disclosure appears coordinated; organizations should confirm with OpenAI's security advisories and their own ChatGPT Enterprise/Team admin release notes whether connector and memory behavior has been modified in their tenant.
Detection & Response
Detection for this threat lives in three places: Google Workspace audit logs (OAuth grants and API usage), proxy/ZTNA logs (AI-domain egress analytics), and endpoint telemetry (automation tooling that could be used to plant or harvest content at scale). The rules below are deliberately narrow — broad "user visited ChatGPT" detections are noise and will be disabled within a week.
Sigma Rules
---
title: Third-Party OAuth Grant Requesting Gmail Read Scopes
id: 3f9c2b71-6a84-4d1e-9b3a-7c5e2f8a1d90
status: experimental
description: Detects new OAuth token authorizations in Google Workspace where a third-party application requests Gmail read/modify scopes. Indirect prompt injection against LLM assistants abuses pre-existing connector consent; alerting on new or re-consented mail-scope grants for AI assistant clients surfaces the access path before it is abused.
references:
- https://thehackernews.com/2026/09/chatgpt-flaw-let-planted-prompt-send.html
- https://attack.mitre.org/techniques/T1528/
author: Security Arsenal
date: 2026/09/10
tags:
- attack.collection
- attack.t1114
logsource:
product: gws
service: token
detection:
selection:
event_name: authorize
scope|contains:
- 'mail.google.com'
- 'gmail.readonly'
- 'gmail.modify'
- 'gmail.insert'
filter_google_owned:
app_name|contains:
- 'Google'
condition: selection and not filter_google_owned
falsepositives:
- Users newly onboarding sanctioned AI assistants or mail clients; treat as an audit workflow rather than a block — verify the application against your approved AI tool inventory
level: medium
---
title: High-Volume Outbound Sessions to AI Assistant Endpoints
id: 8e1a5d42-3b67-4f09-a2c1-9d4e7b6031f5
status: experimental
description: Detects hosts generating anomalously large numbers of outbound HTTPS sessions or bytes to ChatGPT/OpenAI endpoints within a short window. Consistent with scripted or hidden-channel exfiltration riding on sanctioned AI assistant traffic, as demonstrated in the Check Point Gmail exfiltration PoC.
references:
- https://thehackernews.com/2026/09/chatgpt-flaw-let-planted-prompt-send.html
- https://attack.mitre.org/techniques/T1102/
author: Security Arsenal
date: 2026/09/10
tags:
- attack.exfiltration
- attack.t1102.002
logsource:
category: proxy
detection:
selection:
c-domain|contains:
- 'chatgpt.com'
- 'chat.com'
- 'oaistatic.com'
- 'oaiusercontent.com'
condition: selection | count(r-host) by c-ip > 500
timeframe: 10m
falsepositives:
- Power users with heavy legitimate ChatGPT usage; tune the count threshold per business unit and baseline before enabling alerting
level: medium
KQL (Microsoft Sentinel / Defender)
Hunt anomalous egress to OpenAI/ChatGPT infrastructure from your proxy or firewall logs ingested into CommonSecurityLog, and correlate with endpoint network events. The query below surfaces devices whose AI-domain traffic deviates sharply from their own baseline — a stronger signal than any static threshold:
// Baseline per-device outbound volume to AI assistant domains, flag >3x deviation
let aiDomains = dynamic(["chatgpt.com", "chat.com", "openai.com", "oaistatic.com", "oaiusercontent.com"]);
let baseline = CommonSecurityLog
| where TimeGenerated between (ago(30d) .. ago(1d))
| where DestinationHostName has_any (aiDomains)
| summarize AvgBytes = avg(SentBytes), AvgSessions = count_ / 30.0 by SourceIP;
CommonSecurityLog
| where TimeGenerated > ago(1d)
| where DestinationHostName has_any (aiDomains)
| summarize TodayBytes = sum(SentBytes), TodaySessions = count(),
DstHosts = make_set(DestinationHostName, 5) by SourceIP, DeviceName
| join kind=leftouter baseline on SourceIP
| where TodayBytes > (AvgBytes * 3) and TodayBytes > 50000000
| project SourceIP, DeviceName, TodayBytes, TodaySessions, AvgBytes, DstHosts
| order by TodayBytes desc;
// Endpoint view: devices with sustained connections to ChatGPT infrastructure
DeviceNetworkEvents
| where TimeGenerated > ago(1d)
| where RemoteUrl has_any ("chatgpt.com", "openai.com", "oaiusercontent.com")
| summarize Connections = count(), InitiatingProcs = make_set(InitiatingProcessFileName, 10)
by DeviceName, RemoteUrl
| where Connections > 200
| order by Connections desc;
Review the InitiatingProcs output carefully. Legitimate interactive use comes from browser processes (msedge.exe, chrome.exe, firefox.exe). Connections initiated by scripting hosts (powershell.exe, python.exe, node.exe) or headless browser binaries warrant immediate investigation — they are consistent with automation interacting with the assistant outside normal user behavior.
Velociraptor VQL
Endpoint forensics will not catch the exfiltration itself (it happens in the cloud session), but it can catch the tooling an attacker or insider uses to plant instructions, automate conversations, or harvest content at scale. Hunt for headless browser and automation framework execution on endpoints where no sanctioned automation exists:
-- Hunt for headless browser / automation frameworks interacting with AI assistant endpoints
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(--headless|puppeteer|playwright|selenium)'
OR Exe =~ '(?i)(playwright|puppeteer|chromedriver|geckodriver)'
OR (Name =~ '(?i)(chrome|msedge|firefox)'
AND CommandLine =~ '(?i)(--remote-debugging-port|--headless)')
Cross-reference any hits with the KQL results above — a host running headless browser automation and showing anomalous ChatGPT egress volume is a high-confidence lead for either attacker automation or unapproved shadow-AI tooling, both of which merit IR triage.
Containment Script
The fastest way to shrink the blast radius is auditing — and where necessary revoking — third-party OAuth tokens holding Gmail scopes. The following Bash script uses GAM (Google Apps Manager), the standard tool for Workspace admin at scale. Run it from an admin workstation with GAM configured and super-admin credentials:
#!/usr/bin/env bash
# Audit third-party OAuth tokens with Gmail scopes across all Workspace users
# Requires: GAM (https://github.com/GAM-team/GAM) with super-admin auth
REPORT="oauth_gmail_audit_$(date +%Y%m%d).csv"
echo "user,client_id,display_text,scopes" > "$REPORT"
# Enumerate every user's OAuth tokens and filter for mail scopes
gam all users show tokens | grep -Ei 'mail.google.com|gmail.readonly|gmail.modify|gmail.insert' | tee -a "$REPORT"
echo ""
echo "=== Review $REPORT. Cross-reference client IDs against your approved AI-tool inventory. ==="
echo ""
# Revoke a specific unapproved token for a specific user (uncomment after review):
# gam user user@example.com delete token client <CLIENT_ID>
# Nuclear option: revoke ALL third-party tokens for a confirmed-compromised user:
# gam user user@example.com deprovision
# Tenant-wide: restrict which third-party apps can request sensitive scopes
# Admin console -> Security -> Access and data control -> API controls ->
# App access control -> Configure "Limited" Google service access
# and block unconfigured third-party apps from accessing Gmail.
echo "Next steps:"
echo " 1. Enable 'Block unconfigured third-party apps' for Gmail in Admin console API controls."
echo " 2. In ChatGPT Team/Enterprise admin, disable the Gmail connector or restrict to approved workspaces."
echo " 3. Review Gmail audit logs (log event: mail accessed via API) for the affected grant window."
For Microsoft 365 tenants with Copilot or third-party AI connectors touching Outlook, the equivalent audit is Get-MgServicePrincipal / Enterprise Applications consent review — the same consent-laundering logic applies.
Remediation
-
Audit and inventory all AI-assistant OAuth grants today. Pull every third-party token holding Gmail (or Outlook) scopes across your tenant using the script above or your CASB. Anything not on your approved AI-tool list gets revoked. This is your highest-leverage action — it removes the access path regardless of prompt-injection patch status.
-
Enable "Limited" Google service access and block unconfigured third-party apps. In the Workspace Admin console (Security → Access and data control → API controls → App access control), restrict Gmail to trusted/limited apps only. This forces every new AI connector through an explicit admin approval gate instead of user self-consent.
-
Govern ChatGPT connectors at the workspace level. For ChatGPT Business/Enterprise tenants, review connector availability in workspace admin settings. Disable Gmail/Drive/calendar connectors unless there is a documented business need, and confirm with OpenAI whether your tier received the fix for this disclosed behavior. Treat connectors as privileged integrations in your vendor risk register.
-
Baseline and alert on AI-domain egress. Deploy the KQL/Sigma logic above. Per-device deviation alerting on
chatgpt.comtraffic catches both this hidden-channel technique and broader shadow-AI data leakage. -
User guidance for a threat they cannot see. Tell employees: never paste or summarize unsolicited emails/documents from unknown parties into a connected assistant; treat assistant outputs that reference sending, sharing, or "checking" other accounts as red flags; and report any unexpected connector consent prompts. This attack works because the user sees nothing — awareness is the only user-layer control.
-
Update your AI acceptable-use and IR playbooks. Add "LLM assistant abuse / prompt injection" as an incident category with defined containment steps: revoke OAuth grants, disable workspace connectors, pull Workspace token audit logs, and preserve the conversation export. You cannot forensically image a chat session after the fact — establish evidence-preservation steps now.
-
Track vendor advisories. Monitor OpenAI's security disclosures and Check Point Research for follow-on details, indicators, or a CVE assignment. If a CVE is published, map it into your vulnerability-management workflow even though the "patch" is server-side — tenant-level configuration verification still belongs to you.
The broader lesson for 2026: every LLM connector you approve is a machine-speed service account with user consent and a natural-language remote control interface. Govern it like one.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.