Ваш сайт вам больше не принадлежит: как CVE-2025-11953 отдает ключи хакерам

[vaspvort]

Итак, 5 ноября команда JFrog опубликовала предупреждение об уязвимости CVE-2025-11953 в инструментах командной строки проекта React Native Community CLI. React Native — это платформа которую используют тысячи разработчиков для создания мобильных приложений, которые мы видим в App Store или Google Play. А React Native Community CLI через командную строку предоставляет инструменты для разработки и сборки этих приложений, куда как раз и входил злополучный пакет.

На первый взгляд, это еще один CVE в длинном списке. Но проблема глубже: уязвимость в популярном пакете может затронуть сотни проектов одновременно и ударить не только по продакшену, но и по устройствам разработчиков и CI-пайплайнам.

В статье разберем, как библиотеки из удобных помощников превращаются в точку входа для злоумышленников, почему такие инциденты не решаются простым апдейтом и какие механики атак через зависимости встречаются чаще всего. В конце обсудим дилемму — стоит ли вообще полагаться на сторонние фреймворки или лучше писать нативно. Детали под катом.

А что говорят цифры​

По данным отчета Sonatype за прошлый год, количество загрузок открытого исходного кода достигло 6,6 триллиона, при этом до 90% современных приложений строятся на базе опенсорсных компонентов. Получается, что, с одной стороны, без open source не обойтись: его используют все, от фрилансеров до технологических гигантов. С другой, у этого есть своя цена. Количество вредоносных пакетов взлетело на 156% за год, превысив отметку в полмиллиона (512 847) к ноябрю 2024. И эта цифра будет только расти.

Эксплуатируют ли злоумышленники этот рост? Вопрос риторический. Впрочем, ответственность не только на них. Ситуацию усугубляет халатность: 80% зависимостей остаются без обновлений больше года, хотя доступны безопасные версии. Спустя три года после обнаружения Log4Shell (CVE-2021-44228) 13% загружаемых в библиотеку Log4j файлов по-прежнему уязвимы.

Но давайте же рассмотрим внутреннее устройство таких дыр детальнее на реальных примерах.

Техническая анатомия уязвимостей​

Уязвимость в пакете React Native Community CLI​

В начале давайте вспомним инфоповод, из-за которого мы здесь собрались. Что же там случилось и в какой опасности приложения?

Специалисты по безопасности из JFrog обнаружили критическую дыру в экосистеме React Native Community CLI — CVE-2025-11953 с оценкой 9,8 по шкале CVSS. Уязвимость найдена в серверном компоненте пакета @react-native-community/cli — который отвечает за работу с API в React Native. Пакет скачивают порядка двух миллионов раз в неделю, то есть потенциально под ударом тысячи проектов и разработчиков.

Риск возникал только при запущенном Metro и затрагивал пакет @react-native-community/cli-server-api. Уязвимость затрагивала dev‑сервер Metro, используемый React Native CLI: не аутентифицированный POST‑запрос , отправленный на уязвимый endpoint, мог привести к выполнению произвольных системных команд.

Проблема усугубляется тем, что Metro dev-server в ряде конфигураций доступен не только локально, но и из внешней сети, а значит потенциально возможный инцидент превращается из локального риска в реальную удаленную угрозу.

Исследователи экспериментально добились полного контроля параметров исполняемых команд на Windows. На Linux и macOS выполнение команд также возможно, хотя доступ к параметрам ограничен. При этом JFrog подчеркивает: хотя атаки на реальных приложениях пока зафиксированы не были, вероятность компрометации существенная, особенно в средах со множеством наружных зависимостей и непрозрачными цепочками поставки ПО.

Разработчики отреагировали оперативно: исправление включено в релиз 20.0.0 пакета @react-native-community/cli-server-api. Так что если вы используете React Native, лучше как можно скорее проверить проекты и обновиться до версии 20.0.0 или выше.

Атака на цепочки поставок: бэкдор в xz-utils (CVE-2024-3094)​

Источник.
Атаки на цепочку поставок ПО — это ситуация, когда злоумышленники атакуют не напрямую ваше приложение, а бьют по доверию к сторонним библиотекам. Они внедряют свой код в популярный пакет или его свежее обновление. Получается, что этот скрытый код автоматически разлетается к миллионам пользователей через механизм зависимостей, которые разработчики сами регулярно устанавливают в свои проекты.


Представьте: март 2024, инженер Андрес Фройнд ковыряется в тестовой Debian-сборке, видит, что OpenSSH странно тормозит, и решает разобраться. Он начинает смотреть глубже, а там в xz-utils версиях 5.6.0 и 5.6.1 сидит полноценный бэкдор, который мог пропустить удаленный доступ к SSH-сессиям на Linux-машинах с systemd-уведомлениями.

