- Synacktiv found that Helm templates which insert values without escaping can let a user add new Kubernetes objects, even when only the values file is editable.
- The risk applies to unescaped templates. Helm 4 raises the effort but, in Synacktiv's test, did not stop the injection.
- Ask whether templates quote and validate values, whether ArgoCD projects limit resource types, and whether admission policies back both up.
Some platform teams assume they have closed a gap. Developers may edit only the settings of an approved deployment chart, so only approved resources should ship. Synacktiv, a security firm, shows where that logic breaks. When a template drops a setting into place without escaping it, the settings file can start writing the manifest itself. This applies to templates that insert values unescaped. It does not describe every chart.
What Synacktiv found
Synacktiv's team hit the problem during an audit of a Kubernetes cluster. The cluster ran Helm, which fills in templates to produce Kubernetes configuration. It also ran ArgoCD, which syncs a Git repository to the cluster. The flaw sat in a Helm template that ArgoCD applied.
The researchers were surprised by how little guidance exists on this. Helm's own documentation presents quoting strings as a best practice. It gives no security warning. It also covers escaping only after many examples that are injectable.
Why a values-only rule is not enough
The usual reasoning is simple. Developers touch only values, so the output stays safe. Synacktiv says this holds only if the template escapes or validates each value. Where it does not, the assumption fails.
Compare SQL injection. Data pasted into a command starts acting as part of the command. Here, a value pasted into a template can carry structure of its own.
How the injection works
Helm fills a template with entries from a file called values.yaml. Before applying the result, it checks that the output is well-formed YAML. It does not check that the output is a valid Kubernetes manifest. That gap makes the trick possible.
YAML lets a value run over several lines, using a pipe character. A multi-line value can add fields to an existing object. Synacktiv's example adds a field called injectedAttribute.
There is one snag. That style leaves a newline at the end, which can spoil an injection inside a string. The |- variant drops the newline. This lets the value work inside strings too.
Extra fields can let commands run or change a Pod's security context. Synacktiv says this can make a container escape easy. YAML also allows several objects in one file, split by three dashes. The team used this to add a new Namespace and an nginx Pod. They confirmed with kubectl that both existed.
In Synacktiv's assessment, an attacker with these powers can probably take over the cluster, though the outcome turns on how it is set up. One route is creating roles and their bindings. Another is a privileged Pod in a new namespace, which sidesteps Pod Security Admission settings.
What Helm 4 changes, and what it does not
Helm 4 was released in November 2025. It turns on Server-Side Apply by default. That hands validation to the Kubernetes API server. Helm 3 ignored attributes it did not recognise. Helm 4 does not deploy invalid resources by default.
That raises the effort. It did not stop Synacktiv. An attacker can use only valid attributes. Or the attacker can add a throwaway resource to soak up the leftover content. In the test, the Namespace and nginx Pod were created. The throwaway Pod was rejected.
Three layers of defence
First, fix the template. Quote string values. Use the printf function to join strings before quoting. Convert numbers with the int or float64 functions. A value that is not a number becomes 0. A schema file named values.schema.json can check the structure and types of values. A bad injection then produces an error.
Second, limit what ArgoCD may create. The clusterResourceWhitelist field in an AppProject can allow, for example, only Deployments. The injected Namespace and Pod would then break the rules. Synacktiv also suggests running ArgoCD with namespace-level permissions. The standard install needs cluster-wide roles that most often grant cluster admin rights.
Third, add a check at the cluster door. A Validating Admission Policy can refuse privileged Pods in a given namespace. It works whether the cause was a mistake or an injection.
What leaders should ask
Put three plain questions to your platform team. Do our charts quote and validate every value a developer can set? Does each ArgoCD project list only the resource types it needs? Does the cluster itself refuse privileged Pods, whatever ArgoCD sends?
Also ask who can push to repositories that ArgoCD applies directly. Synacktiv notes that anyone with push rights there can deploy arbitrary resources. Limiting people to values helps, but only when the templates hold up.
Synacktiv closes with a point about responsibility. The burden should not fall only on users. Tools in the CI/CD ecosystem should offer clear documentation, secure defaults and explicit guidance. Until then, a pipeline that holds credentials and reaches production deserves the scrutiny given to an admin console. A safe-looking settings file is a boundary only after someone has tested it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Synacktiv.
