| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Baserow dispatches an Application Builder data source without acting on the result of its permission check. The dispatch and record-name views in backend/src/baserow/contrib/builder/api/data_sources/views.py are declared with a permission class that admits any caller, so a request carrying no credential reaches the handler. DataSourceService.dispatch_data_sources in backend/src/baserow/contrib/builder/data_sources/service.py then calls check_multiple_permissions without asking it to raise, and neither stores nor examines the mapping of denials it returns, so a denied check leaves execution to continue and the data source is dispatched whatever the caller's identity. The dispatch runs with the integration's own credentials, so an unauthenticated request naming a data source receives the rows and fields that source reads. Identifiers are small integers and can be enumerated. Version 2.3.1 passes raise_exception to the same call. |
| The updateWorkspace handler in mods/identity/src/workspaces/createUpdateWorkspace.ts in Fonoster through 0.22.7 invokes the gRPC callback with PERMISSION_DENIED when createIsWorkspaceMember reports that the caller is not a member of the target workspace, but it does not return. Execution continues into prisma.workspace.update, which is scoped by the workspace reference alone, so the rename commits before the second callback is issued and the caller receives a permission error for a write that already succeeded. The gRPC interceptor in mods/common/src/identity/createAuthInterceptor.ts binds the workspace accessKeyId to the caller's token only for paths in workspaceResourceAccess or workspaceResourceOwnerOrAdminAccess, and Identity/UpdateWorkspace is listed in fullIdentityAccess, which the base USER role holds. Any authenticated user can therefore rename an arbitrary workspace in the deployment. |
| On Linux, several OpenZFS ioctl authorization checks accept a capability held only within a user-created, unprivileged namespace as equivalent to real host privilege, allowing an unprivileged local user to perform operations that should require root. Affected operations include pool-administrative operations (eg create, import, destroy), pool event log access (zpool events) and fault injection (zinject). Exploiting the problem requires only that the local user is permitted to open /dev/zfs (governed by local device permissions) and that the kernel permits unprivileged user namespace creation. No prior access to the target pool or its underlying devices is needed. |
| Improper input validation in FreeRTOS-Kernel before 11.3.1 might allow an unprivileged task on MPU-enabled ports to execute code in privileged kernel context. To remediate this issue, users should upgrade to version 11.3.1 or later. |
| Leantime JSON-RPC API through version 3.9.0 contains a missing authorization vulnerability in the JSON-RPC dispatcher in app/Domain/Api/Controllers/Jsonrpc.php. The dispatcher does not enforce authorization before invoking service-layer methods, allowing an authenticated user to call methods or act on resources outside their intended permissions. For example, the editOwn method accepts a user-supplied user ID without verifying that it belongs to the caller, allowing an attacker to modify another user's account and set a new password, resulting in account takeover. This vulnerability is distinct from CVE-2026-59712 and CVE-2026-15509 because the root cause is the lack of centralized authorization enforcement in the JSON-RPC dispatcher rather than the behavior of an individual exposed method. |
| Incorrect authorization in CustomTabs in Google Chrome on on Android prior to 152.0.7977.65 allowed a local attacker to bypass web origin policy via a co-installed app. (Chromium security severity: Low) |
| Missing authorization in DevTools in Google Chrome prior to 152.0.7977.65 allowed a remote attacker leveraging social engineering to obtain sensitive information via UI Interaction. (Chromium security severity: Medium) |
| Incorrect authorization in DOM in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to potentially leak sensitive information via a crafted HTML page. (Chromium security severity: Low) |
| Incorrect authorization in StorageAccessAPI in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) |
| Incorrect authorization in Select in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) |
| Missing authorization in Core in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to potentially spoof address bar via a crafted HTML page. (Chromium security severity: Low) |
| The CMP WordPress plugin before 4.1.18 does not perform authorization checks on one of its AJAX actions and relies on a nonce that is skipped for certain (and exposed to anonymous visitors on others), allowing unauthenticated attackers to disable the site's maintenance/coming-soon mode under a non-default countdown configuration. |
| Incorrect authorization in DOM in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium) |
| SeaweedFS is a distributed storage system for files and blobs. In versions 4.39 and earlier, the S3 API accepts an external OIDC JWT sent directly in the Authorization header and maps it to an IAM role without enforcing that role's trust policy, so a federated user can assume a role they are not permitted to hold. The standard STS AssumeRoleWithWebIdentity path rejects such a token when the role's trust policy does not trust the token's federated provider, but the direct S3 bearer path validates only the token itself and then authenticates as the mapped role and evaluates that role's attached S3 permissions. As a result, a valid OIDC user whose token would be denied the role through STS can obtain the role's S3 access, including object read, write, and delete, by presenting the raw OIDC JWT directly to the S3 API. This issue is fixed in version 4.40 |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "user" Splunk role could craft a Dashboard Studio dashboard that runs attacker-controlled Search Processing Language (SPL) for another authenticated user. The attacker-controlled SPL could access all relevant data and affect system integrity and availability. The vulnerability is possible because Dashboard Studio does not consistently enforce the expected app-visibility authorization boundary before dashboard search query options reach search dispatch. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "user" Splunk role should not be able to exploit the vulnerability at will. For more information see Create search-based visualizations with ds.search (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/dashboard-studio/10.4/use-data-sources/create-search-based-visualizations-with-ds.search) in the Splunk documentation. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a low-privileged user that does not hold the fsh_manage capability could perform Remote Code Execution through Federated Search bundle selection. This could allow for access to all relevant data and affect system integrity and availability. The vulnerability is possible because the Federated Search dispatch flow accepts caller-controlled bundle selection without enforcing the capability that manages federated providers and indexes. For more information see Security models for Federated Search for Splunk (https://help.splunk.com/en/splunk-enterprise/search/federated-search/10.4/run-federated-searches-across-other-splunk-deployments/service-accounts-and-security-for-federated-search-for-splunk/security-models-for-federated-search-for-splunk) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. |
| In Splunk Enterprise versions below 10.4.1, 10.2.6, 10.0.8, and 9.4.13, a user who does not hold the "admin" or "power" Splunk roles could trick another user into running arbitrary Search Processing Language (SPL) commands through the Data Model Editor using the permissions of the affected user. The commands could access all relevant data available to the affected user and affect system integrity. The vulnerability is possible because Splunk Web does not apply SPL safeguards for risky commands when the Data Model Editor runs the base search for auto-extracted fields. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who does not hold the "admin" or "power" Splunk roles should not be able to exploit the vulnerability at will. For more information see SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. |
| TypeBot is a chatbot builder tool. Prior to 3.18.0, any authenticated non-guest workspace member can remove another workspace's public custom domain and make typebots on that domain unavailable. The custom-domain delete handler in handleDeleteCustomDomain.ts authorizes a caller against a client-supplied workspaceId but sends the client-supplied domain name to the shared Vercel project before verifying that the domain belongs to that workspace. This issue is fixed in version 3.18.0. |
| Missing authorization in BrowserTag in Google Chrome prior to 152.0.7977.65 allowed a remote attacker leveraging social engineering to obtain sensitive information via a crafted Chrome extension. (Chromium security severity: Low) |
| Incorrect authorization in WebProtect in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to leak sensitive information via a crafted HTML page. (Chromium security severity: Medium) |
