CVE-2026-30855: Broken Object Level Authorization in Tencent WeKnora

Tencent WeKnora versions prior to 0.3.2 contain a Broken Object Level Authorization (BOLA) vulnerability in the tenant management REST API. The vulnerability allows authenticated users to access, modify, and delete resources belonging to other tenants. This access control failure occurs because the API layer implicitly trusts user-supplied tenant identifiers without validating resource ownership against the active session context.

WeKnora operates as an LLM-powered framework for deep document understanding, inherently processing and storing sensitive API keys and organizational data. The vulnerable endpoints manage the core multi-tenancy architecture, exposing administrative functions to any registered user. Because the platform permits public account registration, the barrier to initial access is exceptionally low.

Exploitation results in a high-severity impact across confidentiality, integrity, and availability. Attackers can extract operational LLM API keys (such as OpenAI or DeepSeek credentials), modify tenant configurations, or completely delete tenant workspaces. The vulnerability is tracked as CVE-2026-30855 and carries a CVSS base score of 8.8.

The root cause of CVE-2026-30855 is the failure of the application's Go-based backend handlers to perform contextual authorization checks. When processing requests to the /api/v1/tenants endpoints, the application extracts the target tenant_id directly from the URL path or request body. The handler then passes this identifier directly to the service layer for database operations.

A secure multi-tenant implementation requires the application to extract the authenticated user's identifier from a trusted source, such as a validated JSON Web Token (JWT) or secure session cookie. The application must then query the database to verify that the authenticated user holds the necessary permissions to act upon the requested tenant_id. The vulnerable version of WeKnora bypasses this critical validation step entirely.

This architectural flaw exposes several REST API endpoints to direct manipulation. The most critical exposure occurs within the GET /api/v1/tenants endpoint, which returns a comprehensive list of all configured tenants in the system. The absence of object-level filtering allows a single authenticated request to dump the entire tenant database, including sensitive nested fields.

Analysis of the vulnerable code path reveals a direct mapping between HTTP request parameters and backend repository queries. Prior to version 0.3.2, the API handlers utilized the tenant_id provided in the HTTP request router without cross-referencing the identity bound to the active request context.

The patch introduces a secure pattern by explicitly scoping repository lookups to the authenticated tenant ID. The application now extracts the validated identifier using context propagation. This value is populated by the authentication middleware after successfully validating the user's token.

The implementation of this fix ensures that the data access layer always enforces ownership boundaries. The repository functions were updated to accept both the requested resource ID and the authenticated tenantID. If a user attempts to access a resource outside their administrative boundary, the repository query naturally fails to match any records, safely denying the request.

// Secure pattern implemented in fixed version
tenantID := ctx.Value(types.TenantIDContextKey).(uint64)
existing, err := s.repo.GetKnowledgeByID(ctx, tenantID, knowledgeID)

Exploitation of CVE-2026-30855 requires an attacker to possess a valid authentication token. Since WeKnora allows public account registration, an attacker can satisfy this prerequisite by creating a standard user account. Upon authenticating, the attacker receives a valid Bearer JWT or session cookie, establishing the required authorization context.

The attack sequence begins with an enumeration phase targeting the /api/v1/tenants endpoint. The attacker issues an HTTP GET request to this endpoint with their valid authentication token. The server responds with a JSON array containing the configuration details of every tenant, disclosing numeric identifiers and plaintext LLM API keys.

Using the enumerated tenant identifiers, the attacker can execute state-changing operations against arbitrary tenants. The attacker issues a PUT /api/v1/tenants/{victim_id} request to overwrite the victim's configurations or a DELETE request to destroy the victim's workspace. These operations succeed because the API strictly evaluates the path parameter without enforcing a boundary check against the attacker's JWT.

The exploitation of CVE-2026-30855 produces a high-severity impact across all three tenets of the CIA triad. The confidentiality impact is absolute, as the vulnerability exposes sensitive LLM API keys, configuration data, and potentially proprietary documents managed within the target workspaces. Attackers can leverage these exposed API keys to consume paid LLM resources, resulting in direct financial loss for the victims.

The integrity and availability impacts are equally critical. The ability to invoke the PUT and DELETE endpoints allows an attacker to unilaterally modify tenant configurations or permanently erase tenant data. The destruction of a tenant workspace halts operations for that organization and necessitates an intensive disaster recovery process.

The vulnerability exhibits a CVSS v3.1 base score of 8.8, reflecting the severity of the flaw and the minimal constraints required for exploitation. The attack complexity is low, and no user interaction is required. The requirement for a low-privileged account is trivial to bypass in deployments configured with public registration.

The primary and most effective remediation for CVE-2026-30855 is upgrading WeKnora to version 0.3.2 or later. This release introduces the necessary authorization middleware and scopes all data access layer operations to the authenticated user's context. Organizations should apply this update immediately to all exposed instances.

If immediate patching is not technically feasible, administrators can implement mitigating controls at the reverse proxy or Web Application Firewall (WAF) layer. Access to the /api/v1/tenants endpoints can be restricted to known, trusted IP addresses. Additionally, administrators should disable public account registration if the deployment model does not explicitly require it.

Organizations compromised by this vulnerability must assume that all LLM API keys stored within the platform have been exposed. Incident response procedures must include the immediate revocation and rotation of all OpenAI, DeepSeek, and other integrated service credentials. Security teams should analyze access logs for unauthorized HTTP GET requests to the tenants endpoint or anomalous state-changing requests.