Is the vulnerability that you ship a chart with `Chart.lock -> ../.bashrc`, and then helm writes to `Chart.lock`?

Why is the fix specific to Chart.lock (https://github.com/helm/helm/commit/76fdba4c8c2a4829a6b7abb4...), wouldn't the fix be instead that "A chart cannot contain any symlinks outside of its root"?

This is not the first RCE involving YAML and it won't be the last.

https://tytel.org/helm/

1. Attacker crafts a malicious Chart.yaml containing arbitrary code

2. Replaces Chart.lock with a symlink pointing to a sensitive file (like .bashrc or other startup scripts)

3. When you run helm dependency update, Helm processes the malicious Chart.yaml and writes the payload to whatever file the symlink targets

4. Code executes when the targeted file is next used (e.g., opening a new shell)

Why This Works: Helm follows the symlink during the dependency update process without validating the target, allowing arbitrary file writes outside the intended chart directory.

- You have access to my file system

- You have access to the helm repository

You place malicious binaries outside the helm directory. Helm will now execute malicious code through the helm chart pointing outside the helm directory.

Don't I have already bigger problems if you have access to my file system to place there malicious code?

Is the danger here that one can get an execute permission? But if you can manipulate my helm chart why can you not also place the malicious code in the helm directory?

Allowing LLMs to generate charts and what not via shell execution is a bad idea.

Fortunately, my dotfiles are managed with nix so trying to write to those files on a read only partition will raise many red flags for me.

I don't use bash, but maybe should write a dummy .bashrc (and other start up script equivalents for fish) as some sort of canary.

If I happen to overlook the malicious shell script crafted in a dependency on helm chart, I would get nasty errors that a process was trying to write to a read only file.

Sorry, just can't really recover from trauma of counting spaces and messing up newlines, etc. when writing Helm templates. You know, Lisp "sucks" because "you need to count parenthesis" (you actually don't), yet Helm is a widely accepted technology where you need to count spaces for (n)indent ;)