The post has been translated automatically. Original language: Russian
On September 28, 2026, the Kubernetes security team published a vulnerability notice CVE-2026-19444 in the kubectl client. The contents of the container can write files to arbitrary paths on the local machine when executing the kubectl cp command. Only Windows clients are affected, the CVSS score is 6.5, the level is "average".
How does copying work and where does the defect occur?
kubectl cp does not have its own file transfer protocol. When copying from a container, the client runs a regular tar inside this container, takes the archive stream from the standard output and decompresses it already at home. It turns out that the contents of the archive are entirely determined by the remote party, and the client accepts this content.
That's where the problem lies. According to the description of the notification, a substituted tar in the container can return such a stream that when unpacked, the files will end up not in the target directory, but in an arbitrary location of the client's file system. There is exactly one restriction left — the rights of the local user who launched kubectl. For an engineer who works under an account with the right to write to his profile and tool catalogs, this means the ability to put the file where it will later be read or run from.
There are two noticeable limitations in the CVSS vector given in the notification: high privileges are required and human participation is mandatory. The attack does not happen by itself — it is necessary that the engineer himself causes copying from a container whose contents he does not trust. At the same time, the impact on data integrity is assessed as high, and the area of impact is marked as changed: it is not the cluster that suffers, but the operator's work machine.
Who is affected and what is being closed
kubectl versions 1.34.0 to 1.34.11, 1.35.0 to 1.35.8, and 1.36.0 to 1.36.4 were declared vulnerable. Fixes were released in 1.34.12, 1.35.9, and 1.36.5, meaning three current lines are supported at once. Clients running Linux and macOS, as explicitly stated in the notification, are not affected: the defect appears only on Windows.
You can check your version using the kubectl version command with the client-only output flag. Until the update is rolled out, the notification advises the only measure: do not use kubectl cp to download files from containers whose contents you do not fully control.
I found the problem with Moriel Harush, and the fix was prepared by Marly Salazar, Maciej Szulik, and Vyom Yadav.
What does this mean in practice?
The good news is that you only need to update the client. The server part of the cluster does not need to be touched, there is no downtime, there is no need for a maintenance window — it is the replacement of a single executable file on workstations and agents.
The bad news is that it is the client updates in the teams that are most often lost. kubectl is installed in different ways - manually in an arbitrary directory, through Windows package managers, as part of images for assembly agents, along with utilities from cloud providers. There is usually no centralized update for such a placer, so it is useful to go through the entire list of places where the binary can be located at all, and not just the main one. Separately, it is worth remembering about the assembly agents for Windows: they are the same kubectl clients, and copying commands in pipelines are executed without a person behind the monitor.
The second conclusion is broader than the correction itself. If the tool unpacks an archive that came from an untrusted source, checking the names of records inside the archive is a mandatory step, and making an error in it is expensive. To collect artifacts from the pods, it is more reasonable not to extract them by unpacking to your machine, but to give them through a volume, object storage, or pre-prepared export. If copying is still necessary, it is worth performing it in a separate empty directory and under an account with minimal rights — then even an error in parsing paths will rest on the file system rights.
The draft text was prepared with the participation of AI, the facts were checked against the original source — the official security notice of the Kubernetes project
28 сентября 2026 года команда безопасности Kubernetes опубликовала уведомление об уязвимости CVE-2026-19444 в клиенте kubectl. Содержимое контейнера может записать файлы в произвольные пути на локальной машине в момент выполнения команды kubectl cp. Затронуты только клиенты под Windows, оценка по CVSS — 6.5, уровень «средний».
Как устроено копирование и где возникает дефект
У kubectl cp нет собственного протокола передачи файлов. При копировании из контейнера клиент запускает внутри этого контейнера штатный tar, забирает поток архива из стандартного вывода и распаковывает его уже у себя. Получается, что содержимое архива целиком определяет удалённая сторона, а клиент это содержимое принимает.
Именно здесь и проблема. По описанию уведомления, подменённый tar в контейнере может вернуть такой поток, что при распаковке файлы окажутся не в целевом каталоге, а в произвольном месте файловой системы клиента. Ограничение остаётся ровно одно — права локального пользователя, который запустил kubectl. Для инженера, работающего под учётной записью с правом записи в свой профиль и в каталоги инструментов, это означает возможность подложить файл туда, откуда он позже будет прочитан или запущен.
В векторе CVSS, приведённом в уведомлении, заметны два ограничителя: требуются высокие привилегии и обязательно участие человека. Атака не происходит сама собой — нужно, чтобы инженер сам вызвал копирование из контейнера, содержимому которого он не доверяет. При этом влияние на целостность данных оценено как высокое, а область воздействия помечена как изменённая: страдает не кластер, а рабочая машина оператора.
Кто затронут и чем закрывается
Уязвимыми объявлены kubectl версий с 1.34.0 по 1.34.11, с 1.35.0 по 1.35.8 и с 1.36.0 по 1.36.4. Исправления вышли в 1.34.12, 1.35.9 и 1.36.5 — то есть поддерживаются сразу три актуальные линии. Клиенты под Linux и macOS, как прямо сказано в уведомлении, не затронуты: дефект проявляется только на Windows.
Проверить свою версию предлагается командой kubectl version с флагом вывода только клиентской части. Пока обновление не раскатано, уведомление советует единственную меру: не использовать kubectl cp для выгрузки файлов из контейнеров, содержимое которых вы не контролируете полностью.
Нашёл проблему Moriel Harush, исправление подготовили Marly Salazar, Maciej Szulik и Vyom Yadav.
Что это значит на практике
Хорошая новость: обновлять нужно только клиент. Серверную часть кластера трогать не требуется, простоя нет, окно обслуживания не нужно — это замена одного исполняемого файла на рабочих станциях и агентах.
Плохая новость: именно клиентские обновления в командах чаще всего и теряются. kubectl ставят по-разному — вручную в произвольный каталог, через пакетные менеджеры Windows, в составе образов для сборочных агентов, вместе с утилитами облачных провайдеров. Централизованного обновления у такой россыпи обычно нет, поэтому полезно пройти по всему списку мест, где бинарник вообще может лежать, а не только по основному. Отдельно стоит вспомнить про сборочные агенты под Windows: они такие же клиенты kubectl, и команды копирования в пайплайнах выполняются без человека за монитором.
Второй вывод шире самого исправления. Если инструмент распаковывает архив, пришедший из недоверенного источника, проверка имён записей внутри архива — обязательный этап, и ошибка в ней стоит дорого. Для сбора артефактов из подов разумнее не вытягивать их распаковкой на свою машину, а отдавать через том, объектное хранилище или заранее подготовленный экспорт. Если копирование всё же нужно, стоит выполнять его в отдельный пустой каталог и под учётной записью с минимальными правами — тогда даже ошибка в разборе путей упрётся в права файловой системы.
Черновик текста подготовлен с участием ИИ, факты сверены с первоисточником — официальное уведомление безопасности проекта Kubernetes
Share
