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.

cachestat: fix page cache statistics permission checking

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).

Improper Access Control in Mattermost Channel Member API

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.

Privilege Escalation in lunary-ai/lunary

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.

IDOR in open-webui/open-webui

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.

Improper Access Control in lunary-ai/lunary

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.

Improper Access Control in lunary-ai/lunary

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.

Improper Access Control in lunary-ai/lunary

An improper access control vulnerability exists in lunary-ai/lunary versions up to and including 1.2.2, where an admin can update any organization user to the organization owner. This vulnerability allows the elevated user to delete projects within the organization. The issue is resolved in version 1.2.7.

Improper Access Control in gaizhenbiao/chuanhuchatgpt

In gaizhenbiao/chuanhuchatgpt, specifically the version tagged as 20240121, there exists a vulnerability due to improper access control mechanisms. This flaw allows an authenticated attacker to bypass intended access restrictions and read the `history` files of other users, potentially leading to unauthorized access to sensitive information. The vulnerability is present in the application's handling of access control for the `history` path, where no adequate mechanism is in place to prevent an authenticated user from accessing another user's chat history files. This issue poses a significant risk as it could allow attackers to obtain sensitive information from the chat history of other users.

Improper Role Modification by Admins for Billing Permissions in lunary-ai/lunary

In version 1.5.5 of lunary-ai/lunary, a vulnerability exists where admins, who do not have direct permissions to access billing resources, can change the permissions of existing users to include billing permissions. This can lead to a privilege escalation scenario where an administrator can manage billing, effectively bypassing the intended role-based access control. Only users with the 'owner' role should be allowed to invite members with billing permissions. This flaw allows admins to circumvent those restrictions, gaining unauthorized access and control over billing information, posing a risk to the organization’s financial resources.

Improper Privilege Management in lunary-ai/lunary

In lunary-ai/lunary v1.5.0, improper privilege management in the models.ts file allows users with viewer roles to modify models owned by others. The PATCH endpoint for models does not have appropriate privilege checks, enabling low-privilege users to update models they should not have access to modify. This vulnerability could lead to unauthorized changes in critical resources, affecting the integrity and reliability of the system.

Improper access control vulnerability in Bookgy

Bookgy does not provide for proper authorisation control in multiple areas of the application. This deficiency could allow a malicious actor, without authentication, to reach private areas and/or areas intended for other roles.

data.all admin user may access potentially sensitive data stored by producers via logs

A data.all admin team member who has access to the customer-owned AWS Account where data.all is deployed may be able to extract user data from data.all application logs in data.all via CloudWatch log scanning for particular operations that interact with customer producer teams data.

data.all authenticated users can perform restricted operations against DataSets and Environments

Due to inconsistent authorization permissions, data.all may allow an external actor with an authenticated account to perform restricted operations against DataSets and Environments.

data.all authenticated users can perform mutating update operations on persisted notification records

An authenticated data.all user is able to perform mutating UPDATE operations on persisted Notification records in data.all for group notifications that their user is not a member of.

jenkins-plugin/git-server: missing permission check in Git server Plugin

Jenkins Git server Plugin 114.v068a_c7cc2574 and earlier does not perform a permission check for read access to a Git repository over SSH, allowing attackers with a previously configured SSH public key but lacking Overall/Read permission to access these repositories.

A vulnerability has been identified in Siveillance Control (All versions >= V2.8 < V3.1.1). The affected product does not properly check the list of access groups that are assigned to an individual user. This could enable a locally logged on user to gain write privileges for objects where they only have read privileges.

Incorrect authorization for CLI in Guardian/CMC before 25.2.0

An access control vulnerability was discovered in the CLI functionality due to a specific access restriction not being properly enforced for users with limited privileges. An authenticated user with limited privileges can issue administrative CLI commands, altering the device configuration, and/or affecting its availability.

JhumanJ OpnForm integrations authorization

A vulnerability was found in JhumanJ OpnForm up to 1.9.3. This issue affects some unknown processing of the file /show/integrations. Performing manipulation results in missing authorization. Remote exploitation of the attack is possible. The exploit has been made public and could be used. The patch is named 11d97d78f2de2cb49f79baed6bde8b611ec1f384. It is recommended to apply a patch to fix this issue.