C4Tzzz

Flowise is a low-code platform for building LLM applications. In versions up to and including 3.1.3, the POST /api/v1/node-load-method/:name endpoint is mounted without any route-level permission check and invokes component loadMethods with an attacker-controlled nodeName, loadMethod, inputs, and credential value. The selected credential is resolved by raw Credential.id via getCredentialData() and decrypted without verifying Credential.workspaceId against the caller's active or shared workspace, unlike other credential read paths which are workspace-scoped. As a result, an authenticated low-privilege user (or workspace API key) in one workspace can supply a credential ID owned by another workspace and cause Flowise to act as a confused deputy, performing third-party provider calls with the victim workspace's credential and returning provider metadata to the attacker. Statically identified affected load methods include Google Drive listFiles, Google Sheets listSpreadsheets, and AWS DynamoDB KV Storage listTables. The raw credential secret itself is not returned to the attacker. This issue is fixed in version 3.1.4.

**Name of the Vulnerable Software and Affected Versions** AnythingLLM versions prior to 1.13.0 **Description** An issue exists where a mobile device token created in single-user mode remains valid after migration to multi-user mode, even if the device record has `userId` set to null. The mobile authentication middleware continues to accept this stale token. Since no user is associated with the request, mobile handlers use unscoped data-access branches, returning workspaces and content without per-user filtering. This allows a pre-migration token to enumerate workspaces assigned to other users and retrieve thread metadata and chat content. **Recommendations** Update to version 1.13.0.

**Name of the Vulnerable Software and Affected Versions** AnythingLLM versions prior to 1.12.1 **Description** An insecure direct object reference (IDOR) exists in the text-to-speech endpoint. The endpoint "/api/workspace/:slug/tts/:chatId" validates workspace membership but fails to enforce ownership of the targeted chat row. This allows an authenticated user to access another user's private assistant response in audio form if the `chatId` is known or guessed. **Recommendations** Update to version 1.12.1.