CVE-2026-30861: 
vulnerability analysis and mitigation

CVE-2026-30861 is a critical OS command injection vulnerability in Tencent WeKnora, a Go-based AI knowledge management platform, enabling remote code execution (RCE) via the MCP stdio configuration validation feature. It affects WeKnora versions 0.2.5 through 0.2.9 (inclusive), introduced when the MCP stdio transport was added in version 0.2.5. The vulnerability was published on March 6, 2026, and patched silently in version 0.2.10 without an initial CVE or security advisory, leaving users unaware. The GitHub Advisory Database assigns a CVSS v3.1 score of 10.0 (Critical) with no privileges required and a changed scope, while the NVD/Feedly data reflects a score of 8.8 (High) with low privileges required (GitHub Advisory, WeKnora Advisory).

The root cause is CWE-78 (Improper Neutralization of Special Elements used in an OS Command), arising from an incomplete argument validation blocklist in the ValidateStdioConfig() / ValidateStdioArgs() functions (GitHub Advisory). While the application whitelists only npx and uvx as allowed commands and blacklists dangerous argument patterns, the -p flag for npx node was not included in the DangerousArgPatterns regex list. This allows an attacker to supply arguments such as ["node", "-p", "require('fs').writeFileSync(...)"], which pass validation but cause Node.js to evaluate and execute arbitrary JavaScript — and by extension, arbitrary OS commands — when the MCP service is triggered. Because WeKnora permits unrestricted account registration (no email verification, approval, or rate limiting), any network-accessible attacker can self-register, obtain a JWT, and immediately exploit the flaw. A detailed PoC with step-by-step HTTP requests is publicly available in the security advisory (WeKnora Advisory).

Successful exploitation grants an unauthenticated attacker arbitrary OS command execution with the full privileges of the WeKnora application process, resulting in complete server compromise (GitHub Advisory). All application data is exposed (full confidentiality breach), and attackers can modify or destroy data, install malware, backdoors, or ransomware (full integrity and availability impact). The changed scope in the CVSS assessment reflects the potential for lateral movement to internal systems reachable from the compromised server, amplifying the blast radius beyond the WeKnora instance itself (WeKnora Advisory).

A detailed, step-by-step proof-of-concept exploit with specific HTTP requests and payloads is publicly available in the GitHub security advisory, classified as a real exploit with high confidence by Feedly (WeKnora Advisory). No authentication is required in practice due to open self-registration, making the effective attack barrier extremely low. As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation, no known threat actor attribution, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.083% (24th percentile), indicating a currently low but non-negligible probability of exploitation in the near term (GitHub Advisory).

1. Reconnaissance: Identify internet-facing WeKnora instances running versions 0.2.5–0.2.9 using network scanning tools (e.g., Shodan, Censys) or by checking the application's version endpoint.
2. Account Registration: Register a new account on the target WeKnora instance via the open registration endpoint (no email verification or approval required), and obtain a JWT bearer token from the login response.
3. Create Malicious MCP Service: Send a POST request to /api/v1/mcp-services with the JWT token, specifying transport_type: "stdio" and a stdio_config containing the command npx with args ["node", "-p", "require('fs').writeFileSync('/tmp/pwned.txt', 'Hacked by attacker')"] (or any other arbitrary JavaScript/OS payload). Record the returned service ID from the response.
4. Trigger RCE: Send a POST request to /api/v1/mcp-services/{service_id}/test with the JWT token and an empty JSON body {} to trigger execution of the malicious MCP stdio configuration.
5. Verify and Escalate: Confirm code execution by checking for the creation of /tmp/pwned.txt on the server. Replace the payload with a reverse shell, credential harvester, or persistence mechanism to escalate access and move laterally to internal systems (WeKnora Advisory).

• Network: Unexpected POST requests to /api/v1/mcp-services with transport_type: "stdio" in the request body; POST requests to /api/v1/mcp-services/{id}/test shortly after MCP service creation; outbound connections from the WeKnora server process to unknown external IPs (potential reverse shell or C2 traffic).
• Logs: WeKnora API access logs showing rapid account registration followed immediately by MCP service creation and test calls from the same IP or JWT; log entries for npx node -p execution within the application process context.
• File System: Unexpected files created in world-writable directories such as /tmp/ (e.g., pwned.txt or similarly named artifacts); new cron jobs, systemd units, or startup scripts created by the WeKnora service account; web shells or backdoor binaries in application directories.
• Process: Unusual child processes spawned by the WeKnora Go process, such as node, npx, bash, sh, curl, wget, or python; unexpected network listeners opened by child processes of WeKnora.
• Database/Config: Suspicious MCP service entries in the WeKnora database with stdio transport type and unusual args fields containing -p or JavaScript code strings (WeKnora Advisory).

The primary remediation is to upgrade WeKnora to version 0.2.10 or later immediately, as this release disables the stdio-based MCP transport entirely (commit 57d6fea8bc265ad28b385e0158957c870cff4b50), eliminating the vulnerable code path (WeKnora Patch Commit). If immediate upgrade is not possible, restrict network access to the WeKnora API (e.g., firewall rules, VPN-only access) to limit the attack surface. After upgrading, review server logs for suspicious MCP service creation and test calls dating back to when version 0.2.5 was deployed, audit existing MCP configurations for malicious entries, and monitor for unauthorized file creation or unusual child processes. If compromise is suspected, treat the server as breached and conduct a full forensic investigation (GitHub Advisory).

The vulnerability attracted attention partly due to the vendor's silent patching approach — version 0.2.10 fixed the issue without publishing a CVE or security advisory, a practice criticized in the advisory itself as leaving customers unaware and security scanners unable to flag the risk (WeKnora Advisory). OPSWAT's Unit 515 published a blog post highlighting multiple critical RCE vulnerabilities in WeKnora, framing it as a broader concern about security risks in AI platforms (OPSWAT Blog). The vulnerability was discussed on Mastodon/Infosec.Exchange and covered by The Hacker Wire, reflecting moderate community interest given the public PoC and critical severity rating. The OWASP AISVS project also referenced this CVE in a GitHub issue, indicating relevance to AI system security standards discussions.