Это не какой-то случайный баг. Пользователь под ником JiaT75 (он подписывался Jia Tan), а скорее целая группа вроде APT29 (он же Cozy Bear), с 2009 года вносила мелкие патчи в проект, потихоньку завоевывая доверие мейнтейнера Лассе Коллина. Его даже убедили передать контроль над репозиторием GitHub. Тут Jia Tan и впихнул код в тестовые файлы tarball-архивов, которые использовались для релизов.

Jia Tan разбросал обфусцированный payload кусками с мусором вместо пробелов. Специально измененный makefile собирал этот код в библиотеку liblzma только при компиляции с нужной конфигурацией и ждал триггера от OpenSSH.

Для активации достаточно было подключиться по SSH с поддельным ключом и вуаля, RCE (Remote Code Execution) без аутентификации, CVSS 10.0. Повезло, что программист из Microsoft Андрес Фройнд наткнулся на медленно работающий OpenSSH и начал копать, иначе бы unstable-версии ушли в stable и разлетелись по миру.

Уязвимости десериализации (Deserialization Vulnerabilities) в IBM ODM (CVE-2024-22320)​

Источник.
А тут уже речь о фундаментальной проблеме обработки данных — уязвимостях десериализации. Они возникают, когда приложение небезопасно восстанавливает сериализованные объекты из ненадежных источников. Атакующий может подменить байты и вызвать выполнение произвольного кода через так называемые gadget-цепочки во фреймворках вроде Jackson (Java) или pickle (Python).

В основе лежит отсутствие валидации: десериализатор парсит поток данных, натыкается на класс с вредоносным методом и выполняет его в контексте приложения, часто с повышенными привилегиями.

В феврале 2024 обнаружена критическая RCE-уязвимость CVE-2024-22320 в IBM Operational Decision Manager (ODM). Она использовала стандартный механизм десериализации Java, который остается одним из самых распространенных методов достижения RCE. Взлом можно было совершить только с использованием уже существующей учетной записи. Успешная эксплуатация позволяла атакующему повысить доступ и выполнять произвольный код на уровне SYSTEM.

Уязвимость кроется в механизме обработки данных. Злоумышленник отправляет специально сформированный сериализованный объект на уязвимый эндпоинт (например, через параметр javax.faces.ViewState), который, будучи обработанным приложением IBM ODM, приводит к выполнению произвольных системных команд. Для подготовки таких атак используют публичные инструменты вроде ysoserial для генерации вредоносных нагрузок.

Далее злоумышленнику было достаточно отправить сетевой запрос на конкретный уязвимый эндпоинт с корректным форматом данных в контексте контректной ODM. Эта RCE-уязвимость эксплуатировалась без необходимости аутентификации, что и дало высокий рейтинг CVSS 9.8+ из-за сетевого вектора атаки. Для защиты от подобных дыр необходим комплексный подход: строгая валидация данных в сочетании с переходом на безопасные способы их передачи, такие как Google’s Protocol Buffers,


Сами по себе протоколы не станут лечением — то же Protobuf помогает, только если полностью отказаться от небезопасной десериализации (например, Java-десериализации в смежных стеках). Подробные митигейшены можно изучить на примере схожих уязвимостей.

Typosquatting: маскировка под популярные NPM-пакеты​

Источник.
А если речь о том, что не контролирует машина — это человеческий фактор. Именно к этому явлению применимо понятие тайпсквоттинг. Это метод, при котором весь акцент делается на человеческих ошибках — опечатках в именах пакетов программного обеспечения.

Атакующий размещает в публичных репозиториях вредоносный модуль, имя которого лишь незначительно отличается от имени популярной библиотеки. Например, «react-domm» вместо «react-dom».

В результате человеческого фактора или автоматизированных скриптов, ищущих обновления, этот фальшивый пакет загружается в проекты миллионов пользователей.

В 2024 году аналитики по кибербезопасности, включая компании Socket и Phylum, выявили скоординированную кампанию, нацеленную на кражу критически важных данных разработчиков. Злоумышленники использовали около 10 пакетов с именами, имитирующими популярные зависимости, такие как typescript и discord.js. Эти поддельные пакеты совокупно набрали более 9 900 загрузок до момента их обнаружения и удаления.

Это целенаправленная, спланированная операция. Только за третий квартал 2024 Phylum обнаружил более тысячи пакетов, созданных исключительно для тайпсквоттинга.

Вредоносный код не был частью основных исходников. Он скрывался в postinstall-скрипте — фрагменте кода, который автоматически выполнялся сразу после завершения установки пакета. Этот скрипт запускал многоступенчатый процесс, часто маскируемый под легитимную системную проверку, например, выводя поддельный ASCII CAPTCHA в консоли для отвлечения внимания.

