When requests to the internal network for webhooks are enabled, a server-side request forgery vulnerability in GitLab affecting all versions starting from 10.5 was possible to exploit for an unauthenticated attacker even on a GitLab instance where registration is disabled

An issue was discovered in GitLab Enterprise Edition before 11.5.8, 11.6.x before 11.6.6, and 11.7.x before 11.7.1. The Jira integration feature is vulnerable to an unauthenticated blind SSRF issue.

Gitlab Community and Enterprise Editions version 10.3.3 is vulnerable to an Insecure Temporary File in the project import component resulting remote code execution.

An issue was discovered in GitLab Community and Enterprise Edition before 10.8.7, 11.0.x before 11.0.5, and 11.1.x before 11.1.2. CSRF can occur in the Test feature of the System Hooks component.

GitLab 5.0 before 5.4.2, Community Edition before 6.2.4, Enterprise Edition before 6.2.1 and gitlab-shell before 1.7.8 allows remote attackers to execute arbitrary code via a crafted change using SSH.

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.

GitLab Community Edition (CE) and Enterprise Edition (EE) before 8.17.8, 9.0.x before 9.0.13, 9.1.x before 9.1.10, 9.2.x before 9.2.10, 9.3.x before 9.3.10, and 9.4.x before 9.4.4 might allow remote attackers to execute arbitrary code via a crafted SSH URL in a project import.

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.10 before 18.8.7, 18.9 before 18.9.3, and 18.10 before 18.10.1 that could have allowed an unauthenticated user to execute arbitrary GraphQL mutations on behalf of authenticated users due to insufficient CSRF protection.

GitLab Community and Enterprise Editions before 10.1.6, 10.2.6, and 10.3.4 are vulnerable to an unverified password change issue in the PasswordsController component resulting in potential account takeover if a victim's session is compromised.

A cross-site leak vulnerability in the OAuth flow of all versions of GitLab CE/EE since 7.10 allowed an attacker to leak an OAuth access token by getting the victim to visit a malicious page with Safari

Client side code execution in gitlab-vscode-extension v3.15.0 and earlier allows attacker to execute code on user system

Inaccurate display of Snippet files containing special characters in all versions of GitLab CE/EE allows an attacker to create Snippets with misleading content which could trick unsuspecting users into executing arbitrary commands

Missing sanitization of HTML attributes in Jupyter notebooks in all versions of GitLab CE/EE since version 14.5 allows an attacker to perform arbitrary HTTP POST requests on a user's behalf leading to potential account takeover

Client side code execution in gitlab-vscode-extension v2.2.0 allows attacker to execute code on user system

A privilege escalation issue was discovered in GitLab CE/EE 9.0 and later when trigger tokens are not rotated once ownership of them has changed.

An issue was discovered in GitLab Community and Enterprise Edition before 11.1.7, 11.2.x before 11.2.4, and 11.3.x before 11.3.1. There is Cross Site Request Forgery (CSRF) in the Slack integration for issuing slash commands.

An issue has been discovered in GitLab CE/EE affecting all versions starting from 10.6 prior to 16.9.7, starting from 16.10 prior to 16.10.5, and starting from 16.11 prior to 16.11.2 in which cross-site request forgery may have been possible on GitLab instances configured to use JWT as an OmniAuth provider.

An issue was discovered in GitLab Enterprise Edition 10.6 through 12.0.2. The GitHub project integration was vulnerable to an SSRF vulnerability which allowed an attacker to make requests to local network resources. It has Incorrect Access Control.

An issue was discovered in GitLab Community and Enterprise Edition 10.2 through 11.11. Multiple features contained Server-Side Request Forgery (SSRF) vulnerabilities caused by an insufficient validation to prevent DNS rebinding attacks.

GitLab Community and Enterprise Editions version 8.3 up to 10.x before 10.3 are vulnerable to SSRF in the Services and webhooks component.

GitLab has remediated an issue in GitLab EE affecting all versions from 18.0 before 18.6.6, 18.7 before 18.7.4, and 18.8 before 18.8.4 that, under certain conditions could have allowed an authenticated user with certain permissions to make unauthorized requests to internal network services through the GitLab server.

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 allows SSRF.

GitLab CE/EE, versions 8.18 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 SSRF vulnerability in webhooks.

An issue was discovered in GitLab Community and Enterprise Edition before 11.3.11, 11.4.x before 11.4.8, and 11.5.x before 11.5.1. There is an SSRF vulnerability in the Prometheus integration.

