Как мне повезло с ней столкнуться

В конце 2025 года мир react разработчиков облетела новость о опасной узявимости в серверных реакт компонентах. Уязвимость получила максимальный уровень опасности по шкале CVVS и ей был присвоен номер CVE-2025-55182. Было очень много новостей на эту тему прямо под новый год.

Официальные сообщества react и nextjs поспешили выпустить патчи обновлений и призвали всех обновиться как можно быстрее: вот и вот. Сама же проблема, состоит в неидеально реализованной сериализации для react server components, которая позволяет злоумышленнику выполнять свой код, более подробно описано в статье.

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

Но на днях, доедая салаты, решил дать желудку отдохнуть и заняться потреблением умственной пищи, а точнее - решил разобраться что же происходит с моим сайтом. Кстати мой сайт это небольшая галерея изображений и артов чувашской тематики, посетителей там немного, поэтому заходите, будем рады. Работал он в тот момент на 15.0.0 версии nextjs и 19.0.0 версии react, развернут как и многие в docker, который крутится на vps, который я арендую у провайдера webhost1.

В панели управления vps нагрузка cpu оказалась 100%, раньше я не часто обращал внимания на этот показатель, но раньше он всегда был в норме. И действительно, посмотрев статистику я увидел что такой рост потребления начался с 6 декабря.

Сперва я грешил на на сам проект и решил заглянуть в гит, нет ли там правок которые могли привести к каким-либо поломкам, по совпадению они там оказались, но изучив их стало понятно что дело не в них. Тогда было решено поизучать, что происходить на самом vps сервере (там стоит ubuntu 24), для чего воспользовался утилитой btop и посмотрел какие ресурсы больше всего едят ресурсы процессора.

Подозрительные процессы

Как видно на скриншоте (рис.2) больше всего жрет процесс softirq, полез в гугл узнать что это такое и тут начались мои мытарства по разнообразным источникам информации на тему системных прерываний в linux (soft irq). Потратив несколько часов на бесплодное погружение в основы работы linux (сразу скажу в этом я полный ноль и если где-то сморожу глупость прошу строго не судить), я заметил что в строке команды есть параметр --randomx-1gb-page, координаты скриншота примерно 50% по высоте и 100% по широте.

Полез в яндекс узнать, что это за параметр такой и первый же ответ выдал ссылку на инструкцию к майнеру XMRRig. Вскоре этот процесс сам потух и появился новый, но уже с названием javae. Стало понятно, что это просто замаскированные названия для внедренных злоумышленниками процессов, а в данном случае для майнера.

Получается, благодаря тому, что я запускал docker под root пользователем майнер смог выставить себе настройку на повышенное потребление оперативки. Я проверил также открытые порты, никаких подозрительных портов кроме стандартных октрыто не было. Проверил также расписание cron, в нем тоже ничего подозрительного.

Откуда же майнерам взяться на моем vps сервере? Гугл ИИ вполне доказательно подсказал мне, что этот майнер вполне мог быть заброшен благодаря новой уязвимости react2shell. Кстати название было дано по аналогии с другой известной уязвимостью log4shell.

Тогда я обновил версии и nextjs и react и всех связанных пакетов, перезапустил vps и контейнеры и все заработало как положено. После нескольких часов мониторинга все было в норме - диаграмма сердцебиения CPU пришла в норму. Получается я отделался месяцем работы своего vps на благо вероломных майнеров. Но не у всех было так гладко, в этой статье описана более проблемная история, возможно кому-то поможет.

Что дальше?

Остановиться на этом было нельзя, т.к. данная проблема явно тыкнула меня носом не только в низкую компетенцию по части администрирования и кибербезопасности, но и в очевидную халатность: docker крутился под root пользователем. Было решено перевести docker в rootless режим.

Процитирую документацию по rootless mode:

Режим без прав суперпользователя позволяет запускать демон Docker и контейнеры от имени пользователя без root прав, чтобы снизить риск возникновения уязвимостей в демоне Docker и среде выполнения контейнеров.

Был заведен дополнительный пользователь, выставлены все нужные настройки, установлены утилиты, перенастроен деплой, выданы нужные права на каталоги, предоставлен доступ к портам до 1024, чтобы сайт снова заработал, а команда docker version подтвердила, что docker запущен в rootless режиме (поле context на скриншоте).

Спустя сутки полет нормальный, я надеюсь это были первые и последние проблемы по части безопасности в этому году.

Выводы

Для себя я сделал следующие выводы:

1. Даже во фронтенд фреймворках уязвимости могут быть весьма опасными и не надо пренебрегать безопасностью

2. Даже для пет проектов не надо лениться обновлять пакеты если их скомпрометировали

3. Docker надо запускать в rootless mode