SPR{K}3back to research

One Link, Any Tenant: What the Writer AI Preview Bug Actually Cost

July 8, 2026 · SPR{K}3 Research

One click on a shared preview link handed an attacker somebody else's Writer account — private chats, documents, configured agents, connected LLM credentials, and, depending on the victim's role, administrative control of the whole tenant. That is WriteOut, disclosed yesterday by The Hacker News from research by Sand Security. Writer has patched it.

What broke

Writer's platform includes a "live preview" feature: someone building an agent in the Writer Framework can generate a share link so colleagues can try it in a Writer-managed sandbox. Sand found that the preview proxy was forwarding the viewer's session cookie into the sandbox — the sandbox running code the link creator chose.

An attacker builds a preview link pointing at their own agent. A signed-in Writer user clicks it. Their browser attaches their session cookie, the proxy passes it into the attacker-controlled sandbox, and the attacker's agent reads sandbox process memory, recovers the victim's session token, and ships it out. Replaying the token is full account takeover. The KSEC writeup puts it plainly: "An outsider could go from having no access to taking over any Writer AI organization inside industry-leading enterprises, with nothing more than a link."

Writer's fix: stop forwarding the user's session cookie into sandbox previews, and move previews onto an isolated origin so the browser wouldn't send it anyway. Belt, then suspenders.

Where the trust broke down

The shape is familiar. A trusted control (Writer's preview feature), operated by an untrusted party (whoever made the link), executing inside a sandbox that inherited ambient user identity it was never supposed to have. The sandbox did its job. The mistake was upstream: the platform let the sandbox see the viewer's session, and once it could, everything the session could do was on the table.

Same family as the Cursor DuneSlide chain we wrote about last week — a sandbox structurally sound at rest but allowed to reach one file it shouldn't have, and from there the sandbox stopped constraining anything. Specifics differ (Cursor's helper binary, Writer's session proxy); the class is the same: what the sandbox is allowed to see and reach is the actual security boundary, not any check inside it.

Why this class keeps showing up

Every AI platform running user-authored agents builds something like this preview flow. Someone runs someone else's code; someone sees the output. In single-org SaaS, sharing a preview link with a colleague is the same trust decision as sharing a Google Doc. In a multi-tenant AI platform it isn't — the sandbox executes code chosen by the sender, and the viewer's session is a bearer credential for every tenant they belong to.

That gap — treating an agent preview like a document share when it is remote code execution against your own credentials — is the same instinct behind the TrustFall finding on AI coding CLIs (accepting a folder auto-starts its MCP servers) and the Microsoft-warned MCP tool-description poisoning advisory (an approved tool's description edited after approval, and the agent follows it anyway). Something that reads like content is actually an instruction, and the platform doesn't distinguish.

What we take from it

Nothing in WriteOut required a novel LLM attack. No jailbreak, no prompt injection. The vulnerability lived in the plumbing — who forwards which cookie, which origin serves the preview, whether a sandbox running untrusted code can touch someone else's session. That plumbing is where a lot of the real AI-platform attack surface sits, and testing model outputs doesn't catch it.

Catch it at runtime, from outside the agent. Watch what the sandbox is about to reach — memory, session state, network egress — and refuse reaches that don't line up with what the user asked for. A sandbox reading its own process memory to lift a session token is not doing anything the task required. That is the signal.

WriteOut is patched. The class is not. Anyone shipping an agent-preview or agent-share feature this quarter should assume they have some version of the same bug — inherited user identity leaking into a sandbox that runs somebody else's code is now a standard piece of AI product architecture.

Sources

SPR{K3 is a security research operation that pairs offensive vulnerability research with runtime behavioral defense. Defend is our runtime agent. To talk about a deployment, reach us at support@sprk3.com.