[arp242]

If being able to create files and symlinks to them is a pre-condition for this, then it's not a serious security bug. If you have that kind of access then there are a million nefarious things you can do.

This is almost becoming a joke at this point, "assuming an attacker has access to the system, they can change things on the system".

[empath75]

Helm is not intended to be able to write files outside of the directory you are rendering the templates to, and the directory that you have downloaded the chart to, so if there is a way to do that, it is a bug in the program and a security bug at that, particularly when the destination is controlled by someone who has written a malicious chart. That it also happens to be able to run arbitrary code makes it worse, but the primary problem is that it can write files outside of the chart directory or the directory you are rendering to at all.

This has nothing to do with whether you are running it in sudo or whatever. (and in fact on MacOs, I don't believe this requires running it with sudo permissions to overwrite ~/.zshrc for example)

[yokaze]

I create a malicious chart or compromise one you use (with symlink to an arbitrary file and code).

You download charts either as a tarball from a helm repo or oci registry with helm and helm will create the files and links with your permissions, and send me whatever I wanted to extract from your system.

Yes, you should check things you download from the internet. But also, that is not how a chart is supposed to work.

[JohnMakin]

As noted in other comments, a symlink is just a text reference to a file. It does not need to be created on the host system.

[stonemetal12]

It is on the level of "sudo curl URL". It is an obviously stupid thing to do from a security perspective, but projects have suggested doing it to install their software.

If you are new to helm or haven't considered the security around it, it is good to know what to look out for.