Aleister1102

Improper validation in the Auth0.js SDK may allow the return of user profile data when a specifically crafted invalid ID token is used in conjunction with a valid access token. This issue occurs in applications where access control relies on rules defined in Auth0 Actions, potentially leading to unauthorized information disclosure.

Name of the Vulnerable Software and Affected Versions Nest versions prior to 11.1.18 Description The `SseStream. transform()` function interpolates `message.type` and `message.id` directly into Server-Sent Events text protocol output without sanitizing newline characters (r, ). Because the SSE protocol uses both r and as field delimiters and as event boundaries, an attacker who can influence these fields can inject arbitrary SSE events, spoof event types, and corrupt reconnection state. An attacker can forge SSE events with arbitrary `event:` types, causing client-side `EventSource.addEventListener()` callbacks to fire for incorrect event types. They can also inject arbitrary `data:` payloads, potentially leading to XSS if the client renders SSE data as HTML without sanitization. Additionally, attackers can inject `id:` fields, corrupting the `Last-Event-ID` header on reconnection, causing the client to miss or replay events. The attack requires the developer to map user-influenced data to the `type` or `id` fields of SSE messages. Recommendations Update to version 11.1.18 or later.

The Go MCP SDK’s Streamable HTTP transport was susceptible to accepting browser-generated cross-site `POST` requests without validating the `Origin` header or requiring `Content-Type: application/json`. In deployments lacking Authorization, particularly in stateless or sessionless setups, this permitted an arbitrary website to send MCP requests to a local server, potentially triggering tool execution. A malicious website could send cross-site POST requests with `Content-Type: text/plain`, bypassing CORS preflight barriers due to CORS-safelisted properties. The vulnerable component is the Streamable HTTP transport. The API endpoint is accepting `POST` requests. The vulnerable parameter is the `Origin` header.

WeKnora, an LLM-powered framework for deep document understanding and semantic retrieval, contains an unauthenticated remote code execution (RCE) issue in the MCP stdio configuration validation. The application permits unrestricted user registration, allowing attackers to create accounts and exploit a command injection flaw. Despite the implementation of command whitelists (`npx`, `uvx`) and argument/environment variable blacklists, the validation can be bypassed using the `-p` flag with `npx node`. This enables attackers to execute arbitrary commands with the application’s privileges, potentially leading to complete system compromise. The vulnerable code flow involves the `ValidateStdioConfig()` and `ValidateStdioArgs()` functions, where the `-p` flag is not blocked in the `DangerousArgPatterns` regex list, allowing execution of JavaScript payloads via `npx node -p <payload>`. The issue was silently patched in version 0.2.10, without a public CVE or security advisory, potentially leaving customers unaware.

WeKnora is a framework for deep document understanding and semantic retrieval. A cross-tenant authorization bypass exists in the knowledge base copy endpoint. An authenticated user can clone another tenant’s knowledge base into their own tenant by knowing or guessing the source knowledge base ID, leading to bulk data exfiltration. The issue is due to insufficient access control checks when handling the `source id` parameter in the `POST /api/v1/knowledge-bases/copy` endpoint. Specifically, the `GetKnowledgeBaseByID` function in the repository layer does not enforce tenant isolation, allowing access to knowledge bases across tenants. The vulnerable code copies knowledge base configuration and content from the source knowledge base to a new knowledge base under the attacker’s tenant. The `source id` parameter, supplied by the attacker, is used without proper validation.

WeKnora, an LLM-powered framework for deep document understanding and semantic retrieval, contains a DNS rebinding issue in the `web fetch` tool. An unauthenticated attacker can bypass URL validation and access internal resources on the server, including private IP addresses like 127.0.0.1 and 192.168.x.x. This is possible by crafting a malicious domain that initially resolves to a public IP address during validation and then resolves to a private IP address during execution. The `web fetch` tool lacks complete DNS pinning, performing URL validation only once via the `validateParams()` function. The original URL is then passed unchanged to the `fetchHTMLContent()` function, which ultimately calls `fetchWithChromedp()`. The headless browser (Chromedp) independently resolves the hostname without DNS pinning, creating a time-of-check-time-of-use (TOCTOU) condition. The vulnerability allows access to sensitive local services and potential data exfiltration.

