How a Typosquatting Attack on BoltDB Exposed a Major Security Flaw in the Go Ecosystem

Feb 4

A recent typosquatting attack on Go developers disguised a malicious package as the popular BoltDB library, slipping in a backdoor that gave attackers remote access to infected systems. By exploiting Go’s module caching and a simple naming trick, the attacker ensured that even after cleaning up the repository, the malicious version remained available for download.

This attack highlights a major security flaw in package management: once a malicious package is cached by Go’s proxy, it cannot be removed or updated. That means unsuspecting developers could still install the compromised version long after the attacker "cleaned up" the repo.

Here’s a quick overview on the attack chain:

Now lets talk about how the attack worked, why it was so hard to catch, and what developers can do to stay safe.

Phase 1: Attack Setup & Initial Infection

Typosquatting: Tricking Developers

The attacker created a fake package named boltdb-go/bolt, which closely resembles the legitimate boltdb/bolt package [1].

Since developers often install packages quickly, a small typo or confusion during a search could lead them to accidentally install the fake package instead of the real one.

Malicious Code Injection

Once installed, the fake package secretly executed malicious code:

It was tagged as v1.3.1 to look like a normal update.
Malicious logic was hidden in db.go and cursor.go.
A function (_r()) obscured the attacker's Command & Control (C2) server address:
- 49.12.198[.]231:20022 (formatted this way to prevent accidental clicks).
The Open() function—a standard BoltDB method—triggered a persistent connection to the attacker’s server.
If the connection dropped, the backdoor restarted itself, keeping access open.

At this point, any developer who unknowingly installed the fake package had already given the attacker a foothold on their machine.

Phase 2: Exploiting Go Module Caching

Once the attacker got the malicious version published, they took advantage of Go’s module proxy system, which permanently caches module versions.

Getting Cached by Go’s Proxy

The attacker uploaded the fake package to a public repository (such as GitHub).
Go Module Proxy (proxy.golang.org) cached it when a developer installed it for the first time.
Once cached, Go’s proxy wouldn’t allow modifications or deletions—even if the repository owner removed or changed the package later.

Hiding the Evidence with Git Tags

After ensuring that Go’s proxy had cached the malicious version, the attacker replaced the package in GitHub with a clean version using Git tags.
Now, if someone manually checked the repository, they’d only see a clean package—but Go’s proxy was still serving the older, malicious version to developers installing it.

This bait-and-switch meant that developers had no way of knowing they were pulling a compromised package unless they specifically checked what was being installed on their system.

Phase 3: Persistent Backdoor & Exploitation

Developers Keep Downloading the Malicious Package

Because Go’s proxy kept serving the cached malicious version, any developer who installed boltdb-go/bolt would unknowingly pull the compromised package [2].

Remote Code Execution (RCE) via Backdoor Activation

When the Open() function is executed, the backdoor activates, allowing the attacker to[1]:

Establish a persistent connection to the Command & Control (C2) server.
Receive and execute commands on the victim’s system.
Send command results back to the attacker.

Since BoltDB is widely used in Go applications, this attack could have compromised a large number of development environments.

Key Takeaways

Package Management is a Security Risk

Attackers exploit Git tags, package naming tricks, and module caching to keep malicious versions accessible even after being removed from repositories.

Go Module Caching Can’t Be Reversed

Once a package is cached by proxy.golang.org, it can’t be changed or removed, which means developers can still install a bad version even after it’s been “fixed”.

Typosquatting is a Serious Threat

Even well-known libraries aren’t safe—all it takes is a small typo for a developer to accidentally install a malicious package.

Checking the Repository is Not Enough

A clean GitHub repository doesn’t mean a package is safe—Go’s proxy might still serve an older, cached malicious version.

Obfuscated Code Can Hide Backdoors

Attackers use code obfuscation to hide malicious logic, making manual code reviews ineffective.

What Developers Can Do to Stay Safe

1. Double-Check Package Names

Always verify the exact package name before installing to avoid typosquatted versions.

2. Use Security Tools That Scan Installed Dependencies

Static code reviews aren’t enough—use tools that analyze the actual installed package rather than just checking the repository.

3. Host a Private Module Proxy

Instead of relying on proxy.golang.org, use a private Go module proxy to control what versions are cached and prevent accidental downloads of malicious versions.

4. Monitor Dependencies for Suspicious Changes

Keep track of new versions and dependency changes, especially for widely used packages like BoltDB.

5. Implement Dependency Pinning

Use Go modules with specific version numbers to ensure that your project always pulls a known, safe version.

The real issue isn’t just one bad package—it’s the design of package management systems, which make typosquatting and caching exploits easy for attackers. Developers need to take control of their dependencies to stay secure.

Citation

Socket. (2024, February 4). Malicious package exploits Go module proxy caching for persistence. Socket. https://socket.dev/blog/malicious-package-exploits-go-module-proxy-caching-for-persistence
Lakshmanan, R. (2025, February 4). Malicious Go package exploits module mirror caching for persistent remote access. The Hacker News. https://thehackernews.com/2025/02/malicious-go-package-exploits-module.html

Emilia Mancilla