The Golang msi installer in Windows install by default Go in C:\Go location.
Files and subfolders of folders created under C:\ by default can be edited, created, deleted.

PS C:\Go> icacls .
  BUILTIN\Administrators:(I)(OI)(CI)(F)
  NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
  BUILTIN\Users:(I)(OI)(CI)(RX)
  NT AUTHORITY\Authenticated Users:(I)(M)
  NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)

This means that in a shared Windows environment, is it possible to exploit this insecure ACL to replace/backdoor go.exe binaries, dll and so on.

Scenario Local Privilege Escalation

A Standard User backdoor go.exe, waits for an Administrator to log in and run "go ..." or another component under C:\Go to successfully execute code under the latter elevated context.

Scenario Horizontal Privilege Escalation

A Standard User can backdoor/replace any component under C:\Go and wait for another Standard User to login and run Golang environment to achieve code execution in the context of the target user.

What version of Go are you using (go version)?

Up to latest Golang version: 1.13

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

$ go env
set GOHOSTARCH=amd64
set GOHOSTOS=windows

What did you expect to see?

I was expecting the msi installer to reconfigure after installation the C:\Go default destination folder to have an ACL hardened to allow only Administrators, Administrator, SYSTEM, TrustedInstaller to have modify, write and special permissions over the Golang components.

What did you see instead?

Authenticated Users have Modify permission over any Golang component, thus local privilege escalation is possible.