Tencent WeKnora Unauthenticated MCP STDIO Validation Bypass RCE - CVE-2026-30861
WeKnora unauthenticated RCE is tracked as CVE-2026-30861 (GHSA-r55h-3rwj-hcmg), an unauthenticated remote code execution flaw in Tencent WeKnora's MCP STDIO configuration validation that carries a CVSS score of 9.9. It affects Tencent WeKnora from v0.2.5 up to (not including) v0.2.10, because the validation meant to stop arbitrary process spawning is bypassed by a single allowed binary. This advisory sits under the MCP Server Security pillar guide and covers what to check and how Anomity governs the spawn decision at the hook.
What happened
WeKnora is a Tencent document-understanding and retrieval framework that can act as an MCP host, launching MCP servers over the STDIO transport. CVE-2026-30861 is an unauthenticated remote code execution flaw in its MCP STDIO configuration validation. WeKnora allows unrestricted user registration, so any attacker can self-provision an account and reach the vulnerable validation path - there is no authentication barrier between an internet-reachable instance and the code that decides which process to spawn.
The flaw is the second in a pair. After the earlier CVE-2026-22688, the WeKnora maintainers added an allowlist of permitted commands (npx, uvx) plus blacklists of dangerous arguments and environment variables. Those controls focus on blocking specific patterns rather than validating the full command structure. Because npx is allowlisted, the validation is bypassed by using npx's -p flag with node, which lets an attacker specify and run arbitrary JavaScript and achieve code execution - the front command still reads as an approved npx invocation while the payload is attacker-controlled.
The bug persisted across releases before being patched in WeKnora v0.2.10. The takeaway from the pair is structural: denylist-style fixes to STDIO command handling tend to be incomplete, which is why governing the spawn decision itself is more reliable than filtering its arguments. This is the same class of issue covered in the sibling advisory on MCP STDIO RCE that is dangerous by design.
| Field | Value |
|---|---|
| Identifier | CVE-2026-30861 (GHSA-r55h-3rwj-hcmg) |
| Severity | Critical (CVSS 9.9) |
| Affected | Tencent WeKnora v0.2.5 up to (not including) v0.2.10 |
| Vector | Unauthenticated MCP STDIO command allowlist bypass via npx -p node |
| Fixed in | WeKnora v0.2.10 |
| Prior issue | CVE-2026-22688 (same STDIO command-handling surface) |
Why this is an agentic-endpoint risk
An MCP server is one of the eight AI artifact types Anomity inventories on every managed endpoint, and the STDIO transport is the most direct path from configuration to code execution: a server definition is, in effect, a command line the host runs. CVE-2026-30861 turns WeKnora's MCP host into an arbitrary-process launcher for any registered user - the agentic-endpoint failure mode in its cleanest form, an AI artifact that quietly decides which binary executes on the host.
The unrestricted-registration detail makes this worse than a typical post-auth bug. There is no insider step and no stolen credential; the attack surface is the registration form. Network and EDR controls see an npx process, which is unremarkable on a developer endpoint, so the malicious spawn blends in. The decision that mattered - should this MCP server config launch this command - happened inside WeKnora's validation logic, below perimeter tooling. That is the layer Anomity makes visible through fleet inventory.
It also shows why argument filtering is a fragile place to put the control. The allowlist constrained the front command but not the full command structure, so a permitted binary became the delivery mechanism. Any defense built from string patterns inherits this weakness; the durable boundary is the allow/deny/log decision on the spawn itself.
How Anomity surfaces and governs it
Anomity starts with inventory. It enumerates the eight AI artifact types on every managed endpoint - AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs - and classifies each one. A WeKnora install acting as an MCP host shows up as an MCP server with its configured STDIO command, so a fleet-wide query for WeKnora below v0.2.10, or for STDIO configs that invoke npx with -p, returns the exposed endpoints directly. That inventory is what the features view surfaces and the foundation for everything below.
On agents that expose a hook - for example a Claude Code PreToolUse hook - Anomity returns allow/deny/log on each tool call before it runs. The governing question is the spawn decision, not the argument string: when an MCP STDIO server is about to launch a command, the hook evaluates whether that command, in that context, is permitted, and can deny npx -p node-style invocations or any spawn outside policy before code executes. Because the decision sits at the boundary rather than in a pattern matcher, the -p node bypass that defeated WeKnora's denylist gets no different result - an unapproved spawn is denied however the argument string is arranged.
Every decision, and every artifact added, changed, or removed, lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. Anomity collects metadata only - server names, versions, command shapes, decisions - with on-endpoint secret redaction, and it is SOC 2 Type II. It complements, and does not replace, your Network, EDR, DLP, and GRC tooling: those see the host and the network; Anomity sees the AI artifact layer and the spawn decision. That record is what the outcomes view and your auditors query when they ask which endpoints ran a vulnerable WeKnora and what was launched.
You can't govern what you can't see - and you can't filter your way out of a spawn you should never have allowed. Govern the decision, not the argument string.Anomity Threat Research
What to check across your fleet
- Inventory every WeKnora instance and confirm the version; anything from v0.2.5 up to (not including) v0.2.10 is affected - upgrade to v0.2.10 or later.
- Disable or gate open user registration; unrestricted registration is what makes this flaw unauthenticated.
- Enumerate all MCP servers using the STDIO transport and review their commands, especially
npxinvocations that use-por pull innode. - Treat any allowlist/blacklist on STDIO commands as incomplete by default; verify it validates the full command structure, not just the front binary.
- Restrict who can define or edit MCP STDIO server configurations, separate from ordinary user accounts.
- Confirm enforcement runs where agents expose a hook (e.g. Claude Code
PreToolUse) so the spawn decision runs before the process starts. - Query the 90-day audit trail for past
npx -p-style spawns and for any pre-v0.2.10 WeKnora to scope prior exposure. - Route MCP-spawn deny events to SIEM and Slack so the team is alerted on attempted bypasses, not just confirmed compromise.
CVE-2026-30861 illustrates the cluster's core lesson: denylist fixes to STDIO command handling keep getting bypassed because they police the argument string instead of the spawn. For the full pattern across MCP servers, read the parent guide on MCP Server Security, compare approaches under how it works, and see the frameworks in the AI security framework report and the agentic AI governance guide. When you are ready to inventory your fleet and govern the spawn decision at the hook, request early access.
Frequently asked questions
What is CVE-2026-30861 in WeKnora?
CVE-2026-30861 is an unauthenticated remote code execution flaw in Tencent WeKnora's MCP STDIO configuration validation, scored CVSS 9.9. WeKnora permits unrestricted user registration, so any attacker can self-provision an account and reach the vulnerable validation path. The validation tries to constrain the spawned process to an allowlist of npx and uvx while blacklisting dangerous arguments and environment variables. An attacker bypasses it with npx's -p flag to load node and run arbitrary JavaScript. The flaw affects WeKnora from v0.2.5 up to (not including) v0.2.10.
How is the WeKnora command allowlist bypassed?
After CVE-2026-22688, WeKnora added an allowlist of permitted commands (npx, uvx) plus blacklists of dangerous arguments and environment variables. Those controls match known-bad patterns instead of validating the full command structure. Because npx is allowlisted, an attacker uses its -p flag to pull in node and pass inline JavaScript, which executes outside the patterns the denylist looks for. The allowed front command stays the same while the effective payload changes, so the spawn proceeds and arbitrary code runs.
Which WeKnora versions are affected and where is the fix?
CVE-2026-30861 affects Tencent WeKnora from v0.2.5 up to (not including) v0.2.10. The earlier sibling, CVE-2026-22688, was the first STDIO command-injection issue; the allowlist and blacklist added in response did not validate the full command and were bypassed, so the weakness persisted across releases until v0.2.10 patched it. Upgrade every WeKnora instance to v0.2.10 or later, disable open user registration where it is not required, and restrict who can define MCP STDIO server configurations.
Why do denylist fixes to STDIO command handling keep failing?
A denylist enumerates the bad inputs it already knows about, so any unenumerated path through an allowed binary slips through. The WeKnora pair shows the pattern: blocking specific arguments and environment variables still let npx -p node reach code execution. The reliable control is to govern the spawn decision itself - which binary may run, in which context, under whose authority - rather than to filter an open-ended argument string. Anomity makes that decision at the hook before the process starts, instead of trying to sanitize the command after it is assembled.