The unusual suspect: attackers now hiding payloads in Git repositories

A new frontier in payload delivery

Security researchers have uncovered an emerging tactic: malicious actors are embedding payloads and shell scripts directly inside Git repositories hosted on popular platforms like GitHub, GitLab, and Bitbucket.

The repositories are often cloned by DevOps teams or included as dependencies in CI/CD pipelines. Once pulled into internal environments, the attacker’s code can trigger data exfiltration, privilege escalation, or lateral movement.

This marks a shift from classic malware delivery via phishing or binaries — attackers are now hiding inside the tools developers trust most.

How it works

The attack typically unfolds as follows:

• An attacker sets up a public Git repository with a name and commit history mimicking a legitimate or open source project
• They include a malicious shell script, backdoor, or obfuscated payload in an inconspicuous location — often inside subdirectories or build scripts
• The repo is linked to by a supply chain dependency, automated script, or CI config
• When the repo is cloned or used, the payload is executed inside the target environment — often without alerting antivirus or EDR systems

In many cases, the payload is not in the repo’s main branch, helping it evade manual review or automated scanners.

What we’ve seen in the field

At Cyber Protocol, we’ve encountered this technique in at least four enterprise audits this year — and in each case, the malicious repository had been:

• Cloned into Docker build stages
• Used in CI/CD workflows with excessive trust assumptions
• Included in infrastructure-as-code scripts without verification
• Imported via submodules that bypassed internal code review policies

In one case, a compromised Git repo gave attackers persistent callback access to a production staging environment via a curl-based one-liner embedded in a Bash script.

This wasn’t malware in the traditional sense. It was trusted code from a trusted tool.

What we recommend

Git-based payloads are hard to catch with traditional detection methods. Here’s how to reduce your exposure:

1. Never clone from unaudited sources

Only allow Git repositories from whitelisted, verified origins — especially in automated pipelines or provisioning scripts.

2. Inspect all scripts before execution

Shell scripts, postinstall scripts, and CI hooks should be treated as untrusted by default. Use static analysis tools to scan them.

3. Monitor Git usage in build environments

Set alerts for git clone, curl, wget, or chmod +x behaviors during pipeline runs. These often precede abuse.

4. Avoid automatic submodule or external dependency resolution

Force manual review of every submodule reference or dynamic fetch inside .gitmodules, package.json, or Dockerfiles.

5. Periodically scan Git history

Attackers often hide payloads in older commits or side branches. Use automated tools to audit commit chains for anomalies or obfuscated code.

Final word

The threat isn’t in your firewall logs — it’s in your Git history.

As attack surfaces shift into CI/CD, the trust we place in developer tools is being actively weaponized. Git is no longer just a version control system. It’s now an initial access vector.

Want to know if your dev pipelines are exposing you to Git-based payloads?

Cyber Protocol offers secure CI/CD audits, Git commit history scanning, and dependency chain analysis.

Schedule a CI/CD threat review

Code should be reviewed — especially when it isn’t yours.

Git is fast. So are attackers.

— The Cyber Protocol Team