An issue was discovered in GitLab CE/EE affecting all versions starting from 16.4 prior to 17.5.5, starting from 17.6 prior to 17.6.3, and starting from 17.7 prior to 17.7.1. When a user is created via the SAML provider, the external groups setting overrides the external provider configuration. As a result, the user may not be marked as external thereby giving those users access to internal projects or groups.

An issue has been discovered in GitLab CE/EE affecting all versions from 16.11 before 17.4.5, 17.5 before 17.5.3, and 17.6 before 17.6.1. Long-lived connections could potentially bypass authentication controls, allowing unauthorized access to streaming results.

A business logic error in GitLab EE affecting all versions prior to 16.2.8, 16.3 prior to 16.3.5, and 16.4 prior to 16.4.1 allows access to internal projects. A service account is not deleted when a namespace is deleted, allowing access to internal projects.

An issue has been discovered in GitLab affecting all versions before 16.7.6, all versions starting from 16.8 before 16.8.3, all versions starting from 16.9 before 16.9.1. It was possible for group members with sub-maintainer role to change the title of privately accessible deploy keys associated with projects in the group.

Improper access control in GitLab EE versions 13.11.6, 13.12.6, and 14.0.2 allows users to be created via single sign on despite user cap being enabled

An issue has been discovered in GitLab CE/EE for Self-Managed and Dedicated instances affecting all versions from 17.5 prior to 17.6.5, 17.7 prior to 17.7.4, and 17.8 prior to 17.8.2. It was possible for a user added as an External to read and clone internal projects under certain circumstances."

An issue discovered in GitLab CE/EE affecting all versions from 16.11 prior to 17.6.5, 17.7 prior to 17.7.4, and 17.8 prior to 17.8.2 meant that long-lived connections in ActionCable potentially allowed revoked Personal Access Tokens access to streaming results.

An issue has been discovered in GitLab CE/EE affecting all versions starting from 12.1 before 15.3.5, all versions starting from 15.4 before 15.4.4, all versions starting from 15.5 before 15.5.2. A malicious maintainer could exfiltrate a Datadog integration's access token by modifying the integration URL such that authenticated requests are sent to an attacker controlled server.

An issue was discovered in GitLab CE/EE affecting all versions prior to 16.11.6, starting from 17.0 prior to 17.0.4, and starting from 17.1 prior to 17.1.2, which allows a subdomain takeover in GitLab Pages.

An issue has been discovered in GitLab affecting all versions starting from 10.0 before 15.2.5, all versions starting from 15.3 before 15.3.4, all versions starting from 15.4 before 15.4.1. It was possible for an unauthorised user to create issues in a project.

In all versions of GitLab CE/EE since version 8.0, a DNS rebinding vulnerability exists in Fogbugz importer which may be used by attackers to exploit Server Side Request Forgery attacks.

A business logic error in the project deletion process in GitLab 13.6 and later allows persistent access via project access tokens.

A DNS rebinding vulnerability in the Irker IRC Gateway integration in all versions of GitLab CE/EE since version 7.9 allows an attacker to trigger Server Side Request Forgery (SSRF) attacks.

A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. When 2 factor authentication was enabled for groups, a malicious user could bypass that restriction by sending a specific query to the API endpoint.

In GitLab before 13.0.12, 13.1.6 and 13.2.3, access grants were not revoked when a user revoked access to an application.

A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. In certain cases an invalid username could be accepted when 2FA is activated.

A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. GitLab was not validating a Deploy-Token and allowed a disabled repository be accessible via a git command line.

An issue has been discovered in GitLab EE affecting all versions affecting all versions from 11.11 prior to 16.2.8, 16.3 prior to 16.3.5, and 16.4 prior to 16.4.1. Single Sign On restrictions were not correctly enforced for indirect project members accessing public members-only project repositories.

GitLab Community Edition (CE) and Enterprise Edition (EE) through 12.5 has Incorrect Access Control (issue 2 of 2).

An issue was discovered in GitLab Community and Enterprise Edition 10.8 through 12.2.1. An internal endpoint unintentionally allowed group maintainers to view and edit group runner settings.

An issue has been discovered in GitLab affecting all versions starting from 15.5 before 15.7.8, all versions starting from 15.8 before 15.8.4, all versions starting from 15.9 before 15.9.2. Due to improper permissions checks an unauthorised user was able to read, add or edit a users private snippet.

