When the go command issues an HTTP request to find the repository URL for a module, it expects to receive a response containing a <meta> tag:
<meta name="go-import" content="root-path vcs repo-url [subdirectory]">
From https://go.dev/ref/mod#vcs-find:
repo-url is the repository’s URL, containing a scheme and not containing a .vcs qualifier. Insecure protocols (like http:// and git://) may only be used if the module path is matched by the GOINSECURE environment variable.
The go command currently does not implement the requirement that the repository URL be either secure (like https://) or matched by the GOINSECURE environment variable.
This was reported to us as a potential vulnerability. Our conclusion is that while this is a bug, we cannot see any plausible path for an attacker to exploit it. The impact of this bug is that an attacker who controls the module path in the <meta> tag can cause the module to be served over an unencrypted transport. This doesn't aid in serving a malicious module, since a malicious module can be served over an encrypted transport.
It's still a bug and we should fix it.
When the
gocommand issues an HTTP request to find the repository URL for a module, it expects to receive a response containing a<meta>tag:From https://go.dev/ref/mod#vcs-find:
The
gocommand currently does not implement the requirement that the repository URL be either secure (likehttps://) or matched by the GOINSECURE environment variable.This was reported to us as a potential vulnerability. Our conclusion is that while this is a bug, we cannot see any plausible path for an attacker to exploit it. The impact of this bug is that an attacker who controls the module path in the
<meta>tag can cause the module to be served over an unencrypted transport. This doesn't aid in serving a malicious module, since a malicious module can be served over an encrypted transport.It's still a bug and we should fix it.