Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A critical unauthenticated remote code execution (RCE) vulnerability exists in the MCP stdio configuration validation introduced in version 2.0.5. The application allows unrestricted user registration, meaning any attacker can create an account and exploit the command injection flaw. Despite implementing a whitelist for allowed commands (npx, uvx) and blacklists for dangerous arguments and environment variables, the validation can be bypassed using the -p flag with npx node. This allows any attacker to execute arbitrary commands with the application's privileges, leading to complete system compromise. The vulnerability remained unfixed across multiple releases (2.0.6-2.0.9) before being silently patched in version 2.0.10, without a published CVE, potentially leaving customers unaware. Details The application's open registration policy, combined with the vulnerable MCP stdio configuration, creates an unrestricted attack surface. Any attacker can: 1. Register a new account…
Recommended action: Upgrade to 0.2.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A critical Remote Code Execution (RCE) vulnerability exists in the application's database query functionality. The validation system fails to recursively inspect child nodes within PostgreSQL array expressions and row expressions, allowing attackers to bypass SQL injection protections. By smuggling dangerous PostgreSQL functions inside these expressions and chaining them with large object operations and library loading capabilities, an unauthenticated attacker can achieve arbitrary code execution on the database server with database user privileges. Impact: Complete system compromise with arbitrary code execution --- Details Root Cause Analysis The application implements a 7-phase SQL validation framework in internal/utils/inject.go designed to prevent SQL injection attacks: | Phase | Validation Type | Status | |-------|-----------------|--------| | Phase 1 | Null byte and length checks | ✅ Working | | Phase 2 | PostgreSQL AST parsing via pgquerygo/v6 | ✅ Working | | Phase 3…
Recommended action: Upgrade to 0.2.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A broken access control vulnerability in the database query tool allows any authenticated tenant to read sensitive data belonging to other tenants, including API keys, model configurations, and private messages. The application fails to enforce tenant isolation on critical tables (models, messages, embeddings), enabling unauthorized cross-tenant data access with user-level authentication privileges. --- Details Root Cause The vulnerability exists due to a mismatch between the queryable tables and the tables protected by tenant isolation in internal/utils/inject.go. Tenant-isolated tables (protected by automatic WHERE tenantid = X clause): Queryable tables (allowed by WithAllowedTables() in WithSecurityDefaults()): Gap: The tables messages, embeddings, and models are queryable but NOT in the tenant isolation list. This means queries against these tables do NOT receive the automatic WHERE tenantid = X filtering. Vulnerable Code File: internal/utils/inject.go File:…
Recommended action: Upgrade to 0.2.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A DNS rebinding vulnerability in the webfetch tool allows an unauthenticated attacker to bypass URL validation and access internal resources on the server, including private IP addresses (e.g., 127.0.0.1, 192.168.x.x). By crafting a malicious domain that resolves to a public IP during validation and subsequently resolves to a private IP during execution, an attacker can access sensitive local services and potentially exfiltrate data. Details The vulnerability exists because the webfetch tool lacks complete DNS pinning. The application performs URL validation only once via validateParams(), but the URL is then passed unchanged to the fetchHTMLContent() function, which eventually reaches fetchWithChromedp(). The headless browser (Chromedp) resolves the hostname independently without DNS pinning, allowing a time-of-check-time-of-use (TOCTOU) attack. Validation phase (first DNS resolution): Execution phase (second DNS resolution): The original URL (not the resolved IP) is passed…
Recommended action: Upgrade to 0.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A cross-tenant authorization bypass in the knowledge base copy endpoint allows any authenticated user to clone (duplicate) another tenant’s knowledge base into their own tenant by knowing/guessing the source knowledge base ID. This enables bulk data exfiltration (document/FAQ content) across tenants, making the impact critical. Details The POST /api/v1/knowledge-bases/copy endpoint enqueues an asynchronous KB clone task using the caller-supplied sourceid without verifying ownership (see internal/handler/knowledgebase.go). Then, the asynq task handler (ProcessKBClone) invokes the CopyKnowledgeBase service method to perform the clone operation (see internal/application/service/knowledge.go): After that, the CopyKnowledgeBase method calls the repository method to load the source knowledge base (see internal/application/service/knowledgebase.go): Note: until now, the tenant ID is correctly set in context to the attacker’s tenant (from the payload), which can be used to prevent…
Recommended action: Upgrade to 0.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability involving tool name collision and indirect prompt injection allows a malicious remote MCP server to hijack tool execution. By exploiting an ambiguous naming convention in the MCP client (mcp{service}{tool}), an attacker can register a malicious tool that overwrites a legitimate one (e.g., tavilyextract). This enables the attacker to redirect LLM execution flow, exfiltrate system prompts, context, and potentially execute other tools with the user's privileges. Details The vulnerability stems from two issues in the WeKnora client's MCP implementation: 1. Tool Name Collision (Ambiguous Sanitization): The client generates internal tool identifiers by sanitizing and joining the service name and tool name with underscores: mcp{service}{tool}. - Reference: internal/agent/tools/mcptool.go - The registry overwrites existing entries (internal/agent/tools/registry.go), so if a malicious service registers a tool that resolves to an existing name, it silently replaces the…
Recommended action: Upgrade to 0.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authorization bypass in tenant management endpoints of WeKnora application allows any authenticated user to read, modify, or delete any tenant by ID. Since account registration is open to the public, this vulnerability allows any unauthenticated attacker to register an account and subsequently exploit the system. This enables cross-tenant account takeover and destruction, making the impact critical. Details The tenant management handlers do not validate that the caller owns the tenant or has cross-tenant privileges. The handlers parse the tenant ID from the path and directly call the service layer with that ID, returning or mutating the tenant without authorization checks. Affected handlers: - GET /api/v1/tenants lists all tenants without ownership checks - GET /api/v1/tenants/{id} reads any tenant by ID without ownership checks - PUT /api/v1/tenants/{id} allows updating any tenant by ID without ownership checks - DELETE /api/v1/tenants/{id} allows deleting any tenant by…
Recommended action: Upgrade to 0.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The application's "Import document via URL" feature is vulnerable to Server-Side Request Forgery (SSRF) through HTTP redirects. While the backend implements comprehensive URL validation (blocking private IPs, loopback addresses, reserved hostnames, and cloud metadata endpoints), it fails to validate redirect targets. An attacker can bypass all protections by using a redirect chain, forcing the server to access internal services. Additionally, Docker-specific internal addresses like host.docker.internal are not blocked. Details The /api/v1/knowledge-bases/{id}/knowledge/url endpoint validates the initial URL but follows HTTP redirects without re-validating the destination. This allows attackers to: 1. Submit a URL to an attacker-controlled domain (passes validation) 2. Have that domain respond with a 307 redirect to an internal service 3. The backend automatically follows the redirect without checking if the destination is restricted 4. The internal service response is exposed…
Recommended action: Upgrade to 0.2.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Description --- Vulnerability Overview This issue is a command injection vulnerability (CWE-78) that allows authenticated users to inject stdioconfig.command/args into MCP stdio settings, causing the server to execute subprocesses using these injected values. The root causes are as follows: - Missing Security Filtering: When transporttype=stdio, there is no validation on stdioconfig.command/args, such as allowlisting, enforcing fixed paths/binaries, or blocking dangerous options. - Functional Flaw (Trust Boundary Violation): The command/args stored as "service configuration data" are directly used in the /test execution flow and connected to execution sinks without validation. - Lack of Authorization Control: This functionality effectively allows "process execution on the server" (an administrative operation), yet no administrator-only permission checks are implemented in the code (accessible with Bearer authentication only). Vulnerable Code 1. API Route Registration…
Recommended action: Upgrade to 0.2.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
After WeKnora enables its Agent service, it allows users to call database query tools. Due to lax code backend verification, attackers can use prompts to bypass query restrictions and obtain sensitive information from the target server and database. Details Source - File: /internal/agent/tools/databasequery.go - Function: validateAndSecureSQL() (lines 249-373) - API Endpoint: POST /api/v1/agent-chat/{sessionid} Sink - File: /internal/agent/tools/databasequery.go - Function: Execute() (line 158: t.db.WithContext(ctx).Raw(securedSQL).Rows()) - Description: Raw SQL execution without parameterized queries 后端校验语句：/internal/agent/tools/databasequery.go, 273-281: 此处存在两处漏洞： 1. 未校验postgres内置危险函数 2. 未考虑//等注释，可替换空格绕过检测 PoC 攻击prompt： <img width="825" height="563" alt="Image" src="https://github.com/user-attachments/assets/ff86ee6f-aa25-4636-958c-c1468d6422c6" / <img width="1666" height="866" alt="Image" src="https://github.com/user-attachments/assets/50ed98fa-532e-4cc7-aa90-5b3ed21523ff"…
Recommended action: Upgrade to 0.2.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.