Git clients that support delay-capable clean / smudge filters and symbolic links on case-insensitive file systems are vulnerable to remote code execution while cloning a repository. Usage of clean / smudge filters through Git LFS and a case-insensitive file system changes the checkout order of repository files which enables the placement of a Git hook in the .git/hooks directory. By default, this Metasploit module writes a post-checkout script so that the payload will automatically be executed upon checkout of the repository.
e98b3afb62859d7020a7dd7d9fa1db727066effb6fcaf6be5eb8fbff19874b9dThe GitLab internal API is exposed unauthenticated on GitLab. This allows the username for each SSH Key ID number to be retrieved. Users who do not have an SSH Key cannot be enumerated in this fashion. LDAP users, e.g. Active Directory users will also be returned. This issue was fixed in GitLab v7.5.0 and is present from GitLab v5.0.0.
71630cfcfed3904689a0ba6bbbfad435b4547e989b51038e7a14ced61cb53df9This Metasploit module queries the GitLab GraphQL API without authentication to acquire the list of GitLab users (CVE-2021-4191). The module works on all GitLab versions from 13.0 up to 14.8.2, 14.7.4, and 14.6.5.
37361393f26eabdc1c128ac8137d1d761bdfdcc8e7201453e7e793df6a7c3a27This Metasploit module can detect situations where there may be information disclosure vulnerabilities that occur when a Git repository is made available over HTTP.
f3fc66ff62ad13f3081bddfba7d9e771214b26ddbd974bf809d56a802a53e08cThis Metasploit module exploits an account-take-over vulnerability that allows users to take control of a gitlab account without user interaction. The vulnerability lies in the password reset functionality. Its possible to provide 2 emails and the reset code will be sent to both. It is therefore possible to provide the e-mail address of the target account as well as that of one we control, and to reset the password. 2-factor authentication prevents this vulnerability from being exploitable. There is no discernable difference between a vulnerable and non-vulnerable server response. Vulnerable versions include: 16.1 < 16.1.6, 16.2 < 16.2.9, 16.3 < 16.3.7, 16.4 < 16.4.5, 16.5 < 16.5.6, 16.6 < 16.6.4, and 16.7 < 16.7.2.
2a079a5ea68c49929249db07a48797389f6a5b63a1ad6670bced19ea343c8ecfThis Metasploit modules exploits unauthenticated REST API requests in GitStack through v2.3.10. The module supports requests for listing users of the application and listing available repositories. Additionally, the module can create a user and add the user to the applications repositories. This Metasploit module has been tested against GitStack v2.3.10.
9c42f5f230d90c174810268b0beac5ce6dae1160eced3fca962ef937bce0e330An issue has been discovered in GitLab affecting all versions before 16.6.6, 16.7 prior to 16.7.4, and 16.8 prior to 16.8.1. It is possible to read the user email address via tags feed although the visibility in the user profile has been disabled.
62ce2c8280f3e5fc62225b1364f2a471b91cf622a571b2b9ffbd1a00a324ba26GitLab version 16.0 contains a directory traversal for arbitrary file read as the gitlab-www user. This Metasploit module requires authentication for exploitation. In order to use this module, a user must be able to create a project and groups. When exploiting this vulnerability, there is a direct correlation between the traversal depth, and the depth of groups the vulnerable project is in. The minimum for this seems to be 5, but up to 11 have also been observed. An example of this, is if the directory traversal needs a depth of 11, a group and 10 nested child groups, each a sub of the previous, will be created (adding up to 11). Visually this looks like: Group1->sub1->sub2->sub3->sub4->sub5->sub6->sub7->sub8->sub9->sub10. If the depth was 5, a group and 4 nested child groups would be created. With all these requirements satisfied a dummy file is uploaded, and the full traversal is then executed. Cleanup is performed by deleting the first group which cascades to deleting all other objects created.
69b07b1cbc660e9b657d46058136f20875b62aea95d13f5799d7b0fd27caa958Gitea version 1.22.0 suffers from a cross site scripting vulnerability.
679d63e8928338a2795080c2e8acf6c63870fd815e5470dd05c9c71ca4c12184GitKraken GitLens versions prior to 14.0.0 allow an untrusted workspace to execute git commands. A repo may include its own .git folder including a malicious config file to execute arbitrary code. Tested against VSCode 1.87.2 with GitLens 13.6.0 on Ubuntu 22.04 and Windows 10.
b8273beeca3962657f6a9b1d3bfeafcc468090839b20a36ae8bb674024aa42ceGitLab CE/EE versions prior to 16.7.2 suffer from a password reset vulnerability.
ecc61996fa0e38b05ac70ce2080679b2eaf36720822b04f8d38867b1d69456b3GitLab version 15.3 suffers from a remote code execution vulnerability.
6b39aa9dd2e2a7bec60b18975a9f1d8372e350f6d1ff923d82041ba07d234f5cAn authenticated user can import a repository from GitHub into GitLab. If a user attempts to import a repo from an attacker-controlled server, the server will reply with a Redis serialization protocol object in the nested default_branch. GitLab will cache this object and then deserialize it when trying to load a user session, resulting in remote code execution.
01b86153e9b59cbce82f32a07b24098f2267f0bddf0bec3fcf3243c9d0b7d820This Metasploit module exploits the Git fetch command in the Gitea repository migration process to allow for remote command execution on the system. This vulnerability affect Gitea versions prior to 1.16.7.
dba6b158933e4ec6089f6364c6b953e84d8ade82305acdf446dc098ee940e1ddThis Metasploit module exploits the Git fetch command in Gitea repository migration process that leads to a remote command execution on the system. This vulnerability affects Gitea versions prior to 1.16.7.
dd896fa69248da44c654b1dacf601582e7c11220a2ca6e9f2bbf86da8fcd544bGitlab versions 14.9 prior to 14.9.2, 14.8 prior to 14.8.5, and 14.7 prior to 14.7.7 suffer from a persistent cross site scripting vulnerability.
8cb78a3472e539403d6d39fd3ad3b5fdeb25087820f659a117ceeeb4ad1a58b6Gitlab versions 14.9 prior to 14.9.2, 14.8 prior to 14.8.5, and 14.7 prior to 14.7.7 suffer from a bypass vulnerability due to having set a hardcoded password for accounts registered using an OmniAuth provider.
b9871a137c86a7af7a3f259af24481816299cde62d5eef695abcb78150bb320fGitLab version 13.10.2 remote code execution exploit that provides a reverse shell.
a3816f4a73b68abc9aa497e0982428e2bde3d7b0a005094907ca8484d9f39f60This Metasploit module exploits an unauthenticated file upload and command injection vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). The patched versions are 13.10.3, 13.9.6, and 13.8.8. Exploitation will result in command execution as the git user.
674d3772ec48b70f0ba624c93a36ffde9a6d313b18359aa19702fc270257ff56This Metasploit modules exploits a critical vulnerability in Git Large File Storage (Git LFS), an open source Git extension for versioning large files, which allows attackers to achieve remote code execution if the Windows-using victim is tricked into cloning the attacker’s malicious repository using a vulnerable Git version control tool.
aa2d400dab7c8721b2c5166ed34cccd536045aa8292ad9a6b5fb2e07509a8b9eGitlab version 13.10.2 authenticated remote code execution exploit.
fdd3bf5424a5516bb5299cd43e4d54baa10324040cc743962df9d063321ddcabGitlab version 13.9.3 authenticated remote code execution exploit.
caf8edec9ec8c7e7c6f9952908afef2e43a89a4f0838ce4fa452b92c75110fc9GitLab Community Edition (CE) version 13.10.3 suffers from multiple user enumeration vulnerabilities.
5d420382a54e49ae96ced981f0727ae390e51d108048932dd69d45374578bae6Release functionality on GitHub.com allows modification of assets within a release by any project collaborator. This can occur after the release is published, and without notification or audit logging accessible in the UI to either the project owners or the public.
a9d09c7f970e183298b90b8052e3412ba79d05b1448bd2d0c9c5ff3dfc4ead5bThis Metasploit module leverages an insecure setting to get remote code execution on the target OS in the context of the user running Gitea. This is possible when the current user is allowed to create git hooks, which is the default for administrative users. For non-administrative users, the permission needs to be specifically granted by an administrator. To achieve code execution, the module authenticates to the Gitea web interface, creates a temporary repository, sets a post-receive git hook with the payload and creates a dummy file in the repository. This last action will trigger the git hook and execute the payload. Everything is done through the web interface. It has been mitigated in version 1.13.0 by setting the Gitea DISABLE_GIT_HOOKS configuration setting to true by default. This disables this feature and prevents all users (including admin) from creating custom git hooks. This module has been tested successfully against docker versions 1.12.5, 1.12.6 and 1.13.6 with DISABLE_GIT_HOOKS set to false, and on version 1.12.6 on Windows.
777838a8c7aba78aa158817a5091acfd7337de3556b2fc8c26c13ab9c90a1621Gitea version 1.12.5 suffers from a remote code execution vulnerability.
2e393151dd708e15c61f1611fe9a4ff583e2479ce02c55061ec3edece7a76adc
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed