Rogue Agent: How a Single Code Block Could Hijack Your AI Conversations in Google’s DialogFlow
Varonis Threat Labs discovered a critical vulnerability in Google Cloud Platform's Dialogflow CX service that allowed attackers with only the dialogflow.playbooks.update permission to inject persistent malicious code into the shared Cloud Run execution environment. The vulnerability enabled silent exfiltration of conversation data, bypassing VPC Service Controls, and injection of phishing prompts into chatbot conversations. Additional weaknesses included IMDS credential exposure and unrestricted outbound network access from the Cloud Run environment.
- filenamecode_execution_env.pyGoogle-managed Python execution environment file in Cloud Run that attacker overwrites with a modified version to intercept all Code Block executions, exfiltrate conversation data, and inject phishing prompts persistently
Detection / Hunteropenrouter
What Happened
Security researchers discovered a serious flaw in Google's Dialogflow CX chatbot platform that could let attackers hijack AI chatbot conversations. Anyone using Google Cloud's Dialogflow CX with the Code Blocks feature was at risk before the fix. The flaw let attackers steal sensitive conversation data, bypass security boundaries, and trick users into entering their passwords through the chatbot interface. Google has fixed the issue, but organizations should check their chatbot configurations for signs of past tampering.
Key Takeaways
- A single dialogflow.playbooks.update permission on one Dialogflow CX agent could be exploited to compromise all agents in the same GCP project by overwriting the shared Cloud Run execution environment
- The shared Cloud Run execution environment had a write-enabled filesystem and unrestricted outbound internet access, allowing attackers to persist malicious code and exfiltrate data bypassing VPC Service Controls
- Instance Metadata Service (IMDS) was exposed in the Cloud Run environment, leaking Google-managed service account access tokens with extensive OAuth scopes
- Attackers could inject phishing prompts into chatbot conversations using the internal respond() function, tricking users into submitting credentials through what appeared to be legitimate agent responses
- Google fully resolved the vulnerability in June 2026; no exploitation in the wild has been observed
Affected Systems
- Google Cloud Platform (GCP) Dialogflow CX agents with Playbook Code Blocks enabled
- GCP organizations using Dialogflow CX agents (prior to June 2026 patch)
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Attacker with dialogflow.playbooks.update permission configures a malicious Code Block in a Dialogflow CX agent
- Execution: Code Block downloads modified code_execution_env.py from attacker-controlled GCS bucket and overwrites the original in the shared Cloud Run environment
- Persistence: Modified execution environment intercepts every user utterance, exfiltrates conversation data, and injects phishing prompts invisibly to the victim
- Credential Access: Attacker queries IMDS to retrieve Google-managed service account tokens from the Cloud Run environment
- Exfiltration: Conversation data and credentials exfiltrated via HTTP to attacker-controlled server, bypassing VPC-SC perimeters
- Phishing: Injected prompts disguised as legitimate reauthentication requests trick users into submitting credentials through the chatbot
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: Yes
- Platforms: GCP Cloud Logging
The article provides GCP Cloud Logging queries to detect suspicious Playbooks.UpdatePlaybook events and failed Sessions.DetectIntent requests, along with manual review steps for Dialogflow CX console Code Blocks.
Detection Engineering Assessment
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | The malicious code executes inside a Google-managed Cloud Run container that is outside the victim's infrastructure scope. Standard EDR solutions have no visibility into this environment. |
| Network Visibility | Low | Cloud Run instances have public network egress by default, and the victim organization has no direct visibility into outbound traffic from the Google-managed execution environment. VPC-SC perimeters do not apply to Cloud Run egress. |
| Detection Difficulty | Hard | The overwrite occurs in a Google-managed Cloud Run environment outside the victim's visibility. Cloud Logging does not capture the file overwrite or injected logic. Detection relies on correlating playbook update events with unusual access patterns, which requires DATA_WRITE Audit Logs to be enabled in advance. |
Required Log Sources
- GCP Cloud Audit Logs (DATA_WRITE for Dialogflow API)
- GCP Cloud Logging (Dialogflow CX agent logs)
- GCP IAM audit logs (for dialogflow.playbooks.update permission usage)
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for unusual Playbooks.UpdatePlaybook events in GCP Audit Logs, especially those originating from rare IP addresses or at atypical times, as these may indicate an attacker modifying a Dialogflow agent's Code Blocks | GCP Cloud Audit Logs with DATA_WRITE enabled for the Dialogflow API | Initial Access | Medium - legitimate playbook updates by authorized developers or administrators would trigger this signal |
| Consider hunting for failed Sessions.DetectIntent requests where the error message contains Python exceptions, as these may indicate malicious Code Block execution errors | GCP Cloud Logging for Dialogflow CX sessions | Execution | Medium - legitimate code errors in Code Blocks could produce similar exceptions |
| If you have visibility into outbound traffic from Google-managed services, consider hunting for HTTP requests originating from Cloud Run instances to external or unknown domains, which may indicate data exfiltration | GCP VPC Flow Logs or Cloud NAT logs (if configured for Cloud Run egress) | Exfiltration | Low to Medium - legitimate Code Blocks may make API calls to external services, but unexpected destinations are suspicious |
| Consider reviewing Dialogflow CX Playbook Code Blocks for references to urllib, exec(), or file overwrite operations, as these are not typical in legitimate conversation flow logic | Dialogflow CX console manual review or API export of playbook configurations | Persistence | Low - while some Code Blocks may use urllib for legitimate API calls, file overwrite operations and exec() usage are highly suspicious |
| Consider hunting for access to the Instance Metadata Service from within Cloud Run environments, as code execution environments should not have access to IMDS | GCP Cloud Audit Logs and Cloud Run service logs | Credential Access | Low - IMDS access from Cloud Run is abnormal and should not occur in normal operations |
Control Gaps
- VPC Service Controls (VPC-SC) does not protect against exfiltration from the Google-managed Cloud Run execution environment, as it has unrestricted outbound internet access
- Cloud Logging does not capture Code Block configuration changes or file overwrites within the Cloud Run container
- Standard EDR and network monitoring tools have no visibility into Google-managed Cloud Run containers
- The shared Cloud Run execution environment is outside the victim's security scope, creating a blind spot for file integrity monitoring
- IMDS exposure in the Cloud Run environment violates isolation principles and is not monitored by default
Key Behavioral Indicators
- GCP Audit Log events with method name google.cloud.dialogflow.v3alpha1.Playbooks.UpdatePlaybook from unusual IP addresses or at atypical times
- Failed GCP requests with method name google.cloud.dialogflow.v3alpha1.Sessions.DetectIntent containing Python exception messages in protoPayload.status.message
- Dialogflow CX Playbook Code Blocks containing urllib.request.urlopen calls or file overwrite operations
- Code Blocks referencing code_execution_env.py or using Python exec() function
- Code Blocks using @BeforeModelTrigger or @BeforeActionTrigger decorators with internal function names
- Outbound HTTP requests from Cloud Run instances to external non-Google domains
False Positive Assessment
Medium - Playbook updates are normal administrative actions that would trigger detection signals. Failed DetectIntent requests can occur for various benign reasons. However, correlating with unusual IPs, atypical access times, and specific code patterns (urllib, exec(), file overwrites) significantly reduces false positive risk.
Recommendations
Immediate Mitigation
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider auditing all Dialogflow CX agents in your GCP projects for suspicious Playbook Code Block configurations, especially any containing urllib requests, file operations, or exec() calls
- If DATA_WRITE Audit Logs are enabled for the Dialogflow API, consider reviewing past google.cloud.dialogflow.v3alpha1.Playbooks.UpdatePlaybook events for unusual access patterns, rare IP addresses, or atypical access times
- Consider running the GCP Cloud Logging query provided in the article to identify failed Sessions.DetectIntent requests and review protoPayload.status.message for Python exceptions that may indicate malicious Code Block execution
Infrastructure Hardening
- Consider enabling DATA_WRITE Audit Logs for the Dialogflow API in all GCP projects if not already configured, to ensure visibility into playbook update actions
- Evaluate whether the dialogflow.playbooks.update permission can be scoped down to specific agents rather than granted at the project level, reducing the attack surface
- Consider implementing additional network egress controls or monitoring for Cloud Run instances if your architecture supports it, as the default Cloud Run egress bypasses VPC-SC perimeters
- If applicable, evaluate whether Code Blocks are necessary for your Dialogflow CX use cases and consider disabling the feature where it is not required
User Protection
- Consider manually reviewing all Playbook Code Block configurations in the Dialogflow CX console for each agent in your organization to confirm they are whitelisted and approved
- If your organization uses Dialogflow CX for customer-facing chatbots, consider implementing additional verification steps for sensitive transactions to mitigate phishing risk from compromised agents
- Evaluate whether users should be warned not to enter credentials or sensitive information directly into chatbot conversations
Security Awareness
- N/A
MITRE ATT&CK Mapping
Initial Access
Execution
Command and Control
Exfiltration
Additional IOCs
- Command Lines:
- Purpose: Download modified execution environment file from attacker-controlled GCS bucket and overwrite the original code_execution_env.py in the Cloud Run container | Tools:
Python urllib,exec()| Stage: Execution |urllib.request.urlopen(<url>) - Purpose: Exfiltrate conversation data and user credentials to attacker-controlled server via HTTP using preinstalled urllib library | Tools:
Python urllib| Stage: Exfiltration |urllib.request.urlopen(<url>) - Purpose: Query Instance Metadata Service to retrieve Google-managed service account access tokens from Cloud Run environment | Tools:
Python urllib,IMDS| Stage: Credential Access |urllib.request.urlopen(<metadata_url>)
- Purpose: Download modified execution environment file from attacker-controlled GCS bucket and overwrite the original code_execution_env.py in the Cloud Run container | Tools: