Vulnerability Database

328,781

Total vulnerabilities in the database

CVE-2020-11008

Affected versions of Git have a vulnerability whereby Git can be tricked into sending private credentials to a host controlled by an attacker. This bug is similar to CVE-2020-5260(GHSA-qm7j-c969-7j4q). The fix for that bug still left the door open for an exploit where some credential is leaked (but the attacker cannot control which one). Git uses external "credential helper" programs to store and retrieve passwords or other credentials from secure storage provided by the operating system. Specially-crafted URLs that are considered illegal as of the recently published Git versions can cause Git to send a "blank" pattern to helpers, missing hostname and protocol fields. Many helpers will interpret this as matching any URL, and will return some unspecified stored password, leaking the password to an attacker's server. The vulnerability can be triggered by feeding a malicious URL to git clone. However, the affected URLs look rather suspicious; the likely vector would be through systems which automatically clone URLs not visible to the user, such as Git submodules, or package systems built around Git. The root of the problem is in Git itself, which should not be feeding blank input to helpers. However, the ability to exploit the vulnerability in practice depends on which helpers are in use. Credential helpers which are known to trigger the vulnerability: - Git's "store" helper - Git's "cache" helper - the "osxkeychain" helper that ships in Git's "contrib" directory Credential helpers which are known to be safe even with vulnerable versions of Git: - Git Credential Manager for Windows Any helper not in this list should be assumed to trigger the vulnerability.

  • Published: Apr 21, 2020
  • Updated: Nov 9, 2025
  • CVE: CVE-2020-11008
  • Severity: Low
  • Exploit:

CVSS v3:

  • Severity: Low
  • Score: 4
  • AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N

CVSS v2:

  • Severity: Medium
  • Score: 5
  • AV:N/AC:L/Au:N/C:P/I:N/A:N
Software From Fixed in
git-scm / git 2.18.0 2.18.4
git-scm / git 2.19.0 2.19.5
git-scm / git 2.20.0 2.20.4
git-scm / git 2.21.0 2.21.3
git-scm / git 2.22.0 2.22.4
git-scm / git 2.23.0 2.23.3
git-scm / git 2.24.0 2.24.3
git-scm / git 2.25.0 2.25.4
git-scm / git 2.26.0 2.26.2
git-scm / git - 2.17.5
debian / debian_linux 8.0 8.0.x
canonical / ubuntu_linux 16.04 16.04.x
canonical / ubuntu_linux 18.04 18.04.x
canonical / ubuntu_linux 19.10 19.10.x
fedoraproject / fedora 31 31.x
fedoraproject / fedora 32 32.x

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.