Improper authorization in GitLab CE/EE affecting all versions since 13.3 allowed users to view and delete impersonation tokens that administrators created for their account

Improper authorization in GitLab CE/EE affecting all versions since 12.6 allowed guest users to create issues for Sentry errors and track their status

For GitLab Runner before 13.0.12, 13.1.6, 13.2.3, by replacing dockerd with a malicious server, the Shared Runner is susceptible to SSRF.

An issue was discovered in GitLab Community and Enterprise Edition before 11.4.13, 11.5.x before 11.5.6, and 11.6.x before 11.6.1. It has Incorrect Access Control.

Insufficient validation of authentication parameters in GitLab Pages for GitLab 11.5+ allows an attacker to steal a victim's API token if they click on a maliciously crafted link

GitLab before 5.4.2, Community Edition before 6.2.4, and Enterprise Edition before 6.2.1, when using a MySQL backend, allows remote attackers to impersonate arbitrary users and bypass authentication via unspecified API calls.

An issue has been discovered in GitLab CE/EE affecting all versions from 16.8 before 17.10.7, 17.11 before 17.11.3, and 18.0 before 18.0.1. Group access controls could allow certain users to bypass two-factor authentication requirements.

An issue has been discovered in GitLab affecting all versions starting from 12.10 before 15.1.6, all versions starting from 15.2 before 15.2.4, all versions starting from 15.3 before 15.3.2. GitLab was not performing correct authentication with some Package Registries when IP address restrictions were configured, allowing an attacker already in possession of a valid Deploy Token to misuse it from any location.

An issue has been discovered in GitLab CE/EE affecting all versions before 15.0.5, all versions starting from 15.1 before 15.1.4, all versions starting from 15.2 before 15.2.1. It may be possible for group members to bypass 2FA enforcement enabled at the group level by using Resource Owner Password Credentials grant to obtain an access token without using 2FA.

It was possible to bypass 2FA for LDAP users and access some specific pages with Basic Authentication in GitLab 14.1.1 and above.

In all versions of GitLab CE/EE since version 14.1, an improper access control vulnerability allows users with expired password to still access GitLab through git and API through access tokens acquired before password expiration.

In GitLab before 13.0.12, 13.1.6, and 13.2.3, improper access control was used on the Applications page

A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. Due to improper verification of permissions, an unauthorized user can access a private repository within a public project.

In GitLab before 13.0.12, 13.1.6 and 13.2.3, it is possible to bypass E-mail verification which is required for OAuth Flow.

An issue has been discovered in GitLab affecting all versions starting from 12.6 before 14.8.6, all versions starting from 14.9 before 14.9.4, all versions starting from 14.10 before 14.10.1. GitLab was not correctly authenticating a user that had some certain amount of information which allowed an user to authenticate without a personal access token.

An authentication issue was discovered in GitLab that allowed a bypass of email verification. This was addressed in GitLab 12.1.2 and 12.0.4.

A authentication bypass vulnerability exists in GitLab CE/EE <v12.3.2, <v12.2.6, and <v12.1.10 in the Salesforce login integration that could be used by an attacker to create an account that bypassed domain restrictions and email verification requirements.

Improper authentication exists in < 12.3.2, < 12.2.6, and < 12.1.12 for GitLab Community Edition (CE) and Enterprise Edition (EE) in the GitLab SAML integration had a validation issue that permitted an attacker to takeover another user's account.

An issue has been discovered in GitLab CE/EE affecting all versions starting from 7.8 before 16.9.6, all versions starting from 16.10 before 16.10.4, all versions starting from 16.11 before 16.11.1. Under certain conditions, an attacker with their Bitbucket account credentials may be able to take over a GitLab account linked to another user's Bitbucket account, if Bitbucket is used as an OAuth 2.0 provider on GitLab.

IBM Manage Application 8.8.0 and 8.9.0 in the IBM Maximo Application Suite is vulnerable to incorrect default permissions which could give access to a user to actions that they should not have access to. IBM X-Force ID: 242953.

Improper authentication in SQL data source MFA validation in Devolutions Remote Desktop Manager 2024.3.17 and earlier on Windows allows an authenticated user to bypass the MFA validation via data source switching.

