Tencent WeKnora Authenticated MCP STDIO Command Injection - CVE-2026-22688
What happened
CVE-2026-22688 (also tracked as GHSA-78h3-63c4-5fqc) is an authenticated command-injection vulnerability in Tencent WeKnora, affecting all versions prior to v0.2.5. An authenticated WeKnora user can inject the stdio_config.command and args fields of an MCP STDIO service configuration, which the server then uses to spawn a subprocess during its /test execution flow. When transport_type is stdio, the code performs no allowlisting, no fixed-binary enforcement, and no blocking of dangerous options - the stored configuration data is connected directly to an execution sink with no validation in between. The result is process execution on the server with the application's privileges. The flaw is patched in WeKnora v0.2.5.
Spawning a process on the host is an administrative capability, yet WeKnora enforces no administrator-only authorization check beyond Bearer authentication. That violates the trust boundary: any account that can authenticate - not only operators - can reach a sink that runs arbitrary OS commands. This is the same install-and-invoke-without-review pattern documented across the MCP CVE wave, and a close cousin of the STDIO transport risk covered in Anthropic MCP STDIO RCE by design.
Why this is an agentic-endpoint risk
An MCP STDIO service is, by definition, a command line the host is told to execute. When the command and args of that service are attacker-controlled and reach a spawn without validation, configuring an MCP service stops being configuration and becomes code execution. This is the AI artifact layer behaving exactly as the protocol allows - and exactly where traditional controls were never designed to look. A network proxy sees encrypted traffic, EDR sees a legitimate WeKnora process doing what its config permits, and DLP sees nothing at rest. The dangerous part - a user-controlled command string wired to a subprocess - lives in stored MCP configuration that no existing tool inventories.
It is also a textbook authorization failure on the agentic endpoint. The capability (spawn a process) is administrative; the gate (a valid Bearer token) is not. That gap is precisely what makes MCP servers the new shadow IT: a capability-granting artifact, added bottom-up, reachable by anyone who can authenticate, and never reviewed against the privilege it actually confers. Anomity treats every MCP server as a first-class artifact for this reason - see fleet visibility.
How Anomity surfaces and governs it
Anomity inventories every MCP server on every managed endpoint as one of the eight AI artifact types, and surfaces each server's transport and configured command line. STDIO services whose command/args are user-controlled or unallowlisted - the exact shape of CVE-2026-22688 - are flagged, and the installed WeKnora version is recorded, so finding every host below v0.2.5 is a single query rather than a fleet-wide sweep.
On agents that expose a hook (for example a Claude Code PreToolUse hook), Anomity applies runtime governance: it returns allow, deny, or log on each tool call before it runs. A policy that denies STDIO MCP services outside an approved command allowlist stops the injected command/args from ever reaching a spawn, independent of whether the WeKnora patch is deployed yet. Because Anomity collects metadata only - with on-endpoint secret redaction - no secret values leave the host during inspection.
Every added, changed, or removed MCP service is captured in a queryable 90-day audit trail, and decisions route to your SIEM, Slack, email, or Jira. That gives you a precise window of exposure: who created or edited an MCP STDIO service, when, and with what command line. Anomity complements your Network, EDR, DLP, and GRC controls rather than replacing them; see how the layers fit and how it works.
What to check across your fleet
- Inventory every endpoint and server running Tencent WeKnora and record its version; upgrade anything prior to
v0.2.5. - Identify all MCP services with
transport_typeset tostdioand review the configuredcommandandargsfor user-controlled or unallowlisted values. - Confirm MCP service creation and editing is restricted to operators - authentication alone is not an authorization control.
- Allowlist permitted
commandandargs, and neutralize shell metacharacters in any value that reaches a process spawn. - Run the MCP subprocess with minimal OS privileges, and network-segment the MCP management interface so it is not broadly reachable.
- Review the audit trail for MCP STDIO services created or edited by non-administrator accounts before the upgrade, and treat any
/testruns against them as suspect.
This advisory is part of our MCP Server Security guide, alongside related cases such as Anthropic MCP STDIO RCE by design and MCPJam Inspector Remote Code Execution - CVE-2026-23744. To see which MCP servers are running across your own fleet and how they are configured, request early access.
Frequently asked questions
Am I affected by CVE-2026-22688?
You are exposed if you run Tencent WeKnora at any version prior to v0.2.5 and allow non-administrator users to create or edit MCP service configurations. The flaw lets any holder of a valid Bearer token set the STDIO command and args fields of an MCP service, which the server spawns during its /test execution flow. There is no administrator-only authorization check beyond authentication, so any authenticated account can reach the execution sink. Upgrading to v0.2.5 remediates the issue.
What does the vulnerability allow an attacker to do?
An authenticated user can run arbitrary operating-system commands with the WeKnora application's privileges. The /test flow uses the stored stdio_config.command and args to spawn a subprocess, and the code applies no allowlisting, no fixed-binary enforcement, and no blocking of dangerous options when transport_type is stdio. Because configuration data is wired directly to an execution sink without validation, configuring and testing an MCP service is effectively a process-execution primitive on the server host.
Why is requiring authentication not enough here?
Spawning a subprocess on the server is an administrative capability, but WeKnora gated it only behind Bearer authentication - not an administrator-only authorization check. That collapses the trust boundary: any user who can authenticate can reach a capability that should be restricted to operators. Authentication answers who you are; authorization answers what you may do. CVE-2026-22688 enforces the first and skips the second, so a low-privilege account inherits server-side command execution.
How do I remediate CVE-2026-22688?
Upgrade WeKnora to v0.2.5, which patches the flaw. As defense in depth, allowlist the permitted command and args, neutralize shell metacharacters in any value that reaches a spawn, run the MCP subprocess with minimal OS privileges, and network-segment the MCP management interface so it is not broadly reachable. Restrict MCP service configuration to operators, and review your audit trail for any MCP service created or edited by non-administrator accounts before the upgrade.
How does Anomity help with this class of MCP flaw?
Anomity inventories MCP servers and the seven other AI artifact types on every managed endpoint, surfaces the configured transport and command line, and flags STDIO services whose command/args are user-controlled or unallowlisted. On agents that expose a hook it applies runtime governance - allow, deny, or log on each tool call before it runs - and records every added or changed MCP service in a queryable 90-day audit trail, so finding exposure becomes one query rather than a fleet-wide hunt.