Ah, I see what you're getting at now I think - an exploit would not be required as you are blindly running the go code anyway (e.g. in a web server it could read/write files etc just as the web server process can). Might being able to cause heap corruption let the code affect server operations in unexpected ways though? For example bypassing restrictions on an app plugin in some sort of CMS, bypassing restrictions on something like db access or passwords in memory, or bypassing a sandbox like that on play.golang.org.

I don't think Go is especially vulnerable in this regard, as you noted below ruby gems are also mostly unsigned just now, however I think there was a move to have those signed after the recent problems, and Go's pkgs don't have metadata or a facility to do this AFAIK. So that could be seen as a weakness (though one shared by many other package management systems).