By A couple of years ago wepublisheda blog post with the intention to create a resource that code auditors and security-minded engineers can refer to when auditing or developing Golang projects. In that post we covered some bug classes that we have often seen during our own Golang code auditing projects. Thanks to the second law of thermodynamics time only keeps moving forward, and as any decently supported modern programming language, Go has seen a lot of changes and improvements since our first blog post. So we decided to create this follow-up post with the same idea in mind. Since out first post, automated tooling and AI assistants have raised the floor for code review: a lot of the obvious bugs now get caught on the first pass, by anyone. But that floor is also where most reviewers stop, because the tooling stops there too — the rules only flag what they already know to look for. What separates an experienced auditor is knowing the language's sharp edges that no rule covers yet, and going looking for them deliberately. In this post, first we will start with a quick look at what changes have been made to the language to make security easier and more intuitive for folks (with no particular selection criteria on what we're going to cover). Then we have a bunch of new footguns we would like to highlight, hopefully to the benefit of everyone auditing or developing Golang projects. Finally, we are also releasing a couple of semgrep rules to close the gap regarding these risky coding patterns. The rules can be found in our Semgrep rulesrepository. With the introduction out of the way, first let's see what are some of the features that were introduced Golang with a major impact on its security landscape. To start with something that is mildly concerning, pretty much everything from our previous blog post is still valid in 2026 - with one major caveat. While path traversal is still a very real thing, over a year ago the release of Go 1.24introduceda new set of APIs calledos.Root. Without repeating too much of what is very well explained in the Go team's blog post, these APIs are meant to stop path traversal altogether by creating a root directory and on the framework level disallowing reads and writes past this point. Everything below the root is still available, including child directories and symlinks (as long as they stay within the root). While this is a very useful feature it wasn't withoutteethingproblems; however these were quickly fixed in Go 1.25. In a similar fashion, the Go team has just concluded theirmath/randimprovement era that ran over the course of Go 1.20 to 1.26 (which is the current version at the time of publishing). Go went from "passing nil torsa.GenerateKeyis silently catastrophic" to "it doesn't matter what you pass, the function will do the right thing." This was achieved by tidying upmath/randto the point where developers have an explicit choice between PRNG andcrypto/rand- as opposed to manually seeded generators, which are completely gone from the library at this point. Additionally, the footgun of accidentally using an unsafe random when generating private keys has been removed by making sure that these functions ignore anyio.Reader's passed to them and just use a secure internal random unconditionally. Ok, that's enough preamble, time to dig into the actual footguns.