Source repositories with a confirmed supply chain risk: 61 of 814 (7.5%) (Source: Wiz Research (September 30, 2026))
A single command installs a monitoring stack or an ingress controller on Kubernetes. That command also installs the habits of strangers. How carefully they guard their release credentials, who can change their code, and what their projects depend on all travel with the software.
That is the idea behind new research from Wiz. The lesson here is that a package is only as trustworthy as the people behind it, and standard security tools are not built to give you a view of those people. They check what you write and what you build. They do not check the maintainer's workshop.
What Wiz Research examined
Wiz's researchers began with 1,500 widely used charts from Artifact Hub, a public home for community-maintained charts. Helm is the tool behind them. One install command brings an application and its supporting pieces into a Kubernetes cluster.
Charts often share the same code home. Once that overlap was removed, the list came down to 814 distinct repositories on GitHub.
Wiz did not audit the charts. It audited the upstream projects whose container images those charts install.
Two caveats apply. The sample covers popular charts on one registry, so it does not describe every chart. And the source does not say any of these weaknesses was exploited. It describes what an attacker could have done.
How the two flaws work
Wiz describes two patterns. Both findings below have been fixed.
The first is a dependency nobody owns. KubeView is an open source tool that maps the resources in a Kubernetes cluster. Its go.mod file, which lists the code libraries the project pulls in, named a Go module under a GitHub username that did not exist.
An attacker could have claimed that username and uploaded a booby-trapped version of the module. KubeView's builds would then have fetched it. After Wiz reported the problem, the tool's sole maintainer shipped version 2.2.1 without the dependency, within days.
The second is a build pipeline that trusts outsiders. The meilisearch-kubernetes repository holds the official Helm chart for the Meilisearch search engine. Its GitHub Actions workflow, an automated job, was triggered by any comment on an issue or pull request.
The job then fetched the commenter's own copy of the code, using a bot credential that could write to the repository. It also dropped the copy's branch name directly into a shell command. That flaw is called script injection, and a crafted branch name could therefore run commands.
The job never used GitHub's author association field, which marks whether someone is a maintainer or an outsider. Wiz says any GitHub user could have run commands with write access to the repository. Wiz places this kind of pattern under the label PWN Request, a term it applies when a pull request triggers the workflow. Wiz reports that Meilisearch's maintainers fixed it within days as well.
Why existing tools miss it
Wiz lists three blind spots. The first is ownership of the images. A chart installs images built and hosted elsewhere. They never enter your repositories, so code scanning of your own source has nothing to examine.
The second is that some risks carry no CVE, the public ID assigned to a known vulnerability. Image scanners hunt for known flaws. A username that anyone can register, or a workflow that runs a stranger's code, does not appear on their lists.
The third is image tags. Charts frequently name an image by tag rather than by a fixed digest, which is a unique fingerprint of the exact contents. A tag can be repointed. What you vetted last month may differ from what you download now.
What Wiz is selling, and how to read it
Wiz published this research alongside a product. WizOS Helm charts are rebuilt in Wiz's own pipeline, signed, and shipped with provenance records and a software bill of materials. Wiz says this leaves a compromised upstream workflow, like the Meilisearch one, with no path into what you deploy.
Wiz also promises a patch timetable, backed by an SLA. Critical CVEs are fixed within 7 days, and high and medium ones within 14. The clock starts once a stable upstream patch exists.
Treat those as vendor claims. The findings are Wiz's own and come from a vendor selling a fix. But the two examples are specific, and the maintainers fixed both. Whether a vendor-maintained catalog is the right answer depends on which charts you run and how much you trust one more party in the chain.
Questions to put to your team
Ask for a list of every Helm chart running in production, and who maintains each one. Ask which charts pull images by tag rather than by digest.
Ask whether anyone checks if an upstream project is archived or unmaintained. Wiz found 25 such charts in its sample. Ask who owns the decision to replace one.
Ask which charts sit on privileged parts of the cluster. KubeView, for example, needs visibility across the whole cluster to do its job.
Finally, ask whether your supply chain reviews stop at your own repositories. If they do, the trust in every helm install is unexamined.
A chart can look clean while the project behind it is not. That is the gap worth closing first.
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: Wiz.
