| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An issue was discovered on certain GL-iNet devices, including MT6000, MT3000, MT2500, AXT1800, and AX1800 4.6.2. Users who belong to unauthorized groups can invoke any interface of the device, thereby gaining complete control over it. |
| An issue was discovered on certain GL-iNet devices, including MT6000, MT3000, MT2500, AXT1800, and AX1800 4.6.2. The SID generated for a specific user is not tied to that user itself, which allows other users to potentially use it for authentication. Once an attacker bypasses the application's authentication procedures, they can generate a valid SID, escalate privileges, and gain full control. |
| In the Linux kernel, the following vulnerability has been resolved:
cachestat: fix page cache statistics permission checking
When the 'cachestat()' system call was added in commit cf264e1329fb
("cachestat: implement cachestat syscall"), it was meant to be a much
more convenient (and performant) version of mincore() that didn't need
mapping things into the user virtual address space in order to work.
But it ended up missing the "check for writability or ownership" fix for
mincore(), done in commit 134fca9063ad ("mm/mincore.c: make mincore()
more conservative").
This just adds equivalent logic to 'cachestat()', modified for the file
context (rather than vma). |
| Mattermost versions 10.7.x <= 10.7.0, 10.5.x <= 10.5.3, 9.11.x <= 9.11.12 fail to properly enforce access controls for guest users accessing channel member information, allowing authenticated guest users to view metadata about members of public channels via the channel members API endpoint. |
| A vulnerability has been found in zhenfeng13 My-BBS 1.0 and classified as problematic. This vulnerability affects unknown code. The manipulation leads to cross-site request forgery. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. Multiple endpoints might be affected. |
| In lunary-ai/lunary before version 1.4.30, a privilege escalation vulnerability exists where admins can invite new members with billing permissions, thereby gaining unauthorized access to billing resources. This issue arises because the user creation endpoint does not restrict admins from inviting users with billing roles. As a result, admins can circumvent the intended access control, posing a risk to the organization's financial resources. |
| In lunary-ai/lunary version 1.4.28, the /checklists/:id route allows low-privilege users to modify checklists by sending a PATCH request. The route lacks proper access control, such as middleware to ensure that only authorized users (e.g., project owners or admins) can modify checklist data. This vulnerability allows any user associated with the project, regardless of their role, to modify checklists, including changing the slug or data fields, which can lead to tampering with essential project workflows, altering business logic, and introducing errors that undermine integrity. |
| In lunary-ai/lunary version v1.4.28, the /bigquery API route lacks proper access control, allowing any logged-in user to create a Datastream to Google BigQuery and export the entire database. This includes sensitive data such as password hashes and secret API keys. The route is protected by a config check (`config.DATA_WAREHOUSE_EXPORTS_ALLOWED`), but it does not verify the user's access level or implement any access control middleware. This vulnerability can lead to the extraction of sensitive data, disruption of services, credential compromise, and service integrity breaches. |
| In lunary-ai/lunary before version 1.4.26, the checklists.post() endpoint allows users to create or modify checklists without validating whether the user has proper permissions. This missing access control permits unauthorized users to create checklists, bypassing intended permission checks. Additionally, the endpoint does not validate the uniqueness of the slug field when creating a new checklist, allowing an attacker to spoof existing checklists by reusing the slug of an already-existing checklist. This can lead to significant data integrity issues, as legitimate checklists can be replaced with malicious or altered data. |
| lunary-ai/lunary version v1.4.25 contains an improper access control vulnerability in the POST /api/v1/data-warehouse/bigquery endpoint. This vulnerability allows any user to export the entire database data by creating a stream to Google BigQuery without proper authentication or authorization. The issue is fixed in version 1.4.26. |
| An improper access control vulnerability exists in danswer-ai/danswer version v0.3.94. This vulnerability allows the first user created in the system to view, modify, and delete chats created by an Admin. This can lead to unauthorized access to sensitive information, loss of data integrity, and potential compliance violations. |
| In version v0.3.8 of open-webui, an improper privilege management vulnerability exists in the API endpoints GET /api/v1/documents/ and POST /rag/api/v1/doc. This vulnerability allows a lower-privileged user to access and overwrite files managed by a higher-privileged admin. By exploiting this vulnerability, an attacker can view metadata of files uploaded by an admin and overwrite these files, compromising the integrity and availability of the RAG models. |
| An improper access control vulnerability in open-webui/open-webui v0.3.8 allows an attacker to view admin details. The application does not verify whether the attacker is an administrator, allowing the attacker to directly call the /api/v1/auths/admin/details interface to retrieve the first admin (owner) details. |
| In version v0.3.8 of open-webui/open-webui, improper access control vulnerabilities allow an attacker to view any prompts. The application does not verify whether the attacker is an administrator, allowing the attacker to directly call the /api/v1/prompts/ interface to retrieve all prompt information created by the admin, which includes the ID values. Subsequently, the attacker can exploit the /api/v1/prompts/command/{command_id} interface to obtain arbitrary prompt information. |
| An improper access control vulnerability in open-webui/open-webui v0.3.8 allows attackers to view and delete any files. The application does not verify whether the attacker is an administrator, allowing the attacker to directly call the GET /api/v1/files/ interface to retrieve information on all files uploaded by users, which includes the ID values. The attacker can then use the GET /api/v1/files/{file_id} interface to obtain information on any file and the DELETE /api/v1/files/{file_id} interface to delete any file. |
| In open-webui/open-webui version v0.3.8, there is an improper privilege management vulnerability. The application allows an attacker, acting as an admin, to delete other administrators via the API endpoint `http://0.0.0.0:8080/api/v1/users/{uuid_administrator}`. This action is restricted by the user interface but can be performed through direct API calls. |
| In version 1.2.7 of lunary-ai/lunary, any authenticated user, regardless of their role, can change the name of an organization due to improper access control. The function checkAccess() is not implemented, allowing users with the lowest privileges, such as the 'Prompt Editor' role, to modify organization attributes without proper authorization. |
| In lunary-ai/lunary version 1.2.4, an improper access control vulnerability allows members with team management permissions to manipulate project identifiers in requests, enabling them to invite users to projects in other organizations, change members to projects in other organizations with escalated privileges, and change members from other organizations to their own or other projects, also with escalated privileges. This vulnerability is due to the backend's failure to validate project identifiers against the current user's organization ID and projects belonging to it, as well as a misconfiguration in attribute naming (`org_id` should be `orgId`) that prevents proper user organization validation. As a result, attackers can cause inconsistencies on the platform for affected users and organizations, including unauthorized privilege escalation. The issue is present in the backend API endpoints for user invitation and modification, specifically in the handling of project IDs in requests. |
| berriai/litellm version 1.34.34 is vulnerable to improper access control in its team management functionality. This vulnerability allows attackers to perform unauthorized actions such as creating, updating, viewing, deleting, blocking, and unblocking any teams, as well as adding or deleting any member to or from any teams. The vulnerability stems from insufficient access control checks in various team management endpoints, enabling attackers to exploit these functionalities without proper authorization. |
| An Incorrect Authorization vulnerability exists in lunary-ai/lunary versions up to and including 1.2.2, which allows unauthenticated users to delete any dataset. The vulnerability is due to the lack of proper authorization checks in the dataset deletion endpoint. Specifically, the endpoint does not verify if the provided project ID belongs to the current user, thereby allowing any dataset to be deleted without proper authentication. This issue was fixed in version 1.2.8. |
