Claude-Site Scripting Turns One Email Into Multiple Browser Account Paths
Zenity demonstrated that hidden email content with fabricated conversation turns could steer Claude in Chrome after a user asked it to summarize recent mail. A javascript_tool import from esm-sh.com executed in the authenticated browser context, read Gmail mail data and verification material, and enabled separate Slack, X, and Claude.ai takeover demonstrations; Gmail was the source and interception channel, not an account that the research claims was taken over.
Indirect Prompt InjectionCredential TheftData ExfiltrationClient SecurityAgentic AI
The email is an indirect context channel. Hidden content presents fake assistant and user turns, and Claude in Chrome does not reliably distinguish them from genuine conversation messages in the demonstrated path.
The user's normal request is a prerequisite. The victim asks for an email summary. Zenity reports that no further attacker interaction is needed after delivery, but this is not a no-condition attack that runs without the user's request.
Dynamic code crosses the browser boundary. Claude's javascript_tool imports a typosquatted package from esm-sh.com. The package runs in page context and inherits the logged-in browser session, making the tool execution boundary more important than the package's innocent-looking return value.
The impact is branched. The research uses Gmail's Atom feed to read mail metadata and verification material, then demonstrates separate Slack login, X password-reset, and Claude.ai session paths. These branches should not be flattened into one universal account-takeover sequence.
Before the browser agent executes a server- or model-suggested javascript_tool action, show the exact package URL, code action, browser target, and data scope in a normalized confirmation. A generic continue prompt does not identify the real execution boundary.
Value-Level Capability Metadata & Data Flow Sink Enforcement
Very High
Carry email and browser-session provenance on values read from Gmail, then block verification material and private mail at HTTP, login, and sharing sinks unless the exact destination and data class are authorized.
Require an independent check of the exact target account, action, current identity, typed evidence, and approval before a password reset, login completion, or session-creation exchange. Email-derived values are not approval evidence.
Parse email in a quarantined identity with no privileged tools and pass only a bounded typed result to the planner. Fake assistant turns must remain data rather than becoming privileged instructions.
What Defenders Should Do Now
Process email, page text, and package metadata in a no-tools or quarantined identity. Preserve their source labels when a bounded result is passed to a privileged planner.
Before a logged-in browser agent executes a javascript_tool action or imports a package, require explicit confirmation that displays the full URL, code action, browser target, and requested data access.
Track the provenance of every value read from Gmail or another authenticated site. Block those values from reaching external HTTP destinations, account-sharing actions, or login and password-reset flows without an exact policy decision.
Put password resets, account logins, one-time link exchanges, and membership changes behind an independent approval gate that verifies the target account and action. Do not treat an email instruction or a browser agent's interpretation as approval evidence.
Run browser tasks in an isolated context with narrowly scoped session access and egress, and destroy the context when the task ends.
1 additional consideration
Account-impact boundary
Gmail is the mail and verification source in the reported chain. The source demonstrates separate Slack, X, and Claude.ai account paths, but it should not be summarized as four accounts being taken over in one run.
Recommendation: Model the common email-to-browser prefix and each account path as separate branches, then require product-specific confirmation and session controls at each high-impact sink.
Conclusion
Claude-Site Scripting is a browser execution and authorization problem joined by an indirect email input. The strongest controls are a quarantined parser, explicit confirmation for dynamic code, value-level sink enforcement, and independent approval for account actions. SecureFlow preserves the common prefix and the separate branches so a defender can place each control at the boundary it actually protects.