WeKnora, an LLM-powered framework for deep document understanding and semantic retrieval, contains a remote code execution (RCE) issue in its database query functionality. The application's validation system does not thoroughly inspect child nodes within PostgreSQL array expressions and row expressions, allowing attackers to bypass SQL injection protections. By embedding malicious PostgreSQL functions within these expressions and combining them with large object operations and library loading capabilities, an unauthenticated attacker can execute arbitrary code on the database server with the privileges of the database user. The issue stems from incomplete validation within the `validateNode()` function, specifically the lack of handlers for `ArrayExpr` and `RowExpr` node types. This allows attackers to smuggle dangerous functions, such as `pg read file`, `lo from bytea`, `lo put`, `lo export`, and `pg reload conf`, into queries. A proof-of-concept demonstrates the ability to read arbitrary files, upload a malicious shared library, and ultimately achieve code execution. Successful exploitation could lead to complete system compromise, including data extraction, modification, service disruption, persistence, and lateral movement.

WeKnora is a framework for deep document understanding and semantic retrieval. A broken access control issue in the database query tool allows any authenticated tenant to read sensitive data belonging to other tenants. This includes API keys, model configurations, and private messages. The application does not enforce tenant isolation on critical tables (`models`, `messages`, `embeddings`), enabling unauthorized cross-tenant data access with user-level authentication privileges. The root cause is a mismatch between queryable tables and tables protected by tenant isolation. Specifically, the tables `messages`, `embeddings`, and `models` are queryable but not protected by tenant isolation, meaning queries against these tables do not have the automatic `WHERE tenant id = X` filtering applied. An attacker can exploit this by crafting SQL queries via the `database query` tool to access sensitive data from other tenants. The vulnerable code resides in `internal/utils/inject.go` and `database query.go`.

PinchTab is a standalone HTTP server designed to provide AI agents with direct control over a Chrome browser. A Server-Side Request Forgery (SSRF) condition exists in the `/download` endpoint. This allows a user with API access to force the PinchTab server to make requests to arbitrary URLs, including internal network services and local system files, and then retrieve the full response content. The vulnerability is located in the `GET /download?url=<url>` handler within the `download.go` file, specifically at line 78, where the user-controlled `url` parameter is passed to `chromedp.Navigate(dlURL)` without proper validation. This allows access to local files using the `file://` scheme, internal services, and cloud metadata endpoints. The server then returns the captured response body to the attacker, enabling the exfiltration of sensitive data.

WeKnora is a framework for deep document understanding and semantic retrieval. A flaw exists in the tenant management endpoints that allows authenticated users to read, modify, or delete any tenant by ID. Because account registration is open to the public, an unauthenticated attacker can register an account and exploit this issue. This can lead to cross-tenant account takeover and destruction. The affected API endpoints are: - `/api/v1/tenants` - `/api/v1/tenants/{id}` The vulnerability occurs because the tenant management handlers do not validate ownership or cross-tenant privileges before performing actions. The handlers directly use the tenant ID from the path without authorization checks. The `id` variable in the API endpoint `/api/v1/tenants/{id}` is particularly vulnerable.

WeKnora, an LLM-powered framework for deep document understanding and semantic retrieval, is susceptible to a vulnerability involving tool name collision and indirect prompt injection. A malicious remote MCP server can 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, such as `tavily extract`. This allows redirection of the LLM execution flow, exfiltration of system prompts and context, and potential execution of other tools with the user's privileges. The vulnerability arises from the client's tool name collision and unsanitized tool/metadata output. The client generates internal tool identifiers by sanitizing and joining the service name and tool name with underscores. The registry overwrites existing entries, allowing a malicious service to replace legitimate implementations. The client feeds MCP tool descriptions and execution results directly back into the LLM context without sanitization, enabling a malicious tool to return instructions (Prompt Injection) that the LLM interprets as trusted commands.

The application’s "Import document via URL" feature is susceptible to Server-Side Request Forgery (SSRF) through HTTP redirects. While the backend implements comprehensive URL validation, it fails to validate redirect targets. An attacker can bypass protections by using a redirect chain, forcing the server to access internal services. Docker-specific internal addresses like `host.docker.internal` are not blocked. 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 submit a URL to an attacker-controlled domain, which responds with a 307 redirect to an internal service, enabling access to internal services and potential data exposure. The `IsSSRFSafeURL()` function validates the initial URL but does not validate HTTP redirect targets.