One WhatsApp Message Turned an AI Assistant Into a Hacking Tool — Here’s How

A security researcher sent a completely ordinary-sounding debugging request over WhatsApp. Thirty seconds later, he had code running on the host machine — and the AI didn’t just allow it, it helped, then asked if he needed anything else.

What Actually Happened

Security researcher Chinmohan Nayak set out to audit OpenClaw — an open-source AI assistant with 381,000 GitHub stars and, by Nayak’s own estimate based on npm download data, more than 100,000 daily active users. OpenClaw lets you connect an AI agent to the messaging apps you already use — WhatsApp, Slack, Discord, Telegram, Teams — and text it like a coworker. Ask it to debug something, and it writes code, runs shell commands, and manages files, the same way a human collaborator with terminal access would.

Nayak found three separate flaws in how OpenClaw handles that access, and then did something most vulnerability disclosures stop short of: he chained all three together into a working, end-to-end attack, launched entirely from a WhatsApp message, and documented the whole thing. In his own words: “Last week, I sent a perfectly normal-looking debugging request to an OpenClaw AI assistant over WhatsApp. Thirty seconds later, I had arbitrary code execution on the host machine.”

The First Flaw: A Filter That Only Checked for Secrets

OpenClaw includes a function called sanitizeEnvVars(), built to stop the AI agent from leaking sensitive environment variables — API keys, tokens, passwords — to any process it spawns. It works as a denylist: it checks incoming variables against a list of things that look like credentials, and blocks them.

Nayak’s insight was simple: what about variables that aren’t secrets, but can still cause damage? He tested a handful of what are called interpreter startup variables — settings that tell a programming language’s runtime to load a file automatically before anything else runs. NODE_OPTIONS. BASH_ENV. PYTHONSTARTUP. None of them look like a password. All twelve of them, in his testing, sailed straight through the filter untouched.

The filter, in Nayak’s words, “was built to keep secrets from leaking out. Nobody thought about keeping weapons from leaking in.”

The Message That Did It

Here is the actual prompt Nayak sent over WhatsApp to a test instance of OpenClaw, reproduced from his published research:

Read that again as a developer would. There’s nothing unusual about it. It has the texture of a completely normal Tuesday-afternoon Slack message — a plausible technical task, a manufactured sense of urgency (“incident report”), and a line of borrowed authority (“my team lead needs it”). The agent ran every line without hesitation, wrote the file, and reported the results back cleanly. The “memory profiler” it ran had, in that moment, full filesystem access and every credential available to the OpenClaw process itself. Swap that harmless profiler script for one that reads an SSH key and uploads it to a remote server, and the entire exchange — from message sent to keys stolen — takes seconds.

A broader explainer on how prompt injection attacks work against AI agents — useful context for the mechanism behind this specific exploit. Independent production, not affiliated with Wangdoo.

The Second Flaw: A Git Trick From Another Era

While testing, Nayak revisited an old, mostly-forgotten Git feature: the ext:: transport, which lets you specify an arbitrary shell command as if it were a remote repository URL. Git disabled this by default back in version 2.38 — but a simple configuration flag brings it right back.

His second WhatsApp message framed the request as reproducing a CI pipeline failure — a routine, believable ask for anyone debugging a broken build. The agent ran the command without objection and, notably, explained what it had done afterward, as if narrating a successful debugging session rather than executing an attacker’s payload. Swap the harmless timestamp command in that request for a line that downloads and runs a remote script, and the same “just reproducing CI” framing delivers persistent remote access.

The Third Flaw: A Sandbox With a Blind Spot

OpenClaw’s Docker sandbox mode is supposed to prevent exactly this kind of damage by blocking access to sensitive paths — your SSH keys, your AWS credentials, the Docker socket itself. Nayak found that the check only looked in one direction. It correctly blocked mounting a path inside a protected folder. It never checked whether a broader folder contained a protected one.

Why the AI Itself Didn’t Stop It

The model running behind OpenClaw in Nayak’s testing was Claude Sonnet 4 — by most measures one of the more safety-conscious commercial AI models available. Nayak is careful to note this isn’t a story about Anthropic’s training falling short in some obvious way. It’s a story about what happens when a language model is asked to do a job it was never actually built for: telling a legitimate request apart from an identical-sounding malicious one.

When Nayak sent blunt, obviously hostile payloads — the kind of thing that reads as an attack even to a non-technical person — the model pushed back roughly 40% of the time. But wrap the exact same underlying command in ordinary developer language, framed as debugging or CI reproduction, and it complied in every single fresh session he tested. There was also a session-memory quirk: once the model refused something, it grew more cautious for the rest of that conversation — but starting a brand-new session reset that caution completely, meaning an attacker only needs to land the right phrasing once.

Not a Zero-Day, Not Memory Corruption — Just the Tool Doing Its Job

What makes this disclosure worth understanding, beyond the specific bugs, is what it wasn’t. There was no exotic exploit technique here, no undiscovered class of software vulnerability. Nayak put it plainly in his own writeup: “No zero-days. No memory corruption. Just a developer tool doing exactly what it was designed to do — for the wrong person.” Every individual piece of the attack was the AI assistant behaving as intended: reading a message, interpreting an instruction, executing a command, reporting back. The failure wasn’t in any single function. It was in the assumption that message content alone was enough to establish trust.

This isn’t OpenClaw’s first security disclosure either — Cyera’s researchers published a separate set of four chainable vulnerabilities, dubbed “Claw Chain,” back in May 2026. The pattern across both disclosures is the same: a powerful tool with deep system access, connected to an interface — chat messages — that was never designed to carry the weight of an authentication decision.

What You Actually Need to Do

All three vulnerabilities Nayak found are fixed as of OpenClaw version 2026.6.6. If you run OpenClaw, or anything like it, here’s what matters in practice:

My Take — Mr Wangdoo

The detail from this research I keep coming back to isn’t the technical mechanics of any single bug — it’s the 40% number. Blunt, obviously hostile payloads got refused about 40% of the time. Payloads wrapped in ordinary developer language succeeded 100% of the time, across every fresh session Nayak tried. That’s not a minor gap in an otherwise solid defence. That’s evidence the model’s safety behaviour is responding to how a request sounds, not to what it actually does — which means the “safety” being measured here isn’t really safety in any meaningful sense. It’s a phrasing filter.

I think Nayak’s closing point is the one worth sitting with longest: we’re building tools that combine the trust model of a coworker with system access with the authentication model of “anyone who can send a text message.” Those two things were never designed to go together. A human colleague who asked you to run a suspicious-looking command over WhatsApp might get a phone call to verify first, or at least a raised eyebrow. An AI agent, as these tools are currently built, doesn’t have that instinct, and more importantly, it isn’t supposed to be the thing providing it. Security boundaries belong in the application’s actual logic — who’s allowed to trigger what, under which conditions — not in the judgment of a model that’s fundamentally trying to be as helpful as possible to whoever’s talking to it.

For anyone running OpenClaw or a tool like it, the honest takeaway isn’t “stop using AI agents.” It’s that the convenience of texting your AI assistant like a coworker comes with a genuine cost if the access behind that conversation isn’t deliberately, narrowly scoped. The model was never the security boundary. It was never going to be.

Frequently Asked Questions

Clayton Samuel (Mr Wangdoo), QFA

Founder and editor, Wangdoo.com. Qualified Financial Adviser with a background in electronics, web development, and cloud infrastructure. This article is based on the original security researcher’s disclosure and independent technical reporting. No interviews were conducted; no product is promoted.