GPU VulnDB

Database/Control plane, storage & DevOps

Atlantis: shell metacharacters in a pull request workspace name run commands as the Atlantis service account

CVSS 8.8CVE-2026-116676Control plane, storage & DevOpscurated

Impact

Atlantis joins Terraform arguments into a single string and runs them through sh -c, so the workspace value taken from a pull request's atlantis.yaml is interpreted by the shell. Any contributor whose pull request is eligible for a plan gets command execution as the Atlantis service account - no custom workflow, no apply permission, no malicious provider needed. On a fleet where Atlantis holds the credentials that build the cluster, that account is usually the most privileged thing in the control plane: cloud provider keys, Terraform state, and version-control tokens are all in its environment, which is enough to re-provision nodes, change network and IAM policy, or read state containing secrets. Fork pull requests reach it only when --allow-fork-prs is set; branches in the same repository do not need that option.

Who can reach it

Any authenticated user who can open a pull request that Atlantis will plan - typically anyone with write access to the repository, or any external contributor if --allow-fork-prs is enabled. Network access to Atlantis itself is not required; the webhook carries the payload.

What to do

Upgrade Atlantis to 0.47.1 and restart the service - a single daemon restart, no node impact, and in-flight plans can be re-run from the pull request. Until then, disable --allow-fork-prs, tighten who can push branches to repositories Atlantis watches, and treat the credentials in the Atlantis environment as exposed: rotate cloud and VCS tokens if untrusted pull requests were planned on an affected version.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.