CISA добавила CVE-2026-45321 в каталог Known Exploited Vulnerabilities для TanStack, и важная деталь здесь не похожа на обычное описание бага в приложении. Запись указывает на сбой в цепочке поставки: вредоносные версии были опубликованы в npm под доверенной личностью и использовались для распространения malware, крадущего учетные данные.
Для команд, которые используют пакеты TanStack, это меняет приоритет привычной гигиены зависимостей. Вопрос теперь не только в том, «используем ли мы уязвимую версию?». Нужно также понять: «успели ли наш build, lockfile, cache, машина разработчика или CI когда-либо скачать вредоносный пакет, пока он был доступен?»
Что изменилось в CISA KEV#
Каталог Known Exploited Vulnerabilities от CISA — не общий поток уязвимостей. Попадание в него означает, что CISA оценила уязвимость как уже эксплуатируемую. Для гражданских федеральных органов исполнительной власти США записи KEV запускают обязательства по устранению согласно Binding Operational Directive 22-01. Для остальных KEV все равно полезен как сигнал приоритизации.
В списке указана CVE-2026-45321. CISA называет затронутым продуктом TanStack от TanStack, а тип уязвимости — unspecified. Практический эффект в записи понятнее, чем техническая первопричина: слабость позволила публиковать вредоносные версии продукта в реестре npm, где они могли распространять malware для кражи учетных данных под доверенной личностью.
Требуемое действие у CISA сформулировано широко: применить меры по инструкциям вендора, следовать применимым указаниям BOD 22-01 для cloud services или прекратить использование продукта, если mitigations недоступны. Срок, указанный CISA, — 2026-06-10.
Эта формулировка важна. Она не дает защитникам аккуратный exploit primitive, диапазон затронутых версий или однострочную настройку для исправления. Она задает задачу containment. В response нужно включить происхождение пакетов, разрешение зависимостей, учетные данные разработчиков и CI secrets.
Почему эта CVE важна для security operations#
TanStack находится в JavaScript-экосистеме, где npm-пакеты часто напрямую попадают в build pipelines. Вредоносному пакету не нужно ломать production, чтобы навредить. В зависимости от поведения пакета и окружения он может выполниться во время install, build, test или локальной разработки.
Риск для privacy тоже прямой. В описании CISA говорится о malware, крадущем учетные данные. Значит, ближайшая проблема — не только компрометация приложения. Возможна утечка tokens, npm credentials, GitHub tokens, cloud keys, CI variables, локальных секретов разработчиков и других данных, которые превращают один инцидент с пакетом в более широкий доступ.
Здесь exploitability выглядит иначе, чем в обычной server-side CVE. Для web RCE часто спрашивают, доступен ли exposed service. При компрометации пакета вопрос другой: потребляла ли доверенная automation плохой artifact. Blast radius идет по dependency graph и модели работы с секретами, а не только по internet-facing assets.
Операционный приоритет должен быть выше для команд, которые:
- используют пакеты TanStack в активных проектах;
- разрешают автоматические обновления зависимостей без строгого review;
- запускают npm install или build steps в CI при доступности широкого набора secrets;
- полагаются на floating ranges, а не на зафиксированные версии зависимостей;
- плохо видят, какие версии пакетов были установлены и когда;
- переиспользуют developer tokens между локальными, CI и production-adjacent systems.
Это также напоминание: open source security — не только code review. Registry, publisher identity, release process, maintainer credentials, package signing, lockfiles и build logs становятся security controls. Если эти controls неформальны, response превращается в догадки.
Связанный контекст: GigaTap уже писал, почему security artifacts должны быть рабочими инструментами, а не декорацией, в материале OpenSSF’s April signal: make security artifacts operational: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
Что проверить перед действиями#
Начните с инвентаризации. Определите, зависят ли ваши repositories, build systems, templates, internal packages или developer tooling от пакетов TanStack. Не ограничивайтесь production apps. Frontend tooling, prototypes, internal dashboards и заброшенные repos тоже могут раскрыть учетные данные во время install или build.
Затем подтвердите, что реально запускалось. Lockfiles и package manager logs полезнее, чем намерение в package.json. Проверьте npm, pnpm или yarn lockfiles, CI logs, artifact metadata, dependency caches и build images. Если окружение сохраняет историю скачивания пакетов, используйте ее.
Практические проверки:
- Найдите зависимости TanStack в repositories и lockfiles.
- Сравните установленные версии пакетов с vendor guidance, когда она доступна.
- Просмотрите CI job logs вокруг установки зависимостей и build steps.
- Проверьте, были ли разрешены install scripts.
- Определите, какие secrets были доступны jobs, устанавливавшим зависимости.
- Ротируйте учетные данные, которые могли быть доступны затронутым install или build environments.
- Проверьте npm tokens, GitHub tokens, cloud keys, deployment keys и CI variables на подозрительное использование.
- Очистите или пересоберите dependency caches, если вредоносные artifacts могли там сохраниться.
- Закрепите known-good versions там, где vendor guidance поддерживает такое действие.
- Отключите или ограничьте автоматические обновления зависимостей, пока путь инцидента не понятен.
Ротация учетных данных должна быть scoped, но не робкой. Если CI job имел доступ к deploy credentials во время установки скомпрометированного пакета, считайте эти credentials раскрытыми, пока evidence не покажет обратное. Если машина разработчика скачала вредоносный пакет при наличии sensitive tokens, включите этот endpoint и его token set в investigation.
Patching остается необходимым, но его может быть недостаточно. При supply-chain malware переход на безопасную версию пакета останавливает будущую экспозицию. Он не отменяет уже украденные secrets. Security operations должны отслеживать обе стороны: package remediation и credential response.
Чего не стоит утверждать слишком уверенно#
Запись CISA называет уязвимость unspecified. Это оставляет важные пробелы. Публичный текст KEV сам по себе не устанавливает полный диапазон затронутых версий, точную timeline эксплуатации, число вредоносных пакетов, поведение malware или факт компрометации конкретной организации.
Не превращайте «TanStack есть в lockfile» в доказательство кражи учетных данных. Но и не отмахивайтесь от проблемы только потому, что production systems продолжают работать. Supply-chain malware может выполнить свою задачу еще до запуска приложения.
Более сильное и полезное утверждение уже: CISA рассматривает CVE-2026-45321 как known exploited, а описание указывает на вредоносную публикацию в npm под доверенной личностью с целью кражи учетных данных. Этого достаточно, чтобы срочно провести операционные проверки в окружениях, где используется TanStack.
Практический вывод#
Для команд, использующих TanStack, это KEV-driven supply-chain response, а не обычное обновление зависимости. Найдите экспозицию, проверьте, какие пакеты были установлены, следуйте vendor mitigation instructions и ротируйте secrets, которые присутствовали в затронутых build или developer environments.
Если mitigations недоступны, требуемое действие CISA прямо включает прекращение использования продукта. Это жесткая операционная граница, но она оправдана, когда trust boundary проходит через сам путь распространения пакета.