Command injection in Tencent WeKnora MCP stdio testing enables server-side subprocess execution

WeKnora is an LLM-powered framework designed for deep document understanding and semantic retrieval. Prior to version 0.2.5, there is a command injection vulnerability that allows authenticated users to inject stdio_config.command/args into MCP stdio settings, causing the server to execute subprocesses using these injected values. This issue has been patched in version 0.2.5.

• Tencent WeKnora: versions < 0.2.5 are identified by the CNA as affected.
• The CNA description and GitHub Advisory Database identify 0.2.5 as patched.
• There is inconsistent advisory metadata: the repository advisory page currently displays Patched versions: None, while the CNA description, GitHub Advisory Database, and referenced fix commit point to a fix associated with 0.2.5. The status of parallel release branches or versions outside these boundaries is not independently established by the available evidence.

The flaw is in the MCP test flow that uses stdio transport. An authenticated user can place stdio_config.command and stdio_config.args into an MCP service configuration through the create or update API. In the affected code, JSON input is bound to an MCPService object, stored without sufficient validation, and later loaded by POST /api/v1/mcp-services/:id/test before the values are passed into the MCP stdio client creation path.

When the client connects, the command and arguments are used to start a subprocess on the server. The advisory also states that this functionality requires only Bearer authentication and does not enforce a separate administrator-only permission check, even though it provides process execution on the server. The referenced fix commit adds stdio configuration validation during service creation and before execution, but the complete post-fix enforcement model is not independently established by the available evidence.

The vulnerability is reachable over the network through MCP service management APIs and requires an authenticated attacker. The evidence indicates low privilege requirements, no additional user interaction, and low attack complexity. A user able to call the relevant APIs can supply the command and arguments and then trigger the test flow so the server starts a subprocess.

The record marks a public exploit as available, and the GitHub advisory contains a proof-of-concept description showing activation through a side effect. The available evidence confirms a public PoC, but does not name a campaign, victim, or specific breach.

• The direct technical outcome is server-side subprocess execution based on command and arguments supplied by an authenticated user, rather than a constrained MCP service connectivity test.
• Potential consequences include code execution on the server, access to data available to the process, data modification or deletion, and disruption of WeKnora or dependent services.
• Effective attacker capability is bounded by the WeKnora account and operating-system process permissions, but may increase if the backend has broad credentials, mounts, or network connectivity.
• The advisory identifies possible privilege escalation, lateral movement, and cross-tenant impact depending on the environment. These are conditional consequences, not outcomes required in every deployment.

• A compromised or misused WeKnora account could turn MCP connection testing into command execution in the backend runtime.
• The resulting subprocess could modify files or data accessible to WeKnora, read secrets from environment variables or configuration files, and disrupt service operation.
• If the runtime has broad mounts, network access, or credentials, the impact could extend to internal resources, connected services, or other environments. This is deployment-dependent and is not guaranteed in every installation.
• The advisory also describes possible cross-tenant impact in a shared backend runtime, but the actual boundary depends on the tenant isolation architecture.

1. Upgrade to 0.2.5, which the CNA description and GitHub Advisory Database identify as patched. After upgrading, verify the version actually running in each deployment and retest the MCP stdio create, update, and test paths.
2. Until the upgrade is complete, restrict network and account access to the MCP service create, update, and test APIs, allowing those operations only for trusted administrators. This is a compensating control, not a vendor-confirmed patch.
3. Review and disable unnecessary MCP stdio services, then inspect existing configurations for commands or arguments that do not match the organization’s operating policy.
4. Investigate MCP test requests and subprocesses created before patching. Treat suspicious configuration or process activity as a potential secret exposure or data modification event, because the available evidence does not provide a complete IOC set that can rule out impact from logs alone.

• Inventory all Tencent WeKnora deployments and identify MCP services using transport_type=stdio.
• Review MCP service data for stdio_config.command and stdio_config.args, especially for services created or modified by accounts that are not administrators.
• Check audit and API gateway logs for the service creation, update, and test endpoints: POST /api/v1/mcp-services, PUT /api/v1/mcp-services/:id, and POST /api/v1/mcp-services/:id/test.
• Compare MCP test requests with process telemetry for unexpected child processes launched by WeKnora. This is precautionary monitoring, not a vendor-confirmed IOC.
• The evidence reviewed does not establish a reliable log signature or IOC that can be used to prove safety from the absence of events alone.