An infostealer variant has been caught in the wild stealing OpenClaw configuration files, gateway tokens, and private keys. This isn’t a theoretical risk. It happened on 13 February 2026, and Hudson Rock has the receipts.
This is different from everything else written about OpenClaw security. The [hardening guides](/openclaw-security-hardening/) tell you how to lock things down. The [ClawHub skills warning](/clawhub-skills-security-warning/) covered malicious plugins. The [is it safe article](/is-openclaw-safe/) addressed general risk. This is a live incident report — confirmed malware, confirmed stolen files, documented exfiltration. If you’re running OpenClaw, you need to know what was taken and what an attacker can do with it.
What Happened
On 13 February 2026, cybersecurity firm Hudson Rock detected an active infostealer infection that had successfully exfiltrated a victim’s OpenClaw configuration environment.
Alon Gal, co-founder and CTO of Hudson Rock, told BleepingComputer the malware is believed to be a variant of Vidar — a commodity infostealer that’s been around since 2018 and is sold as malware-as-a-service in criminal forums. Vidar typically targets browser credentials, session cookies, and cryptocurrency wallets. This infection appears to be the first documented case of an infostealer successfully stealing AI agent configuration files from a real user’s machine.
The malware didn’t target OpenClaw specifically. It ran a broad file-stealing routine that scanned directories and file contents for keywords like “token” and “private key.” The ~/.openclaw directory happened to be full of exactly those keywords, so everything in it was swept up and exfiltrated.
That distinction matters. This wasn’t a zero-day exploit or a sophisticated supply chain attack. The malware was doing what commodity infostealers always do — hoovering up anything that looks like credentials — and OpenClaw’s flat-file configuration made it a perfect accidental target. As OpenClaw’s adoption grows, expect infostealers to start targeting the directory deliberately.
What Was Stolen
Hudson Rock documented exactly which files were exfiltrated and what they expose.
openclaw.json — This is the primary configuration file. In the documented case, it exposed the victim’s redacted email address, workspace path, and a high-entropy gateway authentication token. That token is the key to the kingdom. Anyone with it can remotely connect to a local OpenClaw instance (if the gateway is exposed), or impersonate the victim in authenticated API requests. Combined with CVE-2026-25253 — the one-click RCE vulnerability where the Control UI auto-transmits the stored auth token — an attacker could potentially achieve full remote code execution from just this one file.
device.json — Contains both publicKeyPem and privateKeyPem fields used for device pairing and message signing. With the private key, an attacker can sign messages as the victim’s device, potentially bypass “Safe Device” checks, and access encrypted logs or cloud services that are paired with the device.
soul.md and memory files (AGENTS.md, MEMORY.md, daily logs) — These define the agent’s behaviour and store persistent contextual data. Daily activity logs, private messages, calendar events, the agent’s operational instructions — all of it. Hudson Rock’s AI analysis concluded that this data alone is potentially sufficient to enable a full compromise of the victim’s digital identity, even without the authentication tokens. The memory files are your AI agent’s diary. They contain everything it has done, read, and processed on your behalf.
Why This Was Predictable
Hudson Rock had actually published a warning about this exact scenario in late January, calling OpenClaw “the new primary target for infostealers in the AI era.” Their reasoning was straightforward:
The ~/.openclaw directory follows the same pattern as ~/.npmrc, ~/.gitconfig, and ~/.aws/credentials — directories that commodity infostealers have targeted for years because they reliably contain high-value secrets. Once OpenClaw went viral and attracted hundreds of thousands of users, it was only a matter of time before a broad-scanning infostealer hit someone who happened to be running it.
The Adversa.ai security research team made the same prediction in their OpenClaw Security 101 guide, noting that Redline, Lumma, and Vidar infostealers were all likely to encounter and steal OpenClaw files during routine credential-harvesting operations.
They were right, and the lag between “predicted” and “documented first case” was under three weeks.
What an Attacker Can Do With This
The combination of files stolen in this incident gives an attacker a fairly complete kit.
With the gateway auth token from openclaw.json, they can authenticate to the victim’s OpenClaw gateway. If that gateway is publicly exposed (and Censys data suggests over 21,000 OpenClaw instances are), they can connect and issue commands to the agent directly. If the gateway is behind localhost, they need the victim’s browser to be running — but CVE-2026-25253 provides a mechanism for that via a malicious link.
With the device private key from device.json, they can impersonate the victim’s device to any service that uses device-based authentication. Some cloud services and OAuth flows tie trust to a specific device identity; that trust can be transferred.
With the memory files, they have an operational profile of the victim. Email addresses, calendar patterns, recurring tasks, communication style, personal information shared with the agent, integrations that are active, tools that are configured. This is intelligence that enables more targeted social engineering, phishing, or account takeover attempts on linked services.
Hudson Rock described it as “the transition from stealing browser credentials to harvesting the souls and identities of personal AI agents.” That’s a more accurate framing than it sounds. Your AI agent’s files are a forensic record of your digital life.
What to Do Right Now
Immediate steps if you’re worried about existing exposure:
1. Rotate your gateway token. Open OpenClaw settings and regenerate the gateway authentication token. The old one should be treated as compromised until you can verify your machine’s integrity.
2. Regenerate your device keypair. There’s a device settings panel in OpenClaw where you can regenerate the signing keys. Do this if you have any reason to suspect your machine has been infected with malware recently.
3. Audit your memory files. Open ~/.openclaw/MEMORY.md and your daily log files (~/.openclaw/memory/). Look at what’s actually in there. If it contains credentials, personal financial information, or OAuth tokens that the agent was processing, assume that information is exposed and rotate it.
4. Check for infostealer indicators. Run your preferred endpoint security tool. Look for signs of Vidar or Redline activity: unexpected process executions, unusual network connections to Russian or Eastern European IP ranges, browser data exfiltration in network logs.
Structural steps to reduce ongoing risk:
Encrypt the ~/.openclaw directory at rest. On macOS, you can use a FileVault-encrypted disk image mounted at ~/.openclaw. On Linux, use fscrypt or gocryptfs. This won’t stop a running infostealer from reading the files while they’re decrypted, but it raises the bar significantly.
Limit what goes into memory files. If you’ve configured your agent to log everything — email bodies, calendar events, message content — consider restricting what it’s allowed to persist. An agent that stores summaries rather than raw content is less attractive to infostealers.
Don’t expose the gateway. If you’re not actively using remote access, keep the gateway bound to localhost. The attack surface for token theft shrinks dramatically if an attacker needs local code execution to use a stolen token.
Run OpenClaw in a dedicated user account with limited file system permissions. This is the nuclear option, but it means the ~/.openclaw directory on that account only contains OpenClaw data, not the rest of your digital life.
The Bigger Picture
This incident marks a genuine shift in the threat landscape for personal AI agents. Until 13 February, the infostealer risk was theoretical. Now it’s documented.
The pattern is likely to accelerate. Commodity infostealers evolve fast, and their operators update target lists to chase high-value credentials. As OpenClaw adoption grows — and it will grow, regardless of what happens with the [OpenAI acquisition of Steinberger](/openclaw-creator-joins-openai/) — the ~/.openclaw directory will appear in targeted file-theft configurations alongside ~/.aws, ~/.ssh, and browser credential stores.
The security fundamentals haven’t changed. What’s changed is the evidence. Use this as a forcing function to actually implement the hardening steps you’ve been putting off.
The lobster has valuable secrets. Protect them accordingly.
—
Sources: BleepingComputer (Feb 17 2026), Hudson Rock blog post #6182, The Hacker News (Feb 17 2026), Adversa.ai OpenClaw Security 101 (Feb 15 2026), SOCRadar CVE-2026-25253 analysis.