CVE-2026-30855: 
vulnerability analysis and mitigation

CVE-2026-30855 is a Broken Access Control (BOLA/IDOR) vulnerability in the tenant management functionality of Tencent's WeKnora, an AI-powered knowledge management platform. The flaw allows any authenticated user to read, modify, or delete tenants belonging to other customers without authorization. Because account registration is publicly open, this effectively enables unauthenticated attackers to self-register and then exploit the system. All versions up to and including 0.3.1 are affected; version 0.3.2 contains the fix. The CVSS v3.1 base score is 8.8 (High) per the vendor advisory, though the GitHub Advisory Database also lists a 9.8 (Critical) score reflecting the practical unauthenticated attack path (GitHub Advisory, WeKnora Advisory). The vulnerability was published on March 6, 2026, and reported by researcher aleister1102.

The root cause is CWE-284 (Improper Access Control): the tenant management API handlers parse the tenant ID directly from the URL path and pass it to the service layer without verifying that the requesting user owns or has cross-tenant privileges over that tenant (WeKnora Advisory). Four endpoints are affected: GET /api/v1/tenants (lists all tenants), GET /api/v1/tenants/{id} (reads any tenant), PUT /api/v1/tenants/{id} (modifies any tenant), and DELETE /api/v1/tenants/{id} (deletes any tenant) — none enforce ownership or deny-by-default behavior. Exploitation requires only a valid bearer token or API key, which any self-registered user can obtain, making the effective privilege requirement none. The advisory includes concrete HTTP request/response examples demonstrating the full exploit chain (GitHub Advisory).

Successful exploitation results in complete cross-tenant compromise: an attacker can enumerate all tenant IDs and their associated API keys via GET /api/v1/tenants, then use harvested API keys to impersonate victim tenants and access their knowledge bases, LLM service API keys (e.g., OpenAI, Anthropic), and other sensitive configurations (WeKnora Advisory). Beyond data theft, attackers can destructively delete any tenant or overwrite tenant configurations, causing availability loss for all affected customers. The multi-tenant nature of the platform means a single exploit can cascade across all customer organizations hosted on the same WeKnora instance.

A proof-of-concept exploit with step-by-step HTTP request examples is publicly available in the official security advisory (WeKnora Advisory). The EPSS score is approximately 0.078–0.171%, indicating a relatively low but non-negligible probability of exploitation in the next 30 days. No in-the-wild exploitation or threat actor attribution has been reported as of the time of disclosure. The vulnerability is not currently listed in the CISA KEV catalog. Qualys has added detection for this vulnerability (detection ID 761789) (Feedly).

1. Register an account: Navigate to the public WeKnora registration page and create a free account. Obtain the bearer token or API key (sk-...) assigned to your new tenant.
2. Enumerate all tenants: Send a GET /api/v1/tenants request with your API key in the X-API-Key header. The response returns a full list of all tenant IDs, names, and their API keys across all customers.

GET /api/v1/tenants HTTP/1.1
Host: <target>
X-API-Key: sk--HmGzVTrUW-p334ddZzJnucebiWBZ63AH5qKVO0EY4QNrELd

3. Extract victim tenant API keys: From the response JSON, collect the api_key values for target tenants (e.g., tenant ID 10001).
4. Impersonate victim tenant: Use the harvested API key to authenticate as the victim tenant and access their knowledge bases, LLM API keys, and configurations.
5. Modify victim tenant (optional): Send a PUT /api/v1/tenants/10001 request with a modified body to overwrite the victim's tenant name or settings.

PUT /api/v1/tenants/10001 HTTP/1.1
Host: <target>
Authorization: Bearer <your_token>
Content-Type: application/json

{"name": "HACKED by tenant 10025"}

6. Delete victim tenant (optional): Send DELETE /api/v1/tenants/10001 to permanently destroy the victim's tenant and all associated data (WeKnora Advisory).

• Network: Unusual GET /api/v1/tenants requests from IP addresses not associated with known tenant users; sequential or bulk GET /api/v1/tenants/{id} requests iterating over numeric tenant IDs from a single source IP; PUT or DELETE requests to /api/v1/tenants/{id} from users whose own tenant ID does not match the target ID in the path.
• Logs: API access logs showing a single API key or bearer token accessing tenant IDs other than its own; 200 OK responses to cross-tenant modification or deletion requests; sudden spike in tenant enumeration requests from a newly registered account.
• Application: Unexpected changes to tenant names (e.g., names containing attacker-controlled strings); tenants disappearing from the platform without admin action; LLM service API keys being used from unexpected IP addresses or geographic regions after a WeKnora access event (WeKnora Advisory).

Upgrade WeKnora to version 0.3.2 or later, which introduces proper ownership validation in tenant management handlers (WeKnora Advisory, GitHub Advisory). For deployments that cannot be immediately patched, restrict network-level access to the WeKnora API to trusted IP ranges only. As a precautionary measure, rotate all LLM service API keys configured within WeKnora tenants, and review API access logs for any unauthorized cross-tenant activity. Implement audit logging on tenant management endpoints to detect future unauthorized access attempts.

OPSWAT's Unit 515 published a blog post noting that AI platforms are not exempt from security risks, referencing multiple critical vulnerabilities in WeKnora (OPSWAT Blog). The vulnerability received coverage from The Hacker Wire and was discussed on Mastodon and Bluesky shortly after disclosure. Community sentiment highlighted the risk of LLM API key exposure as a particularly impactful consequence given the growing adoption of AI platforms in enterprise environments.