CVE Vulnerability Catalog

In MaxKB versions 2.7.0 through 2.10.4-lts, the POST /chat/api/{application_id}/chat/{chat_id}/share_chat endpoint verifies only that a conversation exists but does not verify it belongs to the authenticated chat_user_id or the application bound to the caller's token. An attacker with any chat token and a known victim chat_id can create a public ChatShareLink exposing the victim's conversation and PublicFileAccess state making associated files retrievable without credentials, with no revoke path.

Session invalidation flaw in x-ui 0.3.2. The full user object is stored in a client-side signed cookie, and authentication does not re-validate against the database. Changing username or password does not revoke previously issued cookies, so an attacker with a valid cookie can continue accessing the admin panel.

In MaxKB 2.10.2-lts and earlier, management chat-record routes authorize the path application_id but load records using global chat_id and chat_record_id values without confirming the chat belongs to the authorized application. A normal user in the same workspace who knows the chat_id of a persisted record for a victim's published application can read victim chat records and copy victim answers via add_knowledge.

In MaxKB 2.10.3-lts and earlier, the knowledge web-document import and synchronization crawler passes an authenticated user's URL to Fork.fork, which calls requests.get with verify=False and without restricting schemes, loopback, link-local, private, or reserved addresses. The response body becomes imported document content, allowing a low-privileged user to read cloud metadata or internal HTTP services through the MaxKB server.

In MaxKB 2.10.2-lts and earlier, a normal user in the same workspace can obtain another user's application_id from the homepage application question-ranking endpoint when the victim's published application has ranking activity in the selected date range. An attacker who can create and publish workflow applications can place the disclosed identifier in a workflow node, trigger it, receive victim application output, and create durable application_chat records under the victim application.

In MaxKB 2.10.2-lts and earlier, the /chat/api/mcp authentication path looks up an ApplicationApiKey using only its secret and active status, without enforcing the is_permanent and expire_time checks used by the standard chat API. A previously valid, non-permanent application key that remains active after expiration can initialize the MCP endpoint, list tool metadata, invoke tools/call, and create durable application_chat state.

In MaxKB 2.10.2-lts and earlier, a normal workspace user who knows another user's active MCP tool_id can retrieve the hidden tool through the tool-detail route, which does not apply per-resource authorization used by the list route. The response includes Tool.code, which may contain MCP server configuration and headers, and an attacker who can create or edit a workflow can place the foreign mcp_tool_id in a workflow mcp-node so debug uses the owner's MCP configuration.

In MaxKB from version 2.0.0 through 2.10.2-lts, document and paragraph operate routes authorize only knowledge_id in the request path, then query the target Document by document_id or Paragraph by paragraph_id without confirming the object belongs to that knowledge base. A normal workspace user with a known victim document or paragraph UUID can read or modify content in another user's knowledge base.

In MaxKB from version 2.0.0 through 2.9.2, a lowest-role workspace member denied access to a tool by WorkspaceUserResourcePermission can still bind its identifier through tool_ids, skill_tool_ids, or mcp_tool_ids and execute it through the agent or workflow dispatch path. The dispatch path does not reapply the per-tool grant, and tool execution decrypts server-side init_params, allowing the caller to receive credentials carried by the denied tool.

In Envoy prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1, URL normalization does not recognize dot and dotdot path segments when they carry semicolon parameters. A request such as /user/..;foo=bar/admin is not canonicalized to /admin even when path normalization is enabled. If an upstream interprets the segment per RFC 3986 while Envoy applies routing or RBAC to the uncollapsed path, a remote client can cause path confusion and bypass path-based security policy.

In Envoy prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1, Envoy normally matches the raw request path, while servlet backends such as Apache Tomcat strip semicolon matrix parameters from each path segment before resolving the resource. The ignore_path_parameters_in_path_matching option truncates at the first semicolon and still does not match per-segment backend behavior. A remote client can use a parameterized protected segment to make Envoy select an unprotected fallback while the backend resolves the protected resource.

Joplin Server before version 3.7.7 with TRANSCRIBE_ENABLED=true has a vulnerability in the GET/POST /api/transcribe/:id routes where the decoded id is passed directly to transcription backend URLs. An authenticated user can use URL-encoded slash and parent-directory segments to escape the intended /transcribe/ prefix and proxy requests to other internal endpoints, potentially exposing administrative, health, or configuration data. This issue is fixed in version 3.7.7.

Sync-in Server before version 2.4.1 has an observable timing discrepancy in the login endpoint because authentication attempts for nonexistent accounts return without performing the bcrypt comparison used for existing accounts. An unauthenticated attacker can measure response times to enumerate valid usernames or email addresses, facilitating credential-stuffing, password-spraying, and phishing attacks. Version 2.4.1 contains a patch.

Sync-in Server before version 2.4.0 has a vulnerability in the sync diff endpoint where it compiles a user-supplied string into a RegExp with no complexity validation. A catastrophic-backtracking pattern (e.g. ^(a+)+b) blocks the Node.js event loop, making the entire server unresponsive to all users until the container is restarted. Version 2.4.0 patches the issue.

Joplin Server before version 3.7.2 has a vulnerability in the GET /items/:id/content route that loads item content from an attacker-supplied internal server ID without checking whether the signed-in user owns or can access that item. Any authenticated user who obtains or guesses another user's item ID can read the corresponding note or item content when end-to-end encryption does not protect it. This issue is fixed in version 3.7.2.

Stencil core 4.43.5 contains a DOM-based cross-site scripting (XSS) vulnerability in the component runtime. When a downstream application enables the experimental slot fixes option and uses scoped components, assigning a string to the textContent property of such a component's host element causes the value to be parsed as HTML instead of being inserted as text. If an application writes attacker-controlled data to these host elements, the data can be interpreted as markup and script can execute in the context of the application's origin.

Stencil core 4.43.5 is vulnerable to Incorrect Access Control.

web2py 3.2.2-stable (commit a7330a2bf21219fa77860b6665de927dd4f98e6d) is vulnerable to Directory Traversal in read_file()/write_file() (applications/admin/controllers/webservices.py).

Envoy before versions 1.36.10, 1.37.6, 1.38.4, and 1.39.1 has a vulnerability in Utility::copyInternetAddressAndPort and QUIC client-address paths that reconstruct scoped IPv6 addresses. The string includes a percent scope identifier that inet_pton cannot parse, causing an exception or abort. Kernel-provided scoped IPv6 destinations in ORIGINAL_DST transparent-proxy deployments, and affected QUIC connection paths, can therefore terminate the process. This issue is fixed in versions 1.36.10, 1.37.6, 1.38.4, and 1.39.1.

Supabase Realtime before version 2.111.2 has a vulnerability in authorization that does not correctly honor the per-extension presence.read row-level security policy when a private-channel client is allowed presence.write but explicitly denied presence.read. Under that differential policy, the client can receive presence_diff messages containing other members' presence metadata, including application-defined location, online-status, roster, viewing, or typing information. Deployments with uniform presence visibility have no differential, and postgres_changes row data is unaffected. This issue is fixed in version 2.111.2.