После этого скрипт загружал инфостилер. Этот зловред предназначался для разных ОС (Windows, Linux, macOS) и был способен извлекать сохраненные пароли, аутентификационные токены, ключи SSH и файлы окружения из браузеров и системных связок ключей.

Обнаружение таких угроз затруднено из-за их поведенческого характера и многоуровневой обфускации. Хотя современные инструменты анализируют сетевые вызовы и обфускацию, подобные атаки успешно обходят традиционные сигнатурные сканеры, используя методы тайпсквоттинга при генерации имен и особые методы маскировки кода.

Уязвимости ядра. Кейс Dirty Pipe (CVE-2022-0847)​

Что может быть больнее удара по ОС, который обходит вообще все защитные механизмы? Только уязвимость в ее собственном ядре.

Уязвимости на уровне ядра операционной системы позволяют локальному непривилегированному пользователю получить root-права или изменить файлы, доступные только для чтения, обходя все стандартные механизмы контроля доступа. Это критический класс уязвимостей, часто оцениваемый по CVSS как высокий из-за полного контроля системы в случае успешной эксплуатации.

В марте 2022 года инженер Макс Келлерманн из CM4all нашел критическую уязвимость в ядре Linux с версии 5.8. Уязвимость получила название «Dirty Pipe» и позволяла любому локальному пользователю получить полные root-права за считанные секунды на огромном количестве серверов и устройств на базе Android.

Агентство по кибербезопасности и защите инфраструктуры США (CISA) подтвердило активную эксплуатацию этой уязвимости в реальных условиях вскоре после ее публичного раскрытия.

Уязвимость крылась в механизме работы с каналом и обработкой флага PIPE_BUF_FLAG_CAN_MERGE в функциях copy_page_to_iter_pipe и push_pipe. Из-за ошибки инициализации этот флаг мог оставаться установленным, даже когда не должен был, что позволяло манипулировать буфером.

Механизм эксплуатации включал создание канала и использование системного вызова splice() для перемещения данных между файловым дескриптором и каналом. Непривилегированный процесс мог «внедрить» произвольные данные в кэш страниц, связанный с файлами. При этом не происходила стандартная проверка разрешений, так как ядро считало, что работает с собственным, уже разрешенным кэшем.

Злоумышленник мог перезаписать содержимое системных файлов (/etc/passwd, исполняемых бинарников вроде sudo), несмотря на то, что эти файлы были открыты в режиме read-only. Патчи были срочно выпущены 23 февраля 2022 года для версий ядра 5.16.11, 5.15.25 и 5.10.102.

Фреймворки vs натив​

Чем так манят фреймворки вроде React Native или Flutter? Тем, что они позволяют выпускать мобильные приложения быстро и сразу для iOS и Android. Но огромные деревья зависимостей npm и экосистема JavaScript делают стек уязвимым к атакам, особенно на цепочки поставок ПО.

С другой стороны, нативная разработка на Swift/Kotlin дает больше контроля. То есть там меньше транзитивных JavaScript-зависимостей, меньше случайных сторонних SDK, и вы сами валидируете каждый импорт, минимизируя поверхность атаки. Выбор прост: фреймворки для MVP и быстрого релиза, натив — для кровавого энтерпрайза или приложений с повышенными требованиями безопасности.

Снижать риски придется везде, но подходы отличаются. Если вы отдаете предпочтение готовым фреймворкам и библиотекам, основной упор придется делать на автоконтроль. Вы будете постоянно сканировать свой код на уязвимости с помощью программ вроде Snyk или Socket. Также нужно вести полный список всех используемых компонентов (это называется SBOM) и блокировать автоматический запуск скриптов при установке пакетов. Еще помогут инструменты yarn и pnpm для проверки целостности ваших библиотек.

Нативные стеки требуют иного подхода и меньшего количества инструментов. Здесь акцент смещается на архитектуру приложения и изоляцию его частей. Фокусируйтесь на внедрении зависимостей, чтобы изолировать модули. Хотя библиотек меньше, все равно важно проводить их регулярный аудит. При этом не забывайте о ключевом принципе нулевого доверия: не стоит доверять сторонним компонентам без их изоляции в безопасной «песочнице», как советуют эксперты из OWASP.

Итог — гибридный подход. Фреймворки с SCA хороши для скорости, а натив с минимализмом подойдет для тех, кому важна максимальная безопасность. И всегда используйте SBOM и автоматизированный аудит, чтобы не стать следующей жертвой атаки вроде той, что была у xz-utils.

Что думаете по этому поводу, делитесь в комментариях.

Источник