In September 2024, Mukesh, chief technology officer of Razz Security, published a demonstration of how a chain of small CI/CD mistakes can end in full control of a production server. It started with a web server that exposed its .git directory. The .git/config file held repository credentials, which let the researcher clone the whole repository, including its Bitbucket Pipelines configuration. That pipeline deployed code to a production server over SSH using the atlassian/ssh-run pipe. By editing the pipeline file and pushing the change to the master branch, the researcher made the next pipeline run add their own SSH public key to the server's authorized_keys file, giving them persistent SSH access as the server's user. The write-up, as summarised by Technijian, names the target only as damn.vulnerable.site, and no affected organisation was identified, so this was a demonstration rather than a confirmed breach. The original Razz Security report is no longer online. The technique itself is well documented: in October 2024, Sysdig reported that the EMERALDWHALE operation had stolen more than 15,000 cloud credentials by scanning for exposed Git configuration files.
Key takeaways
- A Razz Security researcher showed how an exposed .git directory could lead to full server takeover through a CI/CD pipeline.
- Credentials in .git/config let the researcher clone the repository, including the Bitbucket Pipelines configuration.
- Editing the pipeline made the deployment job add the researcher's SSH key to the production server.
- No victim was identified; the write-up names the target as damn.vulnerable.site.
- The identity lesson: a pipeline's deployment key acts for whoever can edit the pipeline, so repository access is effectively production access.
At a glance
| Organisations | Razz Security (research); no affected organisation identified |
|---|---|
| When | Published September 2024 |
| Attacker | None. A researcher's demonstration |
| Entry point | A publicly accessible .git directory whose .git/config held repository credentials |
| Identities abused | Repository credentials from .git/config; the pipeline's SSH deployment access to the production server |
| Impact | Demonstrated SSH access and full control of the target server; no real-world victim reported |
| Category | NHI. Incident class: researcher demonstration of a CI/CD attack chain (vulnerability, no confirmed breach) |
What happened
Technijian, summarising the report, wrote that the demonstration was "first exposed by Mukesh, the Chief Technology Officer (CTO) of Razz Security, who demonstrated how attackers can exploit CI/CD pipelines to gain full access to servers." The starting point was a misconfigured web server: "The issue stemmed from an exposed .git directory on a publicly accessible web server. This oversight exposed sensitive files, including .git/config , which contained user credentials and other sensitive information." With those credentials, an attacker could "clone the entire Git repository and gain access to not only source code but also deployment scripts, configuration files, and other critical data."
The repository used Bitbucket Pipelines to deploy to production. According to Technijian, "By manipulating this file, the attacker was able to inject their own SSH (Secure Shell) public key into the server's authorized_keys file." The command ran through the atlassian/ssh-run:0.2.8 pipe against the target server under the ubuntu user. "Once this modification was pushed to the master branch, the next pipeline run triggered the execution of the attacker's changes. This allowed the attacker to gain SSH access to the server using their own key, granting them full control." The report added that an attacker could then use privilege escalation flaws to obtain root access.
The same starting point has been exploited at scale by criminals. Sysdig reported that the EMERALDWHALE operation ran "a massive scanning campaign between August and September for servers that had exposed Git repository configuration files," then used the tokens it found to clone private repositories and extract more credentials. Pentera describes the same progression in general terms: attackers who get into a repository use leaked tokens for "Accessing CI/CD pipelines," and to persist they "Create new IAM users or SSH keys to stay embedded."
Timeline
| Date | Event |
|---|---|
| September 2024 | Razz Security publishes the CI/CD exploitation demonstration. |
| 10 September 2024 | Technijian publishes its summary of the report. |
| 30 October 2024 | Sysdig discloses EMERALDWHALE, a criminal campaign exploiting exposed Git configuration files. |
How it happened: the identity attack path
- Git directory exposed. A web server served its .git directory publicly.
- Repository credentials read. The .git/config file contained credentials for the remote repository.
- Repository cloned. The credentials gave access to source code and the Bitbucket Pipelines configuration.
- Pipeline poisoned. The researcher changed the pipeline to add their SSH key and pushed it to master.
- Server access. The pipeline's own deployment access installed the key, giving persistent SSH access.
Impact
- Demonstrated: SSH access to and full control of the target server, with a persistent backdoor key.
- Potential: privilege escalation to root and access to data on the server.
- Actual: no affected organisation or real-world misuse reported.
What this means for NHI governance
Two non-human identities make this chain work. The first is the repository credential stored in .git/config, which should never have been on a web server. The second is the pipeline's deployment identity: an SSH key with access to production that runs whatever the pipeline file says. Anyone who can change that file can borrow the key's power without ever seeing it. That is why repository write access to a deploying branch is equivalent to production access.
The defences are to keep credentials out of Git configuration, deploy build artefacts instead of working directories, protect deploying branches with reviews, and scope deployment keys to a single, restricted command where possible. See our CI/CD Pipeline Identity Security Guide and SSH Key Management Guide.
Recommendations
- Block .git paths on web servers. Deny access to dotfiles and test it from outside. See our Secrets Management Guide.
- Keep credentials out of Git remote URLs. Use a credential helper or short-lived tokens instead. See the NHI Authentication Guide.
- Protect deploying branches. Require reviewed pull requests before pipeline changes reach master. See the CI/CD Pipeline Identity Security Guide.
- Audit authorized_keys. Alert on new keys on production servers and remove unused ones. See the SSH Key Management Guide.
- Use separate, scoped keys per environment. A deployment key should not be able to change server access.
Frequently asked questions
Was this a real breach?
No victim was identified. It was a researcher's demonstration published by Razz Security; the write-up names the target as damn.vulnerable.site.
How can an exposed .git directory lead to server takeover?
The .git/config file can contain repository credentials. With them, an attacker can clone the code, edit a deployment pipeline and make it run commands on production servers.
Has this technique been used by real attackers?
Yes, the first step has. Sysdig reported in October 2024 that the EMERALDWHALE operation stole more than 15,000 cloud credentials from exposed Git configuration files.
Related NHI Mgmt Group resources
EmeraldWhale 2024 · Misconfigured Git Servers 2026 · Indian Government Breach 2021 · CI/CD Pipeline Identity Security Guide · SSH Key Management Guide
How NHI Mgmt Group can help
Pipelines carry the keys to production. We help teams find credentials in Git configuration, scope deployment keys and protect the branches that trigger them. See our NHI and AI agent security training.
References
- Technijian: Researcher Exploits CI/CD Pipelines to Take Full Server Control (summary of Razz Security's report) (10 September 2024)
- Sysdig: EMERALDWHALE: 15k Cloud credentials stolen in operation targeting exposed Git config files (30 October 2024)
- Pentera: Exposed Git Repos: The Overlooked Threat to DevOps Security (29 July 2025)