An issue was discovered in GitLab Community and Enterprise Edition before 11.1.7, 11.2.x before 11.2.4, and 11.3.x before 11.3.1. There is Server-Side Request Forgery (SSRF) via the Kubernetes integration, leading (for example) to disclosure of a GCP service token.

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.0 before 18.6.6, 18.7 before 18.7.4, and 18.8 before 18.8.4 that, under certain conditions, could have allowed an authenticated user to perform server-side request forgery against internal services by bypassing protections in the Git repository import functionality.

An issue was discovered in GitLab Community and Enterprise Edition before 11.1.7, 11.2.x before 11.2.4, and 11.3.x before 11.3.1. There is Server-Side Request Forgery (SSRF) via a loopback address to the validate_localhost function in url_blocker.rb.

GitLab has remediated an issue in GitLab EE affecting all versions from 18.8 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an authenticated user with control of a virtual registry upstream to make requests to internal hosts due to improper validation.

A server-side request forgery issue has been discovered in GitLab EE affecting all versions starting from 16.8 prior to 17.1.7, from 17.2 prior to 17.2.5, and from 17.3 prior to 17.3.2. It was possible for an attacker to make requests to internal resources using a custom Maven Dependency Proxy URL

An issue was discovered in GitLab Community and Enterprise Edition before 11.x before 11.4.13, 11.5.x before 11.5.6, and 11.6.x before 11.6.1. It allows SSRF.

The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4.4 has SSRF.

GitLab EE/CE 8.0.rc1 to 12.9 is vulnerable to a blind SSRF in the FogBugz integration.

A blind SSRF vulnerability was identified in all versions of GitLab EE prior to 15.4.6, 15.5 prior to 15.5.5, and 15.6 prior to 15.6.1 which allows an attacker to connect to a local host.

In all versions of GitLab CE/EE since version 8.15, a DNS rebinding vulnerability in Gitea Importer may be exploited by an attacker to trigger Server Side Request Forgery (SSRF) attacks.

A blind SSRF in GitLab CE/EE affecting all from 11.3 prior to 15.4.6, 15.5 prior to 15.5.5, and 15.6 prior to 15.6.1 allows an attacker to connect to local addresses when configuring a malicious GitLab Runner.

An external service interaction vulnerability in GitLab EE affecting all versions from 15.11 prior to 17.6.5, 17.7 prior to 17.7.4, and 17.8 prior to 17.8.2 allows an attacker to send requests from the GitLab server to unintended services.

An issue has been discovered in GitLab EE affecting all versions starting from 15.10 prior to 17.2.9, from 17.3 prior to 17.3.5, and from 17.4 prior to 17.4.2. Instances with Product Analytics Dashboard configured and enabled could be vulnerable to SSRF attacks.

An issue has been discovered in GitLab affecting all versions starting from 13.2. Gitlab was vulnerable to SRRF attack through the Prometheus integration.

When requests to the internal network for webhooks are enabled, a server-side request forgery vulnerability in GitLab CE/EE affecting all versions starting from 10.5 was possible to exploit for an unauthenticated attacker even on a GitLab instance where registration is limited

A vulnerability was discovered in GitLab versions before 12.2. GitLab was vulnerable to a SSRF attack through the Outbound Requests feature.

An issue has been discovered in GitLab CE/EE affecting all versions starting from 12.1 before 14.7.7, all versions starting from 14.8 before 14.8.5, all versions starting from 14.9 before 14.9.2 where a blind SSRF attack through the repository mirroring feature was possible.

A vulnerability was discovered in GitLab versions 10.5 to 14.5.4, 14.6 to 14.6.4, and 14.7 to 14.7.1. GitLab was vulnerable to a blind SSRF attack through the Project Import feature.

A vulnerability was discovered in GitLab starting with version 12. GitLab was vulnerable to a blind SSRF attack since requests to shared address space were not blocked.

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. GitLab was vulnerable to a blind SSRF attack through the repository mirroring feature.

For GitLab before 13.0.12, 13.1.6, 13.2.3 user controlled git configuration settings can be modified to result in Server Side Request Forgery.

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.

GitLab 8.10 and later through 12.9 is vulnerable to an SSRF in a project import note feature.

GitLab EE 3.0 through 12.8.1 allows SSRF. An internal investigation revealed that a particular deprecated service was creating a server side request forgery risk.

Server side request forgery protections in GitLab CE/EE versions between 8.4 and 14.4.4, between 14.5.0 and 14.5.2, and between 14.6.0 and 14.6.1 would fail to protect against attacks sending requests to localhost on port 80 or 443 if GitLab was configured to run on a port other than 80 or 443