CVE-2026-41506

What it actually does

CVE-2026-41506 is a credential exposure flaw in the go-git library’s smart-HTTP clone and fetch handling. Before go-git 5.18.0 and 6.0.0-alpha.2, when a repository request receives an HTTP redirect, the library may forward HTTP authentication credentials, such as Basic authentication headers, bearer tokens, or other authorization material, to the redirected destination. If an attacker can cause or control a redirect target during a clone or fetch operation, credentials intended for the original Git server may be disclosed to an unintended host. The weakness requires user or application interaction that performs a clone or fetch over HTTP(S), and it primarily affects confidentiality rather than integrity or availability.

Why it matters to the business

Applications, automation systems, developer tools, CI/CD components, or services that use vulnerable go-git versions may unintentionally disclose Git credentials to an external or attacker-controlled server. Exposed credentials could allow unauthorized access to source code, private repositories, build pipelines, package manifests, infrastructure-as-code, or other sensitive development assets. The CVSS score is moderate and EPSS is currently low with no known KEV listing or public exploit maturity, but the impact can still be material where long-lived repository tokens or broadly scoped credentials are used. Because go-git is a reusable library, exposure may be indirect through downstream tools rather than obvious from a deployed product name.

How an attack unfolds

An attacker first identifies an application, CLI tool, build process, or service that uses a vulnerable version of go-git to perform smart-HTTP clone or fetch operations with authentication. The attacker then causes the Git URL or Git server response path to involve an HTTP redirect, such as by controlling a repository endpoint, compromising an intermediate service, abusing a user-supplied repository URL, or influencing DNS/proxy/routing behavior. During the clone or fetch, the vulnerable library follows the redirect and may send the original Authorization header or equivalent HTTP credential material to the redirected host. If the redirected host is attacker-controlled or observable by the attacker, the credential can be captured from HTTP request logs or packet data. The attacker can then attempt to reuse the credential against the legitimate Git service or related source-control infrastructure, subject to token scope, expiration, IP allowlists, and other controls.

How to fix it

Upgrade all direct and transitive uses of go-git to a patched release: go-git v5 users should upgrade to 5.18.0 or later, and go-git v6 alpha users should upgrade to 6.0.0-alpha.2 or later. Rebuild and redeploy software that statically links or vendors go-git, because updating the system package alone may not update embedded library code. Review dependency lockfiles, vendored modules, container images, CI runners, developer tools, and internally built binaries that include github.com/go-git/go-git. As a compensating control, restrict outbound HTTP(S) destinations from automation systems that perform Git operations, disallow redirects to untrusted hosts where possible, avoid user-controlled repository URLs, and use short-lived, least-privilege repository tokens. Rotate credentials that may have been used by vulnerable clone or fetch workflows where redirects to untrusted locations were possible or observed.

How to confirm the fix worked

Confirm that dependency manifests and resolved module versions show github.com/go-git/go-git at 5.18.0 or later, or the v6 alpha line at 6.0.0-alpha.2 or later. For Go projects, inspect go.mod, go.sum, vendored modules, software bill of materials, and built binary dependency metadata where available. Rebuild applications after upgrading and verify deployed artifacts contain the patched version rather than only the source tree being updated. Test representative clone and fetch workflows against a controlled redirecting HTTP endpoint and confirm credentials are not forwarded to a different host. Validate that Git automation rejects or tightly controls redirects to unapproved domains, and review outbound proxy or egress logs to confirm authenticated Git traffic is limited to expected repository hosts.

Typical attack path

1. Identify software or automation that uses vulnerable go-git versions before 5.18.0 or 6.0.0-alpha.2.
2. Find a path to influence a clone or fetch operation, such as a user-provided repository URL, dependency source URL, webhook-driven fetch, CI job, or mirrored repository configuration.
3. Cause the Git HTTP endpoint to return a redirect to a host controlled or monitored by the attacker.
4. Wait for the vulnerable client to follow the redirect during a smart-HTTP clone or fetch operation.
5. Capture leaked HTTP authentication material from the redirected request, commonly from web server access logs, reverse proxy logs, or packet capture.
6. Replay or use the exposed credential against the intended Git hosting service or other services where the same credential is accepted.
7. Use resulting access to read private repositories, enumerate code and secrets, or pivot into CI/CD and development workflows.

How to detect it

Investigate whether vulnerable applications performed authenticated smart-HTTP clone or fetch operations that encountered redirects to unexpected hosts. Relevant sources include application logs, CI/CD job logs, Git automation logs, outbound web proxy logs, firewall or DNS logs, reverse proxy logs, source-control audit logs, and any controlled Git gateway logs. Look for HTTP 301, 302, 303, 307, or 308 responses during Git clone or fetch operations, followed by outbound requests to a different hostname that include an Authorization header or other credential-bearing header. Pay particular attention to redirects involving user-supplied repository URLs, dependency fetching, repository mirroring, or build jobs. Compare destination hosts against approved Git hosting domains and investigate any requests where authenticated Git traffic was sent to an unrecognized domain. If a redirect target is attacker-controlled or unknown, assume the associated credential may have been exposed and rotate it. On the source-control side, review audit logs for subsequent use of the same token from unusual IP addresses, new geographies, unfamiliar user agents, unexpected repository enumeration, bulk cloning, or access to repositories outside normal patterns.

• github.com/go-git/go-git
• go-git
• Authorization: Basic
• Authorization: Bearer
• Authorization: token
• WWW-Authenticate
• Location: http://
• Location: https://
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 307 Temporary Redirect
• 308 Permanent Redirect
• /info/refs?service=git-upload-pack
• /git-upload-pack
• service=git-upload-pack
• git clone
• git fetch

What your security team should do

• Inventory software, internal tools, CI/CD components, and third-party products that embed or depend on github.com/go-git/go-git.
• Prioritize upgrade of internet-facing, CI/CD, repository mirroring, dependency fetching, and user-supplied Git URL processing workflows to go-git 5.18.0 or later, or 6.0.0-alpha.2 or later for the v6 alpha branch.
• Rotate Git credentials used by vulnerable automation if logs show redirects, unexpected outbound Git traffic, or repository URLs influenced by untrusted users.
• Reduce token scope to the minimum required repository permissions and prefer short-lived tokens over long-lived passwords or personal access tokens.
• Restrict egress from build and automation environments so authenticated Git clients can only reach approved source-control hosts.
• Add monitoring for authenticated HTTP requests to unexpected domains immediately after Git clone or fetch activity.
• Review application features that accept arbitrary Git URLs and enforce allowlists, scheme restrictions, and redirect controls.
• Include go-git in software composition analysis and SBOM checks so downstream or vendored vulnerable copies are not missed.