Malicious Go Packages Mimic Google UUID to Steal Developer Data
Hoplon InfoSec
08 Dec, 2025
If you use Go, you might want to ask yourself this question today: Is it possible that a "harmless" Go dependency is really a secret spy in your code? Yes, the answer is yes. Recent studies have found bad Go packages that look like real UUID libraries but actually steal sensitive data without anyone knowing, even from CI pipelines.
Every Go developer should be worried about that discovery because it shows that typosquatting Go modules and supply chain attack tactics are more real and dangerous than most people think. In this article, I'll show you step by step what happened, why it matters, and how you can protect yourself and your projects.
Why this(malicious Go packages) problem is important for Go developers right now
Most modern Go apps are built on open-source libraries. Shared utilities, database drivers, UUID generators, and other tools help us get things done faster. That ease of use, though, also comes with some risk. The recent case of a fake UUID library shows how easily and quietly a Go module trojan can get in.
When developers copy import paths from memory or tutorials, a small mistake in the name can send them to a bad package instead of a good one. Typosquatting Go modules can cause this kind of small confusion, which can let attackers get into code that is used in production or in CI pipelines.
Once inside, a bad package might act like a good one when it is used normally. It lets code run as it should. But in the background, it might be gathering secrets, passwords, user data, or environment variables. This means that your app, logs, or even build environment might leak private data without any obvious error or warning.
A single wrong import can spread widely across dependencies because Go's ecosystem lets you import directly from GitHub or other repositories, as well as public module proxies and caching. That means the risk is not just one thing, but a whole system.
What really happened: how bad Go packages pretended to be a trusted UUID library and stole data
The example of a fake UUID
Recently, a group of researchers from the Socket Threat Research Team found two harmful Go packages: github.com/bpoorman/uuid and github.com/bpoorman/uid. These names are very similar to well-known and trusted UUID libraries like github.com/google/uuid and github.com/pborman/uuid.
The attacker used the name bpoorman instead of pborman. This could easily happen to a lot of developers, especially when they are copying code or working quickly. After being imported, the bad library acted just like the real one and made valid UUIDs. That made the attack hard to see.
Hidden exfiltration inside an API that looks familiar
The fake package also added a hidden function called Valid. That seems reasonable at first glance, since many real libraries have validation helpers. But in this case, when a developer sent sensitive information like user IDs, session tokens, email addresses, or other sensitive values to Valid, the code encrypted that information and sent it to a public paste site using a hard-coded API token. There were no alerts or errors during any of this.
The malicious Go package github dot com slash bpoorman slash uuid: source
Most developers never thought anything was wrong because the malicious module still "worked." The package had been available to the public since May 2021, and it was still accessible through the public module proxy and the central package discovery site when it was found.
This is a clear example of how a Go package can leak data without anyone noticing. When code that uses that package runs, it could be leaking data, like internal CI credentials or tokens.
What you need to do: how to keep your Go projects safe from bad dependencies.
These tips can help you stay safe if you work with Go code or CI/CD pipelines:
• Check your dependencies very carefully. Check the contents of your go.mod and go.sum files. Make sure that any UUID or utility packages point to well-known, trusted sites like github.com/google/uuid or github.com/pborman/uuid. Be extra careful with packages that have similar names or user names that look suspicious.
• Check imported modules by hand if they are small or aren't updated very often. Just because a package has a name that sounds good doesn't mean it's safe. Look over the code carefully, paying special attention to any hidden network calls or strange helper functions.
• Use tools for supply chain security. Some tools look for suspicious behavior, like dependencies, obfuscated code, network calls, and other things that look like they might be bad. These tools add an extra layer of safety on top of manual review.
• If you think a module has been compromised, take it out right away and change the CI secrets. That includes environment variables, tokens, credentials, or API keys that are kept in CI or deployment pipelines.
• Think about using a private module proxy or selling dependencies. This means you don't have to rely as much on public mirrors or automatic imports. It gives your team more power over what code actually goes into builds.
These steps lower the chance that a supply chain attack Go or Go module trojan, will secretly compromise your codebase or infrastructure.
Go is especially weak because of its design and ecosystem.m
This risk is made worse by the way the Go ecosystem is set up. First, Go lets developers import directly from any GitHub repository or other URL, rather than having to go through a central, curated registry. Because of this flexibility, it's not hard to publish typosquatting and malicious modules.
The module proxy and caching system (like the official public Go module mirror) is also meant to keep modules in cache forever to make sure that builds are reliable and can be repeated. That feature can be a problem if a bad package gets cached. Even if the upstream repository is cleaned up, the bad version can stay in the cache and keep being served to developers.
Many projects use utility libraries that are deeply embedded in them, like UUID generators. Once a malicious version gets in, it can quietly affect a lot of other things that depend on it. Code review or testing may not show the problem because the package still works as it should.
This is a clear case of a risk in the supply chain for package managers. Attackers can take advantage of the trust that developers put in open-source dependencies, as well as automated tools and indirect imports.
Not just data leaks, but also remote code execution and persistence are real threats.
There are other threats besides the fake UUID package. Researchers found a larger campaign of bad Go modules that sent hidden payloads to Linux or macOS systems. These modules could run code from a distance, get more malware, or even wipe disks.
In some cases, the packages used string obfuscation to hide commands for the shell. When these modules were imported, they rebuilt the commands at runtime, downloaded a payload from servers controlled by the attacker, and ran it. This completely bypassed static analysis and many sandbox protections.
This means that if a package like that got into a CI/CD pipeline or a developer's workstation, it could send a second-stage payload with full control, which could steal secrets, install backdoors, or do permanent damage.
This larger campaign shows that the threat goes beyond UUID libraries and data exfiltration. The ecosystem is being attacked smartly and actively, and the attackers can switch to remote code execution, persistence, and real damage.
What Go has to offer and where you need to be careful
What makes Go interesting
Go modules give developers freedom and speed. You can directly import libraries, utilities, and tools, reuse code easily, and take advantage of a huge ecosystem of open-source packages. A public module proxy makes builds more reliable and consistent.
This model speeds up the development and sharing of solutions when things go well.
Why the risk is real
That flexibility also makes it easy for attackers to publish bad packages or packages with typos. Once they are published, public proxies and caching systems can spread those packages widely and keep them available, even if the original repository is cleaned up.
It's hard to find malicious packages because they can look like real APIs and act as they should for normal use. Backdoor functions that are hidden, code that is hard to read, or payloads that are encrypted can get past security. Transitive dependencies make it even worse because one broken package can hurt many other projects without anyone knowing.
If developers automatically run code in CI, containerized builds, or on servers without checking it carefully, a bad package can quietly break real infrastructure.
Questions that are often asked
Q: What do bad Go packages do to steal data?
A: In some cases that have been reported, attackers put hidden functions, like Valid, into packages that look real. The package encrypts the data and sends it to endpoints controlled by the attacker (like a public paste site) using hard-coded API tokens when code sends sensitive data to those functions.
Q: Which Go modules have been discovered to pretend to be real libraries?
A: A recent example is github.com/bpoorman/uuid (and a related bpoorman/uid), which pretends to be a UUID utility package meant to look like github.com/google/uuid or github.com/pborman/uuid.
There has also been a larger campaign against other modules, such as a backdoored copy of a database library at github.com/boltdb-go/bolt.
Q: How can these kinds of dependencies take secrets from CI systems?
A: If a malicious module is imported into your CI pipeline or deployment scripts, that module can get to environment variables or configuration values that are passed to it. If the module steals data or runs remote payloads, it could get API tokens, passwords, or other CI secrets without anyone knowing.
Q: What are some signs that a Go module might be malicious or have typos?
A: Some warning signs are: maintainer names that are strange or slightly misspelled; packages that don't get much activity or stars but look like popular library names; small utility libraries that make unexpected network calls or have encrypted payloads; README content that is hard to find; or versions served through public proxies long after repository changes. You should also be worried if your go.mod file has a suspicious import path or your go.sum file has entries that you didn't expect.
Here's what you can do right now
Every Go developer and team should be on high alert after finding malicious Go packages that pretend to be UUID libraries. Attackers were able to easily use typosquatting Go modules to sneak a Go package exfiltrate data Trojan into the ecosystem. This shows how fragile trust can be when automation and open source come together.
As a manager of Go projects, you should treat every dependency as possibly untrusted until you check it out. Take a moment to look over your import paths. Check dependencies by hand or with security tools. After a suspicious import, clean up right away and change the CI secrets. When you can, use private module proxies or vendoring.
There is a real risk in Go's supply chain. But if you are aware, develop good habits, and take some simple precautions, it will be much harder for bad code to get in. A little care now can save you a lot of trouble later.
You can also read these importantcybersecuritysnews articles on our website.
· Apple Update,
· Windows Fix,
For more P, please visit our Homepage and follow us on X (Twitter) and LinkedIn for more cybersecurity news and updates. Stay connected on YouTube, Facebook, and Instagram as well. At Hoplon Infosec, we’re committed to securing your digital world.
Share this :