CVE-2026-30857: Unauthorized Cross-Tenant Knowledge Base Cloning in WeKnora

WeKnora is an LLM-powered framework designed for deep document understanding and semantic retrieval. Within its architecture, the application relies on strict tenant isolation to partition knowledge bases, documents, and frequently asked questions across different organizational users. A structural flaw in the authorization model affects versions prior to 0.3.0, specifically within the asynchronous knowledge base duplication functionality.

This vulnerability is classified as a Broken Object Level Authorization (BOLA) or Insecure Direct Object Reference (IDOR) weakness under CWE-639. The application exposes an API endpoint that accepts a target knowledge base identifier but fails to validate whether the authenticated requester possesses explicit access rights to that object. Consequently, the system processes the request solely based on the presence of a valid UUID.

Exploitation allows an authenticated user to initiate a background task that systematically clones a knowledge base belonging to another tenant. The cloned data is entirely transferred into the attacker's administrative domain, exposing sensitive organizational information. The attack requires no specialized privileges beyond standard application access within any tenant workspace.

The primary impact is a full loss of confidentiality for the targeted knowledge base. Because the operation is a non-destructive copy, the integrity and availability of the original data remain entirely unaffected, rendering the attack silent from the perspective of the victim. System administrators must rely on secondary audit logs to detect unauthorized cloning operations.

The root cause of the vulnerability resides in the data access pattern utilized by the asynchronous task worker. When a user sends a request to the POST /api/v1/knowledge-bases/copy endpoint, the API handler enqueues a ProcessKBClone task. This task operates independently of the initial HTTP request context, receiving only the source and target identifiers as parameters.

The task worker subsequently invokes the CopyKnowledgeBase service method, which must retrieve the complete configuration and metadata of the source knowledge base. To achieve this, the service calls the GetKnowledgeBaseByID method within the application's repository layer. This repository function is responsible for executing the underlying database query via the GORM library.

The critical failure occurs within this database query, which applies a filter strictly on the primary key id without incorporating the tenant_id associated with the execution context. In multi-tenant systems, isolating data access requires appending a tenant constraint to every read and write operation. The absence of this constraint allows the application to retrieve records globally across the entire database.

By relying entirely on the statistical unguessability of UUIDs as a substitute for explicit access control, the system violates fundamental secure design principles. If an attacker discovers, predicts, or leaks a valid UUID belonging to another tenant, the application provides no secondary defense mechanism to prevent unauthorized data retrieval.

Analyzing the source code reveals the precise nature of the authorization failure at the database level. In WeKnora versions up to 0.2.14, the repository layer implements retrieval operations assuming that the calling service has already performed necessary authorization checks. However, the service layer delegates this responsibility downward, resulting in a gap where no checks occur.

The vulnerable implementation of GetKnowledgeBaseByID queries the database using a simple Where("id = ?", id) clause. This structure instructs the Object-Relational Mapper (ORM) to return the first matching record regardless of the logical boundaries established by the application's multi-tenant architecture.

// internal/application/repository/knowledgebase.go
// Vulnerable Implementation
func (r *knowledgeBaseRepository) GetKnowledgeBaseByID(ctx context.Context, id string) (*types.KnowledgeBase, error) {
	var kb types.KnowledgeBase
	// Only filters by ID, ignoring the tenant context
	if err := r.db.WithContext(ctx).Where("id = ?", id).First(&kb).Error; err != nil {
		if errors.Is(err, gorm.ErrRecordNotFound) {
			return nil, ErrKnowledgeBaseNotFound
		}
		return nil, err
	}
	return &kb, nil
}

The patch introduced in version 0.3.0 correctly enforces tenant isolation directly within the SQL query construction. The remediated code extracts the tenant_id from the provided context and appends it to the Where clause. This structural change guarantees that the database engine itself rejects access attempts where the record's ownership does not match the requester's context.

// internal/application/repository/knowledgebase.go
// Patched Implementation
func (r *knowledgeBaseRepository) GetKnowledgeBaseByID(ctx context.Context, id string) (*types.KnowledgeBase, error) {
	var kb types.KnowledgeBase
	// Extract tenantID from context
	tenantID := ctx.Value(types.TenantIDContextKey).(uint64)
	
	// Enforce tenant scoping in the query
	if err := r.db.WithContext(ctx).Where("id = ? AND tenant_id = ?", id, tenantID).First(&kb).Error; err != nil {
		if errors.Is(err, gorm.ErrRecordNotFound) {
			return nil, ErrKnowledgeBaseNotFound
		}
		return nil, err
	}
	return &kb, nil
}

Exploiting CVE-2026-30857 requires the attacker to fulfill two specific preconditions. First, the attacker must possess a valid, authenticated session within any tenant workspace on the vulnerable WeKnora instance. Second, the attacker must acquire the exact UUID of the target knowledge base they intend to clone, which represents the primary barrier to exploitation.

The attack sequence begins with the generation of an HTTP POST request directed at the knowledge base duplication endpoint. The attacker structures the JSON payload to include the victim's UUID in the source_id field. Because the endpoint does not mandate a specific target_id, the system will automatically allocate a new identifier within the attacker's environment.

curl -X POST http://<weknora-host>/api/v1/knowledge-bases/copy \
  -H "Authorization: Bearer <ATTACKER_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"source_id":"<VICTIM_KB_UUID>","target_id":""}'

Upon receiving the request, the server responds immediately with an HTTP 200 OK status, confirming that the duplication task has entered the asynchronous processing queue. This decoupling of the request and the execution means the exploit does not require maintaining an active connection while the data transfer occurs in the background.

Once the background worker completes the execution cycle, the application materializes a comprehensive duplicate of the victim's knowledge base within the attacker's administrative dashboard. The attacker gains unrestricted read access to all cloned documents, semantic vectors, and internal FAQ structures, completing the exfiltration process.

The security impact of this vulnerability is strictly confined to data confidentiality, but the severity within that domain is high. An attacker successfully executing this technique extracts entire repositories of processed organizational intelligence. For enterprises utilizing WeKnora to parse proprietary documentation, financial records, or internal policies, this represents a complete compromise of sensitive informational assets.

The CVSS 3.1 base score of 5.3 accurately reflects the technical parameters of the flaw. The Attack Complexity is rated as High specifically because the vulnerability relies on the attacker acquiring a 128-bit UUID prior to exploitation. Since the application does not naturally expose external tenant UUIDs through normal operation, the attacker must rely on secondary information disclosure vectors, social engineering, or side-channel leakage to obtain the requisite identifier.

Remediation requires upgrading the WeKnora deployment to version 0.3.0 or later. The update introduces systemic tenant boundary enforcement at the database abstraction layer, permanently neutralizing the authorization bypass. Organizations running affected versions should apply the patch immediately to secure multi-tenant deployments against cross-tenant data access.

For environments where immediate patching is not feasible, administrators can detect active exploitation by implementing targeted log analysis. Security operations teams should correlate asynchronous task creation events, specifically searching for instances where the authenticated user initiating a knowledge base copy does not match the canonical owner of the source_id specified in the task parameters.