GHSA-gppm-hq3p-h4rp
Git credentials are exposed in Atlantis logs
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/runatlantis/atlantisReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Short summary of the problem. Make the impact and severity as clear as possible. For example: An unsafe deserialization vulnerability allows any unauthenticated user to execute arbitrary code on the server.
Atlantis logs contains GitHub credentials (tokens ghs_...) when they are rotated. This enables an attacker able to read these logs to impersonate Atlantis application and to perform actions on GitHub.
When Atlantis is used to administer a GitHub organization, this enables getting administration privileges on the organization.
This was reported in https://github.com/runatlantis/atlantis/issues/4060 and fixed in https://github.com/runatlantis/atlantis/pull/4667 . The fix was included in Atlantis v0.30.0.
Details
Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.
While auditing the Kubernetes/Argo CD/Atlantis deployment of some company, the following set-up was encountered:
- Most employees have read-only access to Argo CD, enabling them to see the health of deployed applications.
- Atlantis was deployed as an Argo CD application.
- Atlantis was used to manage the configuration of a GitHub organization (such as team members), using Terraform's GitHub integration.
Atlantis logs on Argo CD contained lines such as:
{"level":"debug","ts":"2024-11-07T17:58:30.636Z","caller":"vcs/gh_app_creds_rotator.go:58","msg":"Refreshing git tokens for Github App","json":{}}
{"level":"debug","ts":"2024-11-07T17:58:30.637Z","caller":"vcs/gh_app_creds_rotator.go:64","msg":"token ghs_[REDACTED]","json":{}}
{"level":"debug","ts":"2024-11-07T17:58:30.637Z","caller":"vcs/git_cred_writer.go:36","msg":"git credentials file has expected contents, not modifying","json":{}}
This enabled employees with read-only access to Argo CD to get administration privileges on the GitHub organization, compromising all repositories. As some repositories were used for Infrastructure-as-Code deployment (with Atlantis), this enabled the security auditors to get cluster admin privileges on most Kubernetes clusters.
While the set-up "most employees have read-only access to Argo CD" can be seen as dangerous, this should not incur such security risk (cf. https://argo-cd.readthedocs.io/en/stable/operator-manual/security/). The main issue here was that the logs contained privileged GitHub tokens as they were obtained by Atlantis.
This issue was already reported (https://github.com/runatlantis/atlantis/issues/4060) and fixed (https://github.com/runatlantis/atlantis/pull/4667) but no security advisory was published on https://github.com/runatlantis/atlantis/security and no CVE was assigned (https://app.opencve.io/cve/?&vendor=runatlantis&product=atlantis only lists CVE-2022-24912, which is unrelated).
Could you please publish a security advisory?
PoC
Complete instructions, including specific configuration details, to reproduce the vulnerability.
cf. https://github.com/runatlantis/atlantis/issues/4060 for more details.
Impact
What kind of vulnerability is it? Who is impacted?
- This leaks sensitive GitHub tokens in the log files (CWE-532: Insertion of Sensitive Information into Log File).
- This could enable anyone with log read access to compromiseGitHub organizations managed by Atlantis.
- This impact at least users using Atlantis with Github application and integration.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/runatlantis/atlantis | all versions | 0.30.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/runatlantis/atlantis. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/runatlantis/atlantis to 0.30.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gppm-hq3p-h4rp is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-gppm-hq3p-h4rp is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-gppm-hq3p-h4rp. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-gppm-hq3p-h4rp in your dependencies?
O3 detects GHSA-gppm-hq3p-h4rp across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.