phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. phpMyFAQ's user removal page allows an attacker to spoof another user's detail, and in turn make a compelling phishing case for removing another user's account. The front-end of this page doesn't allow changing the form details, an attacker can utilize a proxy to intercept this request and submit other data. Upon submitting this form, an email is sent to the administrator informing them that this user wants to delete their account. An administrator has no way of telling the difference between the actual user wishing to delete their account or the attacker issuing this for an account they do not control. This issue has been patched in version 3.2.5.

DHIS2 Core contains the service layer and Web API for DHIS2, an information system for data capture. Starting in the 2.36 branch and prior to versions 2.37.9.1, 2.38.3.1, and 2.39.1.2, using object model traversal in the payload of a PATCH request, authenticated users with write access to an object may be able to modify related objects that they should not have access to. DHIS2 implementers should upgrade to a supported version of DHIS2 to receive a patch: 2.37.9.1, 2.38.3.1, or 2.39.1.2. It is possible to work around this issue by blocking all PATCH requests on a reverse proxy, but this may cause some issues with the functionality of built-in applications using legacy PATCH requests.

Improper access control in message routing in Odoo Community 12.0 and earlier and Odoo Enterprise 12.0 and earlier allows remote authenticated users to create arbitrary records via crafted payloads, which may allow privilege escalation.

CWE-284: Improper Access Control

An authorization issue was discovered in GitLab EE < 12.1.2, < 12.0.4, and < 11.11.6 allowing the merge request approval rules to be overridden without appropriate permissions.

Dify is an open-source LLM app development platform. Prior to version 0.6.12, a vulnerability was identified in the DIFY where normal users are improperly granted permissions to edit APP names, descriptions and icons. This access control flaw allows non-admin users to modify app details, despite being restricted from viewing apps, which poses a security risk to the integrity of the application. This issue has been patched in version 0.6.12. A workaround for this vulnerability involves updating the access control mechanisms to enforce stricter user role permissions and implementing role-based access controls (RBAC) to ensure that only users with admin privileges can modify app details.

an Improper Access Control vulnerability has been found in EmbedAI 2.1 and below. This vulnerability allows an authenticated attacker change his subscription plan without paying by making a POST request changing the parameters of the "/demos/embedai/pmt_cash_on_delivery/pay" endpoint.

A vulnerability in the lobby ambassador web interface of Cisco IOS XE Wireless Controller Software could allow an authenticated, remote attacker to remove arbitrary users that are defined on an affected device. This vulnerability is due to insufficient access control of actions executed by lobby ambassador users. An attacker could exploit this vulnerability by logging in to an affected device with a lobby ambassador user account and sending crafted HTTP requests to the API. A successful exploit could allow the attacker to delete arbitrary user accounts on the device, including users with administrative privileges. Note: This vulnerability is exploitable only if the attacker obtains the credentials for a lobby ambassador account. This account is not configured by default.

In Splunk Enterprise versions below 9.4.1, 9.3.3, 9.2.5, and 9.1.8, and versions below 3.8.38 and 3.7.23 of the Splunk Secure Gateway app on Splunk Cloud Platform, a low-privileged user that does not hold the “admin“ or “power“ Splunk roles could edit and delete other user data in App Key Value Store (KVStore) collections that the Splunk Secure Gateway app created. This is due to missing access control and incorrect ownership of the data in those KVStore collections.<br><br>In the affected versions, the `nobody` user owned the data in the KVStore collections. This meant that there was no specific owner assigned to the data in those collections.