Argo CD 3.5 adds internal mTLS, Git commit verification and an ApplicationSet UI

Argo CD 3.5 arrives with a security focus

Argo CD, the GitOps controller that a dev.to overview says is deployed in nearly 60 percent of Kubernetes clusters, shipped version 3.5 in August 2026. According to dev.to, the release closes two long-standing security gaps — unauthenticated internal traffic and blind trust in whatever sits on a branch — while adding a native interface for ApplicationSets. A release candidate for version 3.6 followed in September 2026, which the article reads as a sign that development pace is increasing.

Internal mTLS encrypts component traffic

Until now, communication between the repo-server and the rest of the control plane — the API server, the Application Controller and the ApplicationSet Controller — ran without encryption or authentication. As dev.to reports, this became a concrete problem in July 2026, when a published exploit showed that an unauthenticated attacker could reach the repo-server, abuse a Kustomize option to execute arbitrary commands, read the Redis password from an environment variable and manipulate cached deployment data. The article notes that the underlying bug had been reported to the maintainers 18 months before disclosure.

With version 3.5, the repo-server requires a valid client certificate from every component that connects. Operators can supply their own certificates; if they do not, the repo-server generates self-signed ones in memory, so no filesystem access is required. The feature is additive, meaning existing installations fall back to automatic certificates without reconfiguration. Dev.to stresses that mTLS does not replace NetworkPolicies but supplements them as a second defensive layer, covering cases where network isolation is incomplete or an attacker has already moved laterally into the same namespace.

Signed commits as a deployment gate

The second headline feature, called Source Integrity, verifies Git commit signatures before synchronization. Previously, Argo CD treated any commit present on the configured branch as deployable, regardless of who pushed it or whether it had been tampered with afterwards. Operators can now set sourceIntegrity.required: true in an Application spec, or use the argocd app set --source-integrity-required CLI flag, and commits without a valid signature are excluded from syncing.

According to dev.to, this targets realistic failure modes such as a leaked GitHub personal access token, a compromised developer laptop or a force push during an incident — situations where a commit looks legitimate on the branch. The feature reframes the deployment decision around a single question: was this specific commit signed by a key authorized to approve production changes. The older GPG verification path is now deprecated and will be removed in the next major version.

A native UI for ApplicationSets

ApplicationSets let teams template the same application across multiple clusters or environments, but they previously had no representation in the web interface; administrators had to read YAML or use kubectl to see which concrete applications a template would generate. Version 3.5 introduces an ApplicationSet UI — built with contributions from engineers at Intuit, Red Hat, GoTo and Octopus Deploy, per dev.to — offering a list view, filtering and detail views, plus a Preview Apps tab that shows which applications a template will generate before anything is deployed. The preview in particular reduces the risk of misconfiguration when scaling to more clusters.

Other changes in this release

The release also carries a set of smaller items: impersonation in beta, letting Argo CD assume a specific user identity for server-side tasks and improving audit trails in multi-tenant clusters; the Source Hydrator reaching beta, separating dry source templates from rendered manifests across different repositories; Helm 4 support alongside Helm 3 compatibility; the ability to deploy ApplicationSets in any namespace rather than only the Argo CD namespace; concurrency controls that limit how many applications are processed at once to protect against cluster overload; and Azure Active Directory improvements covering group-claims overflow via the Microsoft Graph API and service principal authentication for Azure DevOps.

Why it matters

Given Argo CD's position in the Kubernetes ecosystem, weaknesses in its internal trust model are systemic rather than local, and the July 2026 exploit demonstrated how little an attacker needed to reach command execution and data manipulation. Internal mTLS raises that bar with minimal migration effort, and commit signing extends the core GitOps promise — that production reflects exactly what was approved — from branch state to cryptographic identity. Both features can be adopted incrementally, per application or component by component, which lowers the cost of tightening a running pipeline. The new ApplicationSet UI, meanwhile, makes multi-cluster GitOps legible to teams without deep YAML expertise, which matters as adoption spreads beyond platform specialists.