WeKnora AI Framework Hit with Twin CVSS 9.9 RCE Flaws

Tencent's WeKnora, an LLM-powered framework for document understanding and semantic retrieval, is carrying two critical remote code execution vulnerabilities that attackers can exploit without authentication. Both CVE-2026-30860 and CVE-2026-30861 score CVSS 9.9, one step below the maximum severity rating.

The flaws were publicly disclosed on March 7, 2026, via GitHub Security Advisories. Organizations running WeKnora deployments should treat these as emergency patches—the combination of unauthenticated access and full RCE makes exploitation trivial once attackers identify exposed instances.

CVE-2026-30861: Command Injection via MCP Stdio

The more dangerous of the two, CVE-2026-30861 exploits a command injection flaw in WeKnora's Model Context Protocol (MCP) stdio configuration validation. WeKnora versions 0.2.5 through 0.2.9 are affected.

The application maintains a whitelist of allowed commands (npx, uvx) and blacklists for dangerous arguments and environment variables. The protection falls apart because attackers can bypass these controls using the -p flag with npx node. This flag combination executes arbitrary JavaScript code while satisfying the whitelist check.

Since WeKnora permits unrestricted user registration by default, any attacker can create an account and immediately exploit the command injection to achieve RCE on the host system. The vulnerability runs with whatever privileges the WeKnora process holds—typically enough to compromise the entire server.

Tencent patched this in version 0.2.10.

CVE-2026-30860: SQL Injection to RCE

The second vulnerability takes a different path to the same destination. CVE-2026-30860 affects WeKnora's database query functionality in versions prior to 0.2.12.

WeKnora's query validation fails to recursively inspect child nodes within PostgreSQL array expressions and row expressions. Attackers can smuggle dangerous PostgreSQL functions inside these expression types, bypassing the SQL injection protections entirely.

From there, the attack chains PostgreSQL large object operations with library loading capabilities. The result: arbitrary code execution on the database server with database user privileges. For typical deployments where WeKnora and PostgreSQL share infrastructure, this means full system compromise.

Attack Requirements Are Minimal

Both vulnerabilities require network access and a user account—but WeKnora's default configuration allows public registration. That means the "authentication" barrier effectively does not exist for internet-facing deployments.

The attack complexity is low across both CVEs. No user interaction required. The vulnerabilities affect confidentiality, integrity, and availability—the complete trifecta. An attacker with a valid account can execute arbitrary code on the server, extract sensitive data, modify documents in the semantic retrieval system, or simply destroy the deployment.

AI frameworks like WeKnora often integrate with sensitive document repositories and enterprise knowledge bases. A compromised WeKnora instance could expose proprietary training data, confidential documents, or become a pivot point into connected systems. We've covered similar risks in AI agent configuration theft where attackers target credentials and API keys stored in AI tooling.

Patch Now

The fix is straightforward:

1. Update to 0.2.10 or later to address CVE-2026-30861 (command injection)
2. Update to 0.2.12 or later to address CVE-2026-30860 (SQL injection)

Since 0.2.12 includes both fixes, upgrading to the latest version handles both vulnerabilities.

Organizations should also review whether public registration is actually needed. Disabling open registration won't fix the vulnerability, but it adds an authentication layer that buys time during patch deployment and reduces attack surface going forward.

The AI Security Pattern Continues

WeKnora joins a growing list of AI and ML frameworks catching critical security scrutiny. The n8n workflow automation platform has seen multiple critical RCE vulnerabilities this year, and we've documented various AI agent ecosystem attacks exploiting the rush to deploy LLM-powered tooling. Even ChatGPT's ad rollout raised questions about AI platform security practices.

The pattern is consistent: development teams prioritize capabilities over security hardening, registration stays open by default for "frictionless onboarding," and validation logic has gaps that seem obvious in hindsight. Framework authors deploying database query functionality without recursive expression parsing or command execution with bypassable whitelists are making foundational security errors.

For security teams, the takeaway is clear: treat AI frameworks with the same rigor applied to traditional web applications. Network segmentation, least-privilege database credentials, and authentication hardening apply regardless of whether the application uses LLMs or not. The ML hype does not change security fundamentals.