Various uses of the Go toolchain in untrusted VCS repositories can result in unexpected code execution. When using the Go toolchain in directories fetched using various VCS tools (such as directly cloning Git or Mercurial repositories) can cause the toolchain to execute unexpected commands, if said directory contains multiple VCS configuration metadata (such as a '.hg' directory in a Git repository). This is due to how the Go toolchain attempts to resolve which VCS is being used in order to embed build information in binaries and determine module versions.
The toolchain will now abort attempting to resolve which VCS is being used if it detects multiple VCS configuration metadata in a module directory or nested VCS configuration metadata (such as a '.git' directoy in a parent directory and a '.hg' directory in a child directory). This will not prevent the toolchain from building modules, but will result in binaries omitting VCS related build information.
If this behavior is expected by the user, the old behavior can be re-enabled by setting GODEBUG=allowmultiplevcs=1. This should only be done in trusted repositories.
Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting this issue.
This is CVE-2025-4674.
/cc @golang/security and @golang/release
Comment From: rolandshoemaker
@gopherbot please open backport issues for this.
Comment From: gopherbot
Backport issue(s) opened: #74381 (for 1.24), #74382 (for 1.23).
Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.
Comment From: gopherbot
Change https://go.dev/cl/686338 mentions this issue: [release-branch.go1.25] cmd/go: disable support for multiple vcs in one module
Comment From: gopherbot
Change https://go.dev/cl/686337 mentions this issue: [release-branch.go1.23] cmd/go: disable support for multiple vcs in one module
Comment From: gopherbot
Change https://go.dev/cl/686395 mentions this issue: [release-branch.go1.24] cmd/go: disable support for multiple vcs in one module
Comment From: gopherbot
Closed by merging CL 686338 (commit 2899144b8d80e8d73274c04fb39a36d3a54658dd) to release-branch.go1.25.
Comment From: gopherbot
Change https://go.dev/cl/686515 mentions this issue: cmd/go: disable support for multiple vcs in one module
Comment From: stefanb
Please note, that commit messages had mixed up issue references, which caused closing of wrong issues and moving some (which was not yet closed at the time of release) to the next milestone.
Specifically: * https://github.com/golang/go/commit/e9d2c032b14c17083be0f8f0c822565199d2994f was merged to release-branch.go1.23, but referenced issue for Go 1.24: https://github.com/golang/go/issues/74382 which was moved to 1.24.6 milestone and closed * https://github.com/golang/go/commit/825eeee3f789a11231ce23a4836c74ec5e34bf2a was merged to release-branch.go1.24, but referenced issue for Go 1.23: https://github.com/golang/go/issues/74381, which was moved to 1.23.12 milestone and closed
Comment From: cagedmantis
@stefanb Thanks for pointing out the error. We will work to correct what we can at this point.
Comment From: mariduv
Forgive me if this is the wrong place to open a discussion connected to this change, but I was surprised to hit this "multiple VCS detected" error today with 1.24.5*, and my situation is that my homedir is a live hg repo with an .hgignore of *, while the project I was building is a git clone deeper within. I set the new GODEBUG flag in order to continue that work, but going forward I'd need to either have it set at all times, putting myself at risk of CVE-2025-4674 it seems, or switch to a dotfiles management scheme where you need a script to link or copy files into place rather than work in situ.
I'm sure I've benefited from mercurial being less popular, but I haven't had anything else take issue with this nested setup in 15 years, and most software supporting several vcs seems to stop walking upward when it finds any single vcs's fingerprints.
I don't think I completely understand the risk (of executing unexpected commands) from the opening remark above and the commit text, nor is there anything in CVE databases yet. I'm trying to figure out if this new buildvcs behavior is unusually cautious, or if this is also a risk to all software that does VCS detection, such as editor status boxes and shell prompts. I'm aware of plenty of other injections, but I couldn't find any enlightening results from a search for "vcs injection" attack 😅
Comment From: dolmen
@mariduv I think that this deserves being reported as a separate issue as this is closed.