Total
4799 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-89032 | 2026-10-01 | N/A | 7.7 HIGH | ||
| BerriAI LiteLLM before 1.101.0-rc.1 contains a tenant isolation bypass vulnerability in the semantic cache layer that allows authenticated users to read other tenants' cached responses by exploiting a metadata key mismatch between _get_semantic_cache_tenant_scope() and _get_metadata_variable_name(). Attackers holding a valid virtual key can submit semantically similar prompts on affected routes such as /v1/responses and /bedrock/* to retrieve cached responses containing other tenants' personally identifiable information, financial data, or source code, and can cause agentic front-ends to auto-execute attacker-supplied tool calls under victim credentials by returning cached function_call or tool_calls payloads to a different principal. | |||||
| CVE-2026-101880 | 2026-10-01 | N/A | 8.8 HIGH | ||
| OpenClaw Windows Node before 2026.7.1 contains an incorrect authorization vulnerability in the system.run exec-approval policy where ExecShellWrapperParser fails to split commands on pipe operators or extract command substitutions. Connected gateways or agents can bypass approval rules by placing denied commands behind allowed prefixes using pipe operators or command substitution syntax, achieving arbitrary command execution on Windows hosts. | |||||
| CVE-2026-101062 | 2026-09-30 | N/A | 8.8 HIGH | ||
| Obot before v0.23.0 (affected versions <= v0.22.1) running with OBOT_SERVER_ENABLE_AUTHENTICATION=true exposes OAuth dynamic client registration without authentication and without any restriction on the redirect URIs a client may register. Because the authorization flow auto-completes for an already logged-in user with no consent screen, an attacker who registers a client pointing at their own domain and induces a logged-in victim to visit a single crafted authorization URL receives an authorization code at the attacker-controlled redirect URI and can exchange it for an access token and refresh token. The token minted by the MCP OAuth flow carries the victim's full group set in the JWT, and Obot validated only the issuer and not the audience, so the token is accepted as a bearer token against any Obot API endpoint the victim can access rather than being scoped to the requested MCP server, allowing the attacker to read or modify the victim's resources until the token is revoked. v0.23.0 adds a consent screen, restricts MCP OAuth tokens to the MCP involved in the request, and enforces audience validation. | |||||
| CVE-2026-100879 | 2026-09-30 | 4.0 MEDIUM | 4.3 MEDIUM | ||
| A security flaw has been discovered in zhistaredu StarTraining up to 3.8.1. This affects the function checkRoleAllowed of the file SysRoleServiceImpl.java of the component dataScope Endpoint. The manipulation results in missing authorization. The attack may be performed from remote. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way. | |||||
| CVE-2025-68129 | 1 Auth0 | 4 Auth0-php, Laravel-auth0, Symfony and 1 more | 2026-09-30 | N/A | 6.8 MEDIUM |
| Auth0-PHP is a PHP SDK for Auth0 Authentication and Management APIs. In applications built with the Auth0-PHP SDK, the audience validation in access tokens is performed improperly. Without proper validation, affected applications may accept ID tokens as Access tokens. Projects are affected if they use Auth0-PHP SDK versions between v8.0.0 and v8.17.0, or applications using the following SDKs that rely on the Auth0-PHP SDK versions between v8.0.0 and v8.17.0: Auth0/symfony versions between 5.0.0 and 5.5.0, Auth0/laravel-auth0 versions between 7.0.0 and 7.19.0, and/or Auth0/wordpress plugin versions between 5.0.0-BETA0 and 5.4.0. Auth0/Auth0-PHP version 8.18.0 contains a patch for the issue. | |||||
| CVE-2025-59376 | 1 Feisky | 1 Mcp-kubernetes-server | 2026-09-30 | N/A | 3.7 LOW |
| feiskyer mcp-kubernetes-server through 0.1.11 does not consider chained commands in the implementation of --disable-write and --disable-delete, e.g., it allows a "kubectl version; kubectl delete pod" command because the first word (i.e., "version") is not a write or delete operation. | |||||
| CVE-2026-76111 | 1 Dell | 13 Powerstore 1000t, Powerstore 1200t, Powerstore 3000t and 10 more | 2026-09-30 | N/A | 8.8 HIGH |
| Dell PowerStore contains an Incorrect Authorization vulnerability. An authenticated attacker with low privileges could potentially exploit this vulnerability to invoke administrator-only operations, leading to privilege escalation. | |||||
| CVE-2026-61519 | 2026-09-30 | N/A | 8.8 HIGH | ||
| Liberu CRM 0.9.1 before 10.0.0 contains a broken access control vulnerability that allows any user holding a pending team invitation to invite additional attacker-controlled accounts with elevated privileges by exploiting a flawed authorization predicate in TeamPolicy::addTeamMember() that grants invitation rights based solely on the existence of a pending invitation email match. Attackers can send a POST request to the team-invitations route specifying the admin role for a second account, bypassing privilege-level validation in InviteTeamMember, causing the second account upon invitation acceptance to be attached to the team with full admin-level create, read, update, and delete access over all team-scoped data. | |||||
| CVE-2026-53769 | 2026-09-30 | N/A | 6.5 MEDIUM | ||
| Avo is a framework to create admin panels for Ruby on Rails apps. From version 2.28.0 to before version 3.32.0, Avo's direct attachment upload endpoint lacks server-side upload authorization and bypasses the documented field-level upload policy methods such as upload_{FIELD_ID}?. An authenticated Avo user who can reach the Avo attachment upload endpoint can replace or add attachment content, including binary content, filename, and content-type metadata, on a resolved record even when both update? and upload_<field>? policies deny the operation. This primarily affects multi-role Avo Pro/Advanced-style deployments where non-administrator or restricted operator users can reach Avo and per-record or per-field operations are expected to be enforced by policies. This issue has been patched in version 3.32.0. | |||||
| CVE-2026-100371 | 2026-09-30 | N/A | N/A | ||
| InvoicePlane is a self-hosted open source application for managing invoices, clients, and payments. In version 1.7.2, an authorization guard to Users::change_password(), was added to address a previous authorization flaw that allowed a secondary administrator (user_type=1, user_id != 1) to directly change the password of the primary administrator (user_id=1) through users/change_password/{id}. That remediation, however, protects only the direct password-change operation. It does not protect the identity attribute that password recovery actually trusts: user_email. Users::form() applies no equivalent object-level authorization check when editing the primary administrator's account, and user_email is not included in PROTECTED_FIELDS. A secondary administrator can therefore rewrite the primary administrator's email address, then drive the public password-recovery flow — which resolves the account by user_email — to receive the reset token and take over user_id=1. The result is an alternate attack path that achieves the same impact PR #1638 was intended to prevent: cross-administrator full account takeover of the primary administrator. This issue has been patched via commit 8616fa4. | |||||
| CVE-2026-61788 | 2026-09-30 | N/A | 7.4 HIGH | ||
| DBHub is a database MCP server for Postgres, MySQL, SQL Server, Oracle, MariaDB, SQLite. Prior to version 0.22.6, setting `readonly = true` on the `execute_sql` tool does not make the connection read-only. The connectors are written to set PostgreSQL `default_transaction_read_only=on` (and open SQLite in `readOnly` mode), but that code is gated on a config value that is never populated, so it never runs. The only thing left enforcing read-only is a classifier that inspects the first keyword of each statement. Any `SELECT` that writes or has side effects through a function call passes it. With an ordinary role this allows sequence tampering; with a privileged role it allows writing arbitrary files on the server (`lo_export`), reading arbitrary host files (`pg_read_file`), and remote code execution (`dblink` + `COPY ... TO PROGRAM`). The HTTP transport is unauthenticated and binds to `0.0.0.0` by default, so this is reachable by any network caller of `/mcp`. Version 0.22.6 patches the issue. | |||||
| CVE-2026-101914 | 2026-09-30 | N/A | 6.5 MEDIUM | ||
| @grpc/grpc-js implements the core functionality of gRPC purely in JavaScript, without a C++ addon. Prior to 1.13.1 and 1.14.1, the exact path (method name) matcher used by RBAC performs a prefix comparison instead of an equality comparison when case-insensitive matching is enabled. If one service method name prefixes another and the methods have different access rules, a request for the longer method can match the shorter method's rule and cause incorrect authorization. This issue is fixed in versions 1.13.1 and 1.14.1. | |||||
| CVE-2026-100392 | 2026-09-30 | N/A | N/A | ||
| InvoicePlane is a self-hosted open source application for managing invoices, clients, and payments. In version 1.7.2, Users::form() performs no object-level authorization check on user_id = 1. A Secondary Administrator (user_type = 1, user_id != 1) can rewrite the Primary Administrator's user_type to 2 (Guest / read-only), destroying the root account's privilege and locking the legitimate owner out of the instance. At time of publication, there are no publicly available patches. | |||||
| CVE-2026-55866 | 2026-09-30 | N/A | 3.7 LOW | ||
| SpiceDB is an open source database system for creating and managing security-critical application permissions. From 1.34.0 until 1.54.0, SpiceDB can return PERMISSIONSHIP_HAS_PERMISSION instead of PERMISSIONSHIP_CONDITIONAL_PERMISSION or PERMISSIONSHIP_NO_PERMISSION because checkRequestToKey() and checkRequestToKeyWithCanonical() in internal/dispatch/keys/computed.go omit CheckHints when constructing dispatch Check cache keys. The incorrect result requires a permission combining relations with intersection or exclusion, a subject reachable through caveated and non-caveated branches, LookupResources with a context parameter running concurrently with CheckPermission or CheckBulkPermissions for the same resource and subject, and an enabled dispatch result cache. Under these conditions, a result computed for one hint set can poison the cache entry used by a semantically different authorization check, allowing permission without satisfying the caveat. This issue is fixed in version 1.54.0. | |||||
| CVE-2026-102330 | 1 Google | 1 Chrome | 2026-09-30 | N/A | 6.5 MEDIUM |
| Incorrect authorization in SiteIsolation in Google Chrome prior to 154.0.8037.92 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) | |||||
| CVE-2026-93379 | 1 Google | 1 Chrome | 2026-09-30 | N/A | 4.3 MEDIUM |
| Incorrect authorization in ORB in Google Chrome prior to 153.0.8010.52 allowed a remote attacker to bypass site isolation via a crafted HTML page. (Chromium security severity: Low) | |||||
| CVE-2026-88862 | 2026-09-30 | N/A | 8.8 HIGH | ||
| Capgo (capgo.app) backend through 12.242.4 does not validate parent-child delegation when processing the x-limited-key-id header. checkKeyByIdPg() in supabase/functions/_backend/utils/hono_middleware.ts resolves the attacker-supplied numeric API key ID using only the key ID, its expiration state, and the authenticating key's user_id, while hasLimitedRbacSubkeyScope() accepts any key with a non-organization (e.g., app-scoped) RBAC binding and validateSubkeyUser() only compares owning user IDs. Because Capgo treats API keys as independent RBAC principals with separate role bindings, an authenticated apikey_manager API key with no application access can supply the numeric ID of a more privileged same-owner key and have the middleware replace the authenticated principal and effective API-key secret with that key (setSubkeyAuthContext), exercising an app_admin sibling's permissions without knowing or submitting its secret. The issue was reproduced on release 12.242.4 (commit b3d02cdbc23ac59990785acacd1f113c07458568) after the fix for GHSA-8h52-44r7-w343; at the time of the advisory no patched version was available. | |||||
| CVE-2026-88860 | 2026-09-30 | N/A | 6.3 MEDIUM | ||
| Capgo fails to clean up channel permission overrides when a user's last organization role binding is deleted, leaving stale overrides active. Attackers can retain channel-specific permissions after their base RBAC access has been revoked to perform unauthorized actions like changing production OTA versions. | |||||
| CVE-2026-65054 | 2026-09-30 | N/A | 3.1 LOW | ||
| MediaCMS 8.2.0 contains an information disclosure vulnerability that allows authenticated users to expose private media metadata belonging to other users by adding arbitrary media tokens to their own playlist without access control checks. Attackers can issue a PUT request to the playlist API endpoint with a known media token to bypass state and ownership validation, then retrieve the playlist to read private media fields including title, description, view count, like count, file size, author username, and encoding status through the unfiltered playlist owner branch in the playlist detail view. | |||||
| CVE-2026-100623 | 2026-09-30 | N/A | 8.8 HIGH | ||
| Capgo (capgo.app) exposes the legacy membership table public.org_users directly through Supabase PostgREST. The table's row-level security policies "Allow org admin to insert" and "Allow org admin to update" only verify that the caller has admin rights in the target organization (public.check_min_rights('admin', ...)); they do not require a pending invitation in tmp_users, acceptance of an invite token via /private/accept_invitation, any action by the target user, or the membership/role-consistency and anti-escalation checks enforced by the RBAC role-binding path. As a result, an authenticated user who is an admin of an organization can INSERT or UPDATE org_users rows directly to add any existing public.users account as an active member of that organization with user_right="admin", bypassing the invitation and role-assignment workflow entirely. In testing, an account with no prior access to the organization or its apps could, after such a direct insert, read the organization and app and pass check_min_rights. All versions are affected and no patch was available at the time of publication. | |||||