Total
3945 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-70471 | 1 Flowiseai | 1 Flowise | 2026-09-14 | N/A | 6.5 MEDIUM |
| Flowise is a drag-and-drop user interface for building customized large language model (LLM) flows. Prior to 3.1.3, Flowise injects $vars into the code execution sandbox without requiring variables:view, bypassing the permission-protected Variables API. Variables for the active workspace are fetched at packages/components/src/utils.ts and runtime variables are resolved from server environment variables, while the official variables route enforces variables:view. A user or API key that is denied variables:view can call /api/v1/node-custom-function and receive $vars pre-populated with all variables for the workspace, including Variable.name to Variable.value static variables and Variable.name to process.env[Variable.name] runtime variables. This can expose secrets such as database passwords, JWT secrets, SMTP passwords, and cloud keys, depending on the workspace Variables configuration. This issue is fixed in version 3.1.3. | |||||
| CVE-2026-70472 | 1 Flowiseai | 1 Flowise | 2026-09-14 | N/A | 8.8 HIGH |
| Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, Flowise openai-assistants-vector-store endpoints accept a client-controlled credential parameter and load credentials by id without checking whether that credential belongs to the caller workspace. Route permissions assistants:* only check feature access. The controller passes req.query.credential straight to the service, and the service uses findOneBy({ id: credentialId }), decrypts the credential, and calls OpenAI APIs without a workspaceId check. If an attacker knows another workspace credentialId, the attacker can use that workspace OpenAI key, read, modify, or delete victim vector stores and files, cause billing impact on the victim OpenAI account, and violate multi-tenant boundaries. This issue is fixed in version 3.1.3. | |||||
| CVE-2026-90460 | 2026-09-14 | N/A | N/A | ||
| An issue was discovered in OpenStack Keystone before 29.0.3. Tokens obtained via delegated authentication methods (EC2 credentials, application credentials, OAuth1 access tokens, and trusts) are not blocked from creating, modifying, or deleting credentials via the /v3/credentials API. EC2-derived tokens can additionally read credential blobs, exposing TOTP MFA seeds and other secrets. Also, PATCH /v3/credentials does not validate the requested post-update project_id, allowing any delegated token to move a credential to an unauthorized project. All Keystone deployments using delegated authentication are affected. | |||||
| CVE-2026-90450 | 2026-09-14 | N/A | N/A | ||
| The application's role-authorization lookup defaults to granting access when a request handler's name is not present in its table of role requirements, rather than defaulting to deny. Any request handler that is not explicitly registered in this table is reachable by any authenticated user regardless of their assigned role, and any newly added handler is fail-open by default until explicitly added to the table. | |||||
| CVE-2026-56839 | 2026-09-14 | N/A | 7.3 HIGH | ||
| PraisonAI is a multi-agent teams system. Prior to 4.6.59, the CODE_TOOLS wrappers keep _workspace_root as None and pass workspace=None to read_file, search_replace, and apply_diff helpers that enforce path containment only for a truthy workspace. An application that exposes code_read_file, code_search_replace, or code_apply_diff before set_workspace can therefore let prompt-influenced calls read and modify files outside the intended project directory, while explicitly configured workspaces remain effective. This vulnerability is fixed in 4.6.59. | |||||
| CVE-2023-50461 | 2026-09-14 | N/A | 8.8 HIGH | ||
| An issue was discovered in the direct_mail (aka Direct Mail) extension through 9.5.1 for TYPO3. The Configuration backend module of the extension allows an authenticated user to write to an arbitrary TSConfig page for folders configured as Direct Mail. Exploiting this may lead to Configuration Injection (TYPO3 10.4 and above) and to Arbitrary Code Execution (TYPO3 9.5 and below). A valid backend user account, with access to the Direct Mail Configuration backend module, is needed to exploit this. | |||||
| CVE-2026-61910 | 2026-09-14 | N/A | 3.5 LOW | ||
| An issue was discovered in Cyrus IMAP before 3.12.4. Mailbox/set let a sharee change a special-use role on shared mailboxes. An authenticated user with maySetKeywords on another user's mailbox could change that mailbox's specialuse annotation. This could allow the sharee to change the shared mailbox to perform the archived, snoozed, or other role, which might cause mail mail to be written to the shared mailbox, sharing more content than intended. (This is likely to be an unusual situation, made more unusual because if the target already has an non-shared mailbox with that role, role duplication suppression will prevent the update.) | |||||
| CVE-2026-61907 | 2026-09-14 | N/A | 4.3 MEDIUM | ||
| An issue was discovered in Cyrus IMAP before 3.12.4. JMAP snooze bypasses the destination-mailbox ACL. An authenticated user with insert permissions on another user's snoozed mailbox could cause insertion of mail to that user's inbox, or any other of their mailboxes whose id was known to the user, despite having no insert permissions to the target mailbox. | |||||
| CVE-2023-50462 | 2026-09-14 | N/A | 5.3 MEDIUM | ||
| An issue was discovered in the content_consent (aka Content Consent) extension through 2.0.1 for TYPO3. It fails to verify whether a specified content element identifier is permitted by the plugin. This enables an unauthenticated user to display various content elements, leading to an insecure direct object reference (IDOR) issue with the potential to expose internal content elements. | |||||
| CVE-2023-50459 | 2026-09-14 | N/A | 5.4 MEDIUM | ||
| An issue was discovered in the femanager extension 7.x before 7.2.3 for TYPO3. It fails to check access permissions for the edit user component. An authenticated frontend user can exploit this to either edit data of various frontend users or delete various frontend user accounts. | |||||
| CVE-2026-86760 | 2026-09-14 | N/A | 5.4 MEDIUM | ||
| Snipe-IT versions 8.2.0 through 8.6.x (fixed in 8.7.0) contain an incorrect authorization flaw in app/Http/Controllers/Users/UsersController::update(). The single-user edit route assigned the activated field from the request payload before evaluating the canEditAuthFields authorization gate, so an authenticated non-admin user holding the users.edit permission in the target's company scope can submit a full valid PUT request to /users/{id} and toggle the activated flag on any user, including admin and superuser accounts. Deactivating an admin locks that account out of the application until another admin or superuser re-enables it. Only the activated field is affected; username, email, password and permissions remain protected by the gate, no data is disclosed, and the API (Api\UsersController::update) and bulk-edit paths are not affected. | |||||
| CVE-2026-86755 | 2026-09-14 | N/A | 5.4 MEDIUM | ||
| Snipe-IT versions 4.2.0 through 8.6.3 expose Laravel Passport's auto-registered personal-access-token routes (GET, POST, DELETE /oauth/personal-access-tokens*) with only 'web' and 'auth:web' middleware, without the self.api permission gate that Snipe-IT enforces on its own token endpoints (/account/api and /api/v1/account/personal-access-tokens). Any user with a valid web session and the corresponding CSRF token can POST to /oauth/personal-access-tokens and mint a long-lived bearer token for their own account, even when an administrator has denied the self.api permission. The issued token is still subject to existing per-endpoint authorization policies, so this is not a privilege escalation; it defeats the administrative control intended to block API/scripted access at the user's own permission level. Fixed in 8.7.0 (commit 3f74b8c), which registers overriding routes wrapped in the can:self.api middleware. | |||||
| CVE-2026-87575 | 1 Google | 1 Chrome | 2026-09-14 | N/A | 5.4 MEDIUM |
| Incorrect authorization in Loader in Google Chrome prior to 153.0.8010.36 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Low) | |||||
| CVE-2026-87544 | 1 Google | 1 Chrome | 2026-09-14 | N/A | 9.8 CRITICAL |
| Incorrect authorization in Extensions in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to bypass system access restrictions into a privileged page via a crafted HTML page. (Chromium security severity: Low) | |||||
| CVE-2026-53638 | 2026-09-14 | N/A | 4.3 MEDIUM | ||
| Sylius is an Open Source eCommerce Framework on Symfony. Starting in version 2.0.0 and prior to version 2.0.18, 2.1.15, and 2.2.6, an authorization bypass vulnerability exists in the shop account API. The `PATCH /api/v2/shop/account/orders/{tokenValue}/payments/{paymentId}` endpoint, used by an authenticated shop customer to change the payment method of an order that has been placed but not yet paid (state `STATE_NEW`), does not validate that the chosen payment method is enabled for the order's channel. The equivalent checkout endpoint (`PATCH /api/v2/shop/orders/{tokenValue}/payments/{paymentId}`) correctly rejects out-of-channel payment methods with `HTTP 422`; the account endpoint silently accepts them and returns `HTTP 200`. An authenticated customer can therefore assign any globally enabled payment method to their own placed order, including methods that the store operator has explicitly excluded from that channel. The issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6 and above. As a workaround, decorate the `Sylius\Bundle\ApiBundle\Changer\PaymentMethodChangerInterface` service in the application. | |||||
| CVE-2026-3009 | 1 Redhat | 4 Build Of Keycloak, Jboss Enterprise Application Platform, Jboss Enterprise Application Platform Expansion Pack and 1 more | 2026-09-14 | N/A | 8.1 HIGH |
| A security flaw in the IdentityBrokerService.performLogin endpoint of Keycloak allows authentication to proceed using an Identity Provider (IdP) even after it has been disabled by an administrator. An attacker who knows the IdP alias can reuse a previously generated login request to bypass the administrative restriction. This undermines access control enforcement and may allow unauthorized authentication through a disabled external provider. | |||||
| CVE-2026-20773 | 2026-09-14 | N/A | N/A | ||
| A role-based access control issue was identified in the administrative expression evaluation functionality. This could allow users with certain administrative roles to access expression testing capabilities beyond their intended permissions. | |||||
| CVE-2026-42016 | 1 Jfrog | 1 Artifactory | 2026-09-12 | N/A | 8.1 HIGH |
| JFrog Artifactory (Self Hosted) versions before 7.133.11 are vulnerable to a privilege escalation attack due to a validation check of the token signature/issuer and not the token’s scope. | |||||
| CVE-2026-77108 | 1 Adobe | 3 Commerce, Commerce B2b, Magento | 2026-09-11 | N/A | 7.5 HIGH |
| Adobe Commerce is affected by an Incorrect Authorization vulnerability that could result in privilege escalation. An attacker could leverage this vulnerability to gain elevated access to sensitive information. Exploitation of this issue does not require user interaction. | |||||
| CVE-2026-70474 | 1 Flowiseai | 1 Flowise | 2026-09-11 | N/A | 8.1 HIGH |
| Flowise is a drag-and-drop user interface for building customized large language model (LLM) flows. Prior to 3.1.3, Flowise has three OAuth2 credential endpoints that look up credentials by id alone with no workspaceId filter. The authorize, callback, and refresh handlers query the Credential table by id only; callback and refresh are whitelisted from authentication. This allows any authenticated user to initiate OAuth2 flows against credentials belonging to other workspaces, allows an unauthenticated attacker to forge OAuth2 callbacks to overwrite tokens in any credential, and allows an unauthenticated attacker to refresh tokens for any credential. The affected routes include /api/v1/oauth2-credential/authorize/<VICTIM_CREDENTIAL_UUID>, /api/v1/oauth2-credential/callback?code=ATTACKER_AUTH_CODE&state=<VICTIM_CREDENTIAL_UUID>, and /api/v1/oauth2-credential/refresh/<VICTIM_CREDENTIAL_UUID>. This issue is fixed in version 3.1.3. | |||||