| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A flaw was found in Keycloak. An authenticated user with existing organization membership can exploit this flaw by accessing user-facing APIs, such as the account API or by requesting an OpenID Connect (OIDC) token with the 'organization' scope. This allows organization metadata to be disclosed in tokens, even after an administrator has explicitly disabled the Organizations feature, potentially leading to incorrect authorization decisions by resource servers. |
| Frappe HR is an open-source human resources management solution (HRMS). Prior to 16.5.0, authenticated employees could access other employees’ leave details due to improper authorization checks. This vulnerability is fixed in 16.5.0. |
| Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.6.12 and 1.7.1, an unauthenticated open redirect in Authlib's OpenIDImplicitGrant and OpenIDHybridGrant authorization endpoint lets a remote attacker cause the authorization server to issue an HTTP 302 to an attacker-chosen URL by submitting an authorization request that omits the openid scope. This vulnerability is fixed in 1.6.12 and 1.7.1. |
| Budibase is an open-source low-code platform. Prior to 3.39.0, the single-datasource GET and PUT routes are guarded by generic TABLE READ, not by Builder/Admin permission or datasource-specific ownership/resource checks. The built-in Basic app user role maps to the WRITE permission set, which includes table read/write and query write. A Basic user can therefore read an existing REST datasource, receive redacted authConfigs values, submit an update that changes only config.url while keeping the redacted placeholders, and trigger an existing saved relative-path REST query. During update, mergeConfigs() restores the old stored secret when it sees the redaction placeholder. During query execution, Budibase prefixes the attacker-controlled datasource config.url to the relative query path and applies the resolved stored auth headers. The result is server-side disclosure of the builder-configured REST Authorization secret to an attacker-controlled listener. This vulnerability is fixed in 3.39.0. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.2 before 18.10.7, 18.11 before 18.11.4, and 19.0 before 19.0.1 that under certain conditions could have allowed an unauthorized user to enumerate private projects due to incorrect authorization checks. |
| Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.83.39, a missing authorization directive on the GET /api/v1/stable/dags/tasks endpoint caused Hatchet's tenant-membership check to be skipped for this route. A user authenticated to any tenant on the same Hatchet instance could query the endpoint with another tenant's UUID and a DAG UUID belonging to that tenant, and receive task metadata for that DAG. This vulnerability is fixed in 0.83.39. |
| Due to a lack of user account state validation during authentication, locked user accounts can be successfully authenticated using Magic Link or Pass Key methods. This bypasses the intended security control that should prevent access to accounts that have been locked.
This vulnerability may allow unauthorized access to applications and sensitive data associated with accounts that should have been restricted via the account lock mechanism. It also undermines the effectiveness of the account lock mechanism intended to prevent further login attempts. |
| Due to not validating the organization context when executing adaptive authentication flows, the WSO2 Identity Server allows adaptive authentication logic to be triggered on unintended organizations. A malicious actor with privileges to configure adaptive authentication within one organization can leverage this functionality to execute authentication logic on other organizations and sub-organizations.
This flaw allows bypassing authorization boundaries between organizations, leading to unauthorized access to critical operations and user accounts in other organizations. When adaptive authentication is enabled in a multi-organization deployment, a malicious actor with privileges to configure adaptive authentication in one organization could exploit this feature to perform critical operations in other organizations without authorization. This may result in privilege escalation, unauthorized access to resources, and potential account takeover across organizations. |
| Grav API Plugin is a RESTful API for Grav CMS that provides full headless access to your site's content, media, configuration, users, and system management. Prior to 1.0.0-beta.15, an insecure direct object reference and logic flaw in the Grav API plugin (UsersController::update) allows any authenticated user with basic API access (api.access) to modify their own permission configuration. An attacker can exploit this to escalate their privileges to Super Administrator (admin.super and api.super), leading to full system compromise and potential RCE. This vulnerability is fixed in 1.0.0-beta.15. |
| Snipe-IT is an IT asset/license management system. Prior to 8.4.1, aAn authenticated user with only users.edit permission can escalate their own privileges to admin by sending a PATCH request to /api/v1/users/{id} with permissions[admin]=1. The API controller only strips the superuser key from the permissions array, allowing admin and all other permission keys to be set by any user who can update users. This vulnerability is fixed in 8.4.1. |
| Traccar is an open source GPS tracking system. Prior to 6.13.0, DeviceResource.uploadImage authorizes the target device only through Condition.Permission(User.class, getUserId(), Device.class) and then immediately streams the uploaded body into mediaManager.createFileStream(...). Unlike the generic mutation path in BaseObjectResource.update and the explicit device mutation handler updateAccumulators, this route never invokes permissionsService.checkEdit(getUserId(), Device.class, false, false). The skipped guard is exactly where Traccar enforces readonly and deviceReadonly restrictions for non-admin users. An unauthorized user can replace a device’s stored image file under the server media directory. This allows modification of UI-visible device media and any downstream workflows that rely on the persisted image, despite other device update paths correctly rejecting the same identity. This vulnerability is fixed in 6.13.0. |
| A security vulnerability has been detected in SourceCodester eDoc Doctor Appointment System 1.0. This affects an unknown part of the file /admin/delete-session.php. The manipulation of the argument ID leads to missing authorization. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used. |
| authentik is an open-source identity provider. In versions prior to 2025.12.5 and 2026.2.0-rc1 through 2026.2.2, authenticated non-admin users with at least one OAuth2 access token can retrieve the client_secret of confidential OAuth2 providers they have previously authenticated against, exposing sensitive information to users without the correct permissions. This logic is GET /api/v3/oauth2/access_tokens/. The API response includes a nested provider object containing client_id and client_secret for providers configured with client_type: confidential, which should not be accessible to low-privilege users. This issue has been fixed in versions 2025.12.5 and 2026.2.3. |
| Redaxo CMS Mediapool Addon 5.5.1 and older contains an arbitrary file upload vulnerability that allows authenticated users to bypass file extension blacklist restrictions. Attackers with editor accounts can upload executable files by using obfuscated extensions like php71 or php53 to evade the blacklist filter and execute arbitrary code. |
| A vulnerability was identified in NousResearch hermes-agent up to 2026.4.16. This affects the function check_all_command_guards of the file tools/approval.py of the component Batch Runner. Such manipulation leads to missing authorization. The attack can be launched remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| Concrete CMS 9.5.0 and below is vulnerable to missing authorization in the bulk_user_assignment.php which can lead to privilege escalation to Administrative Group. Any authenticated user with access to the bulk user assignment dashboard page can add any user email to any group and can remove legitimate admins. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.5 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks Vincent55 for reporting. |
| In Splunk AI Toolkit versions below 5.7.3, a low-privileged user that does not hold the 'admin' or 'power' roles could access confidential data that was restricted through `srchFilter` configurations on custom roles.<br><br>The app contains an `authorize.conf` configuration file with a `srchFilter` entry that modifies the built-in ‘user’ role. Because the Splunk platform combines inherited search filters with the `OR` SPL operator, the injected filter overrides more restrictive filters on child roles. |
| OpenClaw before 2026.4.8 contains a privilege escalation vulnerability allowing previously paired nodes to reconnect with exec-capable commands without the operator.admin scope requirement. Attackers can bypass re-pairing authentication to execute privileged commands on the local assistant system. |
| OpenClaw before 2026.4.8 contains a privilege escalation vulnerability in the gateway plugin HTTP authentication mechanism that escalates identity-bearing operator.read requests to runtime operator.write permissions. Attackers can exploit this by sending read-scoped requests through the gateway auth route to gain unauthorized write access to runtime operations. |
| OpenClaw versions prior to 2026.2.26 contain an authorization bypass vulnerability in the pairing-store access control for direct message pairing policy that allows attackers to reuse pairing approvals across multiple accounts. An attacker approved as a sender in one account can be automatically accepted in another account in multi-account deployments without explicit approval, bypassing authorization boundaries. |
