Уязвимость функций LoadIndexFile() и DownloadIndexFile() пакета repo и функции LoadDir() пакета plugin пакетного менеджера для Kubernetes Helm, позволяющая нарушителю вызвать отказ в обслуживании

Уязвимость пакетного менеджера для Kubernetes Helm, связанная с неверным ограничением имени пути к каталогу с ограниченным доступом, позволяющая нарушителю сохранить диаграмму Helm Chart за пределами ожидаемого каталога

Helm is a tool for managing Charts. Charts are packages of pre-configured Kubernetes resources. When either the Helm client or SDK is used to save a chart whose name within the `Chart.yaml` file includes a relative path change, the chart would be saved outside its expected directory based on the changes in the relative path. The validation and linting did not detect the path changes in the name. This issue has been resolved in Helm v3.14.1. Users unable to upgrade should check all charts used by Helm for path changes in their name as found in the `Chart.yaml` file. This includes dependencies.

Helm is a package manager for Charts for Kubernetes. Versions prior to 3.14.2 contain an uninitialized variable vulnerability when Helm parses index and plugin yaml files missing expected content. When either an `index.yaml` file or a plugins `plugin.yaml` file were missing all metadata a panic would occur in Helm. In the Helm SDK, this is found when using the `LoadIndexFile` or `DownloadIndexFile` functions in the `repo` package or the `LoadDir` function in the `plugin` package. For the Helm client this impacts functions around adding a repository and all Helm functions if a malicious plugin is added as Helm inspects all known plugins on each invocation. This issue has been resolved in Helm v3.14.2. If a malicious plugin has been added which is causing all Helm client commands to panic, the malicious plugin can be manually removed from the filesystem. If using Helm SDK versions prior to 3.14.2, calls to affected functions can use `recover` to catch the panic.

Просьба обновить версию Helm до последней

A flaw was found in mupdf 1.18.0. Double free of object during linearization may lead to memory corruption and other potential consequences.

MuPDF through 1.18.1 has an out-of-bounds write because the cached color converter does not properly consider the maximum key size of a hash table. This can, for example, be seen with crafted "mutool draw" input.

A Floating point exception (division-by-zero) flaw was found in Mupdf for zero width pages in muraster.c. It is fixed in Mupdf-1.20.0-rc1 upstream.