Build1 publisher2 min readPublished
Argo CD 3.5 makes its repo-server demand a client certificate from every internal caller
Argo CD 3.5 puts mutual TLS in front of its repo-server by default, closing the unauthenticated path a July 2026 Kustomize flaw used to run commands. Clusters without their own certificates get it on upgrade, so older GitOps installs should take 3.5 as a security patch.
The Engineer · Build desk
What happened
- Before 3.5, traffic between the repo-server and the API server, Application Controller and ApplicationSet Controller was neither encrypted nor authenticated.
- The July flaw also let an attacker read the Redis password from an environment variable and alter cached deployment data.
- The bug had been reported to Argo CD's maintainers 18 months before it was disclosed.
- Version 3.5 also adds Source Integrity, which lets operators keep commits without a valid signature out of synchronization.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Holding pre-3.5 clusters for the 3.6 release leaves their repo-servers open to anonymous callers in the interim, so the 3.5 upgrade should not wait on the next version.
- exposure Clusters still on pre-3.5 releases will not show up in scanners that match versions against CVE feeds, because the flaw has no CVE identifier to match.
- cost Teams that verify commits with the older GPG mechanism now owe a migration to Source Integrity before the next major version removes GPG support.
According to a write-up on dev.to, the repo-server in 3.5 requires a valid client certificate from every component that connects to it [8]. Operators can supply their own certificates [9]. If they do not, the repo-server generates self-signed ones in memory and does not need full filesystem access to do it [9].
I think the in-memory fallback is the best decision in the release. A transport control that depends on a certificate rollout tends to protect nothing until someone schedules the rollout.
The bug reached the maintainers around January 2025, counting back from the July 2026 disclosure [1]. Version 3.5 went GA in August 2026, about a month after that disclosure [2]. For roughly a year and a half after the report, the only credential the repo-server asked for was a network route to it [4] [1].
The write-up is explicit that mTLS supplements NetworkPolicies and does not replace them [11]. The Helm chart ships NetworkPolicies that protect the repo-server at the network level once they are activated [11]. mTLS covers the case where that isolation is incomplete, or where an attacker moves laterally from another pod in the same namespace [12].
The write-up does not say whether the Kustomize option itself was restricted in 3.5 [5]. Certificates decide which components may connect [8]. Under the new scheme the API server and both controllers present valid certificates, so an attacker who compromises one of them arrives on the permitted side of the check [3].
Source Integrity is the opt-in half of the security work [13]. Before 3.5, Argo CD deployed whatever commit sat on the configured branch, regardless of who pushed it or whether it was tampered with afterwards [15]. The check turns on with `sourceIntegrity.required: true` in the Application spec, or with `argocd app set --source-integrity-required` [14]. The write-up's cases are a leaked GitHub personal access token, a compromised developer laptop and a force push during an incident, where the commit on the branch looks legitimate [16].
What to watch
- Whether the Argo CD project's own release notes or an advisory confirm that the Kustomize option was restricted, beyond the new mTLS requirement.
- Documentation on how the API server and controllers obtain client certificates when the repo-server falls back to in-memory self-signed certificates.
- Whether a CVE is assigned to the July 2026 flaw, so version scanners can flag pre-3.5 clusters.