| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In OpenStack Aodh before 22.0.1, the alarm list API bypasses project scoping when the all_projects query parameter is set to false. The API checks for the presence of the all_projects key rather than its value; a true value enforces the administrator-only policy, but a false value removes the key and skips the branch that normally restricts results to the caller's project. A non-admin user with the reader role can list alarms from all projects, exposing alarm actions containing trust webhook URLs, Heat signal endpoints, project IDs, and user IDs. The parameter can also be combined with a foreign project_id to target a specific project's alarms. A related concern is that OpenStack Watcher does not apply authorization to its webhook trigger endpoint. Any authenticated user who learns an audit's webhook URL, for example from this leaked Aodh alarm metadata, can start an EVENT audit and its associated action plan regardless of their own project or role. The webhook endpoint has lacked policy enforcement since its introduction in the Ussuri release (Watcher 4.0.0). |
| Incorrect authorization in Workers in Google Chrome prior to 151.0.7922.173 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: High) |
| Incorrect authorization in Azure Arc allows an unauthorized attacker to elevate privileges over a network. |
| Windmill is an open-source developer platform for internal code: APIs, background jobs, workflows and UIs. Prior to 1.715.0, a resource-scoped API token could read script contents outside its allowed path scope through GET /api/w/{workspace}/scripts/list_search. The route-level scope middleware validated the token domain and action but did not enforce the resource/path segment, and the list_search_scripts handler had no additional check_scopes call or per-row filtering before returning script path and content fields. A token such as scripts:read:f/allowed/* could therefore receive source code for unrelated paths in the same workspace, potentially disclosing internal automation logic, integration details, business logic, inline configuration, or hardcoded secrets and credentials. Exploitation required possession of a valid scoped API token for the workspace but did not require administrator privileges. This issue is fixed in version 1.715.0. |
| A flaw was found in FreeIPA. The trust-fetch-domains command is gated by a read-only permission on the trust object rather than a trust-administration permission, allowing an authenticated, non-privileged IPA user to trigger a privileged Active Directory trust refresh using an attacker-supplied server and credentials, resulting in unauthorized, attacker-controlled modification of trusted-domain and ID-range identity data in the IPA LDAP directory. |
| IBM Power Systems Firmware FW1120.00, FW1110.00 through FW1110.30, and FW1060.00 through FW1060.80 is affected by a vulnerability in the interface between the BMC/FSP and the host system. An attacker with service account or root access to the BMC/FSP can access and disrupt host processor state, potentially affecting the managed system and all hosted partitions, resulting in an confidentiality, and availability impact. |
| Dell Command Update (DCU), versions prior to 5.7.1, contain an Incorrect Authorization vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of privileges. |
| is affected by an Incorrect Authorization vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain limited unauthorized read and write access, causing a limited disruption to availability. Exploitation of this issue does not require user interaction. |
| is affected by an Incorrect Authorization vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized read and write access, potentially resulting in an application denial-of-service condition. The vulnerable component is restricted to an administrative network zone by default. Exploitation of this issue does not require user interaction. Scope is changed. |
| ColdFusion is affected by an Incorrect Authorization vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. The vulnerable component is restricted to an administrative network zone by default. Exploitation of this issue does not require user interaction. |
| Incorrect authorization in frozen BI aggregations in Checkmk <2.5.0p2, <2.4.0p29, <2.3.0p47, and all 2.2.0 versions allows an authenticated user with restricted host and service visibility to learn the names and the existence of hosts and services they are not authorized to see. |
| The GutenKit WordPress plugin before 2.5.0 does not have a sufficient capability check on some of its REST API endpoints, allowing users with the Contributor role and above to retrieve mailing-list audience metadata from the site's connected marketing account. |
| stigmem versions before 0.9.0a12 contain a broken object level authorization vulnerability in the decay sweep endpoint that allows authenticated attackers with write credentials for one tenant to execute decay operations affecting all tenants. Attackers can submit POST requests to the decay sweep endpoint with ttl_seconds=0 to expire facts across all tenants, or use dry_run to obtain cross-tenant fact counts and existence information. |
| Flow-Like is a platform for building end-to-end use cases. Prior to version 1.0.4, `GET /api/v1/apps/{app_id}/invoke/presign` grants Azure Blob Storage SAS credentials with write and delete access to app content to any app member that has `ExecuteEvents`, even when that member lacks `ReadFiles` and `WriteFiles`. The route treats file permissions as optional after the `ExecuteEvents` gate. When the caller has neither file permission, it selects `CredentialsAccess::InvokeNone`. In the Azure credential provider, `InvokeNone` still mints a `content_sas_token` for `apps/{app_id}` with `sp=rwdl`, plus user-content and log SAS tokens. The returned shared credential is enough for the low-privilege caller to directly write or delete blobs under the app content prefix. Version 1.0.4 patches the issue. Flow-Like Studio and the hosted Flow-Like Web App are not affected. These deployments use AWS-backed storage. Self-hosted deployments are only affected if they use Azure Blob Storage as the storage backend. In affected deployments, the issue only applies to authenticated app members who have workflow execution permissions but should not have app file write/delete permissions. Users of affected self-hosted Azure deployments should update to version 1.0.4 or the latest dev branch. |
| A low privileged remote attacker with a valid session can submit a request to the user creation functionality exposed through /api/user/add.php to create new accounts with arbitrary role values, including the highest privilege level used by the application. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store risky Search Processing Language (SPL) commands in a Table Editor dataset and share the dataset. A user who holds the "admin" Splunk role triggers the commands when that user opens the dataset in the Table Editor. The commands run using the permissions of the second user and could expose all relevant data and modify lookup files. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands to the field-summary search that it runs for the Initial Data step. 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 "power" Splunk role 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.2/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. |
| In Splunk AI Toolkit versions below 6.0.0, a user who does not hold the "admin" or "power" Splunk roles could run searches with system-level privileges, access all relevant data, affect system integrity, and read or delete search jobs belonging to other users through Agent Run History. The improper privilege management is possible because the Agent Run History handler replaces the calling user session key with a system authentication token before it performs search operations. For more information see AI Toolkit Agent Launchpad (https://help.splunk.com/en/splunk-enterprise/apply-machine-learning/use-ai-toolkit/6.0.0/ai-toolkit-connections-containers-and-agents/ai-toolkit-agent-launchpad) in the Splunk documentation. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store attacker-controlled Search Processing Language (SPL) in a Table Editor dataset and share the dataset. A user who holds the "admin" Splunk role triggers the SPL when that user opens the dataset in the Table Editor. The SPL runs using the permissions of the second user and could expose all relevant data and modify limited data on the search head. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands when it prepares the dataset initial data. 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 "power" Splunk role should not be able to exploit the vulnerability at will. For more information see Define initial data for a new table dataset (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/9.4/create-and-edit-table-datasets/define-initial-data-for-a-new-table-dataset), SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/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.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. |
| Lemmy is a link aggregator and forum for the fediverse. From 0.19.18 until 0.19.19 and 1.0.0-alpha.20, a community moderator can feature or unfeature posts in other communities through federated CollectionAdd and CollectionRemove activities using CollectionType::Featured. After verify_mod_action authorizes the actor against self.community(), the receive handlers in crates/apub/activities/src/community/collection_add.rs and crates/apub/activities/src/community/collection_remove.rs dereference self.object as an ApubPost and update featured_community without verifying that post.community_id equals community.id. A moderator can therefore target an unrelated post owned by another community, push it into featured feeds and listings, or undo another community's legitimate curation decision. This issue is fixed in versions 0.19.19 and 1.0.0-alpha.20. |
| Wekan is open source kanban built with Meteor. Prior to 9.89, the second Boards.allow({ update }) rule in server/permissions/boards.js called canUpdateBoardSort in server/lib/utils.js, which authorized any board member whenever fieldNames included sort. Because Meteor combines allow rules with OR semantics and applies the complete modifier, a comment-only or read-only member could send one Boards.update with $set values for sort, members, permission, and title, make themselves the sole board administrator, expose a private board, and evict the legitimate owner; the last-admin deny rule inspected only $pull and did not block a wholesale $set of members. Version 9.89 requires sort to be the only modified field and rejects $set member arrays that remove the last active administrator. This issue is fixed in version 9.89. |
