An issue was discovered in GitLab Community Edition (CE) and Enterprise Edition (EE) 10.8 through 12.6.1. It has Incorrect Access Control.

GitLab Enterprise Edition (EE) 11.3 and later through 12.5 allows an Insecure Direct Object Reference (IDOR).

GitLab EE/CE 9.0 to 12.9 allows a maintainer to modify other maintainers' pipeline trigger descriptions within the same project.

An issue has been discovered in GitLab affecting all versions starting from 15.2 before 16.1.5, all versions starting from 16.2 before 16.2.5, all versions starting from 16.3 before 16.3.1. A namespace-level banned user can access the API.

An issue was discovered in GitLab Community and Enterprise Edition 11.6 through 12.4 in the add comments via email feature. It has Insecure Permissions.

An input validation problem was discovered in the GitHub service integration which could result in an attacker being able to make arbitrary POST requests in a GitLab instance's internal network. This vulnerability was addressed in 12.1.2, 12.0.4, and 11.11.6.

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.

An issue has been discovered in GitLab CE/EE affecting all versions before 15.7.8, all versions starting from 15.8 before 15.8.4, all versions starting from 15.9 before 15.9.2. A malicious project Maintainer may create a Project Access Token with Owner level privileges using a crafted request.

An issue was discovered in GitLab Community and Enterprise Edition 11.9 and later through 12.0.2. GitLab Snippets were vulnerable to an authorization issue that allowed unauthorized users to add comments to a private snippet. It allows authentication bypass.

An issue was discovered in GitLab EE affecting all versions from 16.5 prior to 17.7.7, 17.8 prior to 17.8.5, and 17.9 prior to 17.9.2 which allowed a user with a custom permission to approve pending membership requests beyond the maximum number of allowed users.

An issue was discovered in GitLab CE/EE affecting all versions starting from 17.0 prior to 17.0.4 and from 17.1 prior to 17.1.2 where a Guest user with `admin_push_rules` permission may have been able to create project-level deploy tokens.

An issue was discovered in GitLab CE/EE affecting all versions starting from 17.0 prior to 17.0.4 and from 17.1 prior to 17.1.2 where a Developer user with `admin_compliance_framework` custom role may have been able to modify the URL for a group namespace.

GitLab Enterprise Edition (EE) 8.2 and later through 12.5 has Insecure Permissions.

The groups API in GitLab 6.x and 7.x before 7.4.3 allows remote authenticated guest users to modify ownership of arbitrary groups by leveraging improper permission checks.

GitLab CE/EE, versions 10.1 up to 11.x before 11.3.11, 11.4 before 11.4.8, and 11.5 before 11.5.1, are vulnerable to an insecure direct object reference issue that allows a user to make comments on a locked issue.

For GitLab before 13.0.12, 13.1.6, 13.2.3 after a group transfer occurs, members from a parent group keep their access level on the subgroup leading to improper access.

A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. A user without 2 factor authentication enabled could be prohibited from accessing GitLab by being invited into a project that had 2 factor authentication inheritance.

Improper access control in GitLab CE/EE version 10.5 and above allowed subgroup members with inherited access to a project from a parent group to still have access even after the subgroup is transferred

An issue was discovered in GitLab Community and Enterprise Edition 11.8 through 12.4 when handling Security tokens.. It has Insecure Permissions.

GitLab 12.7 through 12.8.1 has Insecure Permissions. Under certain conditions involving groups, project authorization changes were not being applied.

An issue was discovered in GitLab Community and Enterprise Edition before 11.5.8, 11.6.x before 11.6.6, and 11.7.x before 11.7.1. It has Incorrect Access Control (issue 3 of 3). When a project with visibility more permissive than the target group is imported, it will retain its prior visibility.

In Gogs 0.11.91, MakeEmailPrimary in models/user_mail.go lacks a "not the owner of the email" check.

Pimcore is an open source digital experience platform. In Pimcore before version 6.8.5 it is possible to modify & create website settings without having the appropriate permissions.

Improper permissions preservation in Nextcloud Server 16.0.1 causes sharees to be able to reshare with write permissions when sharing the mount point of a share they received, as a public link.

BigBlueButton is an open source web conferencing system. Versions prior to 2.4.3 contain a whiteboard grace period that exists to handle delayed messages, but this grace period could be used by attackers to take actions in the few seconds after their access is revoked. The attacker must be a meeting participant. This issue is patched in version 2.4.3 an version 2.5-alpha-1

Wagtail is an open source content management system built on Django. In affected versions if a model has been made available for editing through the `wagtail.contrib.settings` module or `ModelViewSet`, and the `permission` argument on `FieldPanel` has been used to further restrict access to one or more fields of the model, a user with edit permission over the model but not the specific field can craft an HTTP POST request that bypasses the permission check on the individual field, allowing them to update its value. This vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin, or by a user who has not been granted edit access to the model in question. The editing interfaces for pages and snippets are also unaffected. Patched versions have been released as Wagtail 6.0.3 and 6.1. Wagtail releases prior to 6.0 are unaffected. Users are advised to upgrade. Site owners who are unable to upgrade to a patched version can avoid the vulnerability as follows: 1.For models registered through `ModelViewSet`, register the model as a snippet instead; 2. For settings models, place the restricted fields in a separate settings model, and configure permission at the model level.