Improper Authentication vulnerability in Drupal Login Disable allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Login Disable: from 2.0.0 before 2.1.1.

The CTS Web transaction system related to authentication management is implemented incorrectly. After login, remote attackers can manipulate cookies to access other accounts and trade in the stock market with spoofed identity.

TYPO3 is an open source PHP based web content management system released under the GNU GPL. In typo3 installations there are always at least two different sites. Eg. first.example.org and second.example.com. In affected versions a session cookie generated for the first site can be reused on the second site without requiring additional authentication. This vulnerability has been addressed in versions 8.7.55, 9.5.44, 10.4.41, 11.5.33, and 12.4.8. Users are advised to upgrade. There are no known workarounds for this vulnerability.

From version 1.3.0 onward, Apache Spark's standalone master exposes a REST API for job submission, in addition to the submission mechanism used by spark-submit. In standalone, the config property 'spark.authenticate.secret' establishes a shared secret for authenticating requests to submit jobs via spark-submit. However, the REST API does not use this or any other authentication mechanism, and this is not adequately documented. In this case, a user would be able to run a driver program without authenticating, but not launch executors, using the REST API. This REST API is also used by Mesos, when set up to run in cluster mode (i.e., when also running MesosClusterDispatcher), for job submission. Future versions of Spark will improve documentation on these points, and prohibit setting 'spark.authenticate.secret' when running the REST APIs, to make this clear. Future versions will also disable the REST API by default in the standalone master by changing the default value of 'spark.master.rest.enabled' to 'false'.

Zoho ManageEngine ADManager Plus before 7203 allows 2FA bypass (for AuthToken generation) in REST APIs.

Synapse is a Matrix protocol homeserver written in Python with the Twisted framework. In affected versions it may be possible for a deactivated user to login when using uncommon configurations. This only applies if any of the following are true: 1. JSON Web Tokens are enabled for login via the `jwt_config.enabled` configuration setting. 2. The local password database is enabled via the `password_config.enabled` and `password_config.localdb_enabled` configuration settings *and* a user's password is updated via an admin API after a user is deactivated. Note that the local password database is enabled by default, but it is uncommon to set a user's password after they've been deactivated. Installations that are configured to only allow login via Single Sign-On (SSO) via CAS, SAML or OpenID Connect (OIDC); or via an external password provider (e.g. LDAP) are not affected. If not using JSON Web Tokens, ensure that deactivated users do not have a password set. This issue has been addressed in version 1.85.0. Users are advised to upgrade.

A vulnerability in the spam quarantine feature of Cisco Secure Email and Web Manager, formerly Cisco Security Management Appliance (SMA), could allow an authenticated, remote attacker to gain unauthorized access and modify the spam quarantine settings of another user. This vulnerability exists because access to the spam quarantine feature is not properly restricted. An attacker could exploit this vulnerability by sending malicious requests to an affected system. A successful exploit could allow the attacker to modify another user's spam quarantine settings, possibly disabling security controls or viewing email messages stored on the spam quarantine interfaces.

Himmelblau is an interoperability suite for Microsoft Azure Entra ID and Intune. Himmelblau versions 0.9.0 through 0.9.14 and 1.00-alpha are vulnerable to a privilege escalation issue when Entra ID group-based access restrictions are configured using group display names instead of object IDs. Starting in version 0.9.0, Himmelblau introduced support for specifying group names in the `pam_allow_groups` configuration option. However, Microsoft Entra ID permits the creation of multiple groups with the same `displayName` via the Microsoft Graph API—even by non-admin users, depending on tenant settings. As a result, a user could create a personal group with the same name as a legitimate access group (e.g., `"Allow-Linux-Login"`), add themselves to it, and be granted authentication or `sudo` rights by Himmelblau. Because affected Himmelblau versions compare group names by either `displayName` or by the immutable `objectId`, this allows bypassing access control mechanisms intended to restrict login to members of official, centrally-managed groups. This issue is fixed in Himmelblau version **0.9.15** and later. In these versions, group name matching in `pam_allow_groups` has been deprecated and removed, and only group `objectId`s (GUIDs) may be specified for secure group-based filtering. To mitigate the issue without upgrading, replace all entries in `pam_allow_groups` with the objectId of the target Entra ID group(s) and/or audit your tenant for groups with duplicate display names using the Microsoft Graph API.