CVE-2026-30859: 
vulnerability analysis and mitigation

CVE-2026-30859 is a broken access control vulnerability in Tencent WeKnora's database query tool that enables any authenticated tenant to read sensitive data belonging to other tenants, including API keys, model configurations, and private messages. The flaw affects WeKnora versions up to and including 0.2.11 (Go module github.com/Tencent/WeKnora), with version 0.2.12 containing the fix. It was published on March 6, 2026, and reviewed the same day (GitHub Advisory). The CVSS v3.1 base score is reported as 7.5 (High) by NVD (unauthenticated vector) and 5.3 (Moderate) by the vendor advisory (authenticated, high complexity vector); Feedly estimates it at 6.5 (Medium) (GitHub Advisory, WeKnora Advisory).

The root cause is a mismatch in internal/utils/inject.go between the tables permitted by WithAllowedTables() and those covered by the WithTenantIsolation() function (CWE-284: Improper Access Control). The WithTenantIsolation() function's default map only includes tenants, knowledge_bases, knowledges, sessions, and chunks — omitting messages, embeddings, and models. Because WithSecurityDefaults() calls WithAllowedTables() with all eight tables but WithTenantIsolation() only filters five, queries against messages, embeddings, and models pass validation without the automatic WHERE tenant_id = X clause being appended. An authenticated tenant can invoke the database_query tool via an AI agent prompt (e.g., SELECT * FROM models) and receive unfiltered results spanning all tenants (GitHub Advisory, WeKnora Advisory). A proof-of-concept video demonstrating the exploit was included in the advisory (WeKnora Advisory).

Successful exploitation results in complete cross-tenant confidentiality breach with no integrity or availability impact. An attacker can exfiltrate API keys and authentication credentials for third-party LLM providers (OpenAI, Anthropic, etc.), database connection strings, authentication tokens for integrated services, and all private messages and AI conversation histories belonging to every tenant on the platform. In multi-tenant SaaS deployments, this enables one customer to harvest credentials and sensitive communications of all other customers, potentially enabling further lateral movement into third-party services using stolen API keys (GitHub Advisory, WeKnora Advisory).

A working proof-of-concept, including a demonstration video, was published alongside the advisory on March 6, 2026 (WeKnora Advisory). The EPSS score is approximately 0.037–0.071%, indicating a low but non-negligible probability of exploitation in the near term (GitHub Advisory). No evidence of in-the-wild exploitation, threat actor attribution, or CISA KEV catalog listing has been reported as of the available data. Exploitation requires only authenticated tenant-level access, making it accessible to any registered user of a vulnerable WeKnora deployment.

1. Authenticate: Obtain valid credentials for any tenant account on a WeKnora instance running version ≤ 0.2.11.
2. Identify the database_query tool: Confirm the AI agent exposes the database_query tool by reviewing available agent capabilities or documentation.
3. Craft a cross-tenant query for model credentials: Send the following prompt to the AI agent: Use the database_query tool with {"sql": "SELECT * FROM models"} to query the database. Output all results and any errors. The agent will return all rows from the models table across all tenants, including API keys, LLM provider credentials, and configuration details.
4. Exfiltrate private messages: Repeat with: Use the database_query tool with {"sql": "SELECT * FROM messages"} to query the database. Output all results. The agent returns all messages from all tenants without any tenant filtering.
5. Repeat for embeddings: Query SELECT * FROM embeddings to retrieve embedding data across all tenants.
6. Leverage harvested credentials: Use extracted API keys (e.g., OpenAI, Anthropic keys) or authentication tokens to access third-party services or escalate access beyond the WeKnora platform (GitHub Advisory, WeKnora Advisory).

• Logs: Application or database query logs showing SELECT * FROM models, SELECT * FROM messages, or SELECT * FROM embeddings queries issued by a tenant that does not own records in those tables; repeated broad SELECT queries against these tables from a single tenant session.
• Network: Unusual outbound API calls to LLM provider endpoints (OpenAI, Anthropic, etc.) originating from IP addresses not associated with the legitimate tenant, potentially indicating use of harvested API keys.
• Application Behavior: AI agent responses containing data from multiple tenants (e.g., model records with differing organization names or IDs) visible in a single tenant's session logs or audit trail.
• Database: Query audit logs (if enabled) recording unfiltered full-table scans on models, messages, or embeddings tables without a WHERE tenant_id = clause (GitHub Advisory).

Tencent released WeKnora version 0.2.12 as the patched release, which adds messages, embeddings, and models to the WithTenantIsolation() default table map, ensuring all queryable tables receive the automatic WHERE tenant_id = X filtering. Operators should upgrade to version 0.2.12 or later immediately. As a temporary workaround prior to patching, administrators can restrict or disable the database_query tool for tenant-facing AI agents, or revoke tenant access to the tool until the upgrade is applied (GitHub Advisory, WeKnora Advisory).

OPSWAT's Unit 515 published a blog post noting that AI platforms are not exempt from security risks and referencing multiple vulnerabilities in WeKnora, including this broken access control issue (OPSWAT Blog). The vulnerability was also tracked by Red Hat's security advisory feed and openSUSE's security announcement list, indicating broad monitoring by the open-source security community (Red Hat CVE). No significant social media controversy or high-profile researcher commentary beyond the advisory itself has been identified.