Yes, if you let pull requests from untrusted authors drive an ApplicationSet. Argo CD deploys what Git describes. Its pull request generator creates an Application per open pull request, so whoever can open a pull request can influence your cluster unless projects, filters and repository rules limit them.
What does Argo CD actually do with pull requests?
Argo CD is a deployment tool, not a build system. The pull request generator queries the source control provider's API for open pull requests and creates an Application for each match, polling every 30 minutes by default unless a webhook triggers it sooner. Templates can use fields such as the pull request number, branch, head SHA and author.
A poisoned build is the CI half of the story, covered in our GitHub Actions post. This post covers the deployment half: what happens when a preview Application points at a branch an outsider controls.
What do the Argo CD docs warn about?
The ApplicationSet security page makes four points worth quoting in spirit:
- Only admins should create, update or delete ApplicationSets, because they can create Applications under arbitrary projects, create many quickly, and in some cases read privileged data.
- Even if non-admins cannot create ApplicationSets, they may influence behavior through the source of truth. A user with push access to a git generator's repository could generate an excessive number of Applications and strain the controllers and the provider's rate limits.
- If the project field is templated, admins must control every source of truth for the generators. Someone who can create an Application under an unrestricted project, such as the default, could take control of Argo CD itself, for example by modifying its RBAC ConfigMap.
- The pull request generator page repeats it: if the project is templated, only admins should be able to create pull requests.
The generator page also notes that with no filters, all pull requests are processed, and that it does not discuss untrusted authors such as fork contributors.
How permissive is the default project?
The projects guide says an application with no project belongs to the default project, which permits deployments from any source repository, to any cluster, and of all resource kinds. It recommends dedicated projects with explicit source, destination and resource permissions. It also shows how to strip all permissions from the default project so any application using it is denied until moved.
Constructed example
A team uses the pull request generator for per-PR preview namespaces. The ApplicationSet hard-codes a project called previews, restricted to the team's repository, one cluster and one namespace pattern, and denies cluster-scoped resources. A filter limits generation to pull requests carrying a label that a maintainer applies after review. A contributor from outside the team opens a pull request that adds a manifest granting cluster-admin. The label is missing, so no Application exists. Even if it did, the project would reject the cluster-scoped resource.
What to do
- Create a dedicated project for previews with an explicit source repository, destination and namespace pattern, and no cluster-scoped kinds.
- Hard-code the project in the ApplicationSet template. Do not template it.
- Use label or branch filters so only reviewed pull requests generate Applications.
- Restrict who can open pull requests against the deployment repository, and require review before previews build.
- Remove permissions from the default project.
- Limit ApplicationSet creation to admins through Kubernetes RBAC.
- Give the generator's token the narrowest access, such as a GitHub App scoped to one repository.
- Cap preview count and lifetime to limit resource abuse.
Safeguard's pull request gate and dependency scanning can check what a pull request changes before it merges. Cluster-side controls such as projects remain Argo CD settings.
Quick check
What happens if I set no filters on the pull request generator?
Per the Argo CD docs, all pull requests are processed, so every open pull request gets an Application.
Why is the default project risky?
It permits any source repository, any cluster and all resource kinds by default. Moving previews to a restricted project limits what a poisoned pull request can deploy.
Sources
Last reviewed: 18 October 2026.
