Как SSRF в Plex превращается в майнер на домашнем сервере

Plex Media Server стоит во многих домашних лабораториях: на NAS, в Docker-контейнере на мини-ПК, на старом ноутбуке под кроватью. Часто его порт проброшен наружу, чтобы смотреть фильмы с телефона вне дома. В сентябре разработчики выпустили версию 1.43.3 и попросили всех обновиться. В октябре вышли технические детали и демонстрационный эксплойт, а 17 октября, через день после публикации PoC, непропатченные серверы начали массово взламывать. На них ставят прокси-сервер и криптомайнер.

Цепочка состоит из четырёх уязвимостей: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 и CVE-2026-96656. Нашёл их независимый исследователь под ником Zmain, причём искал с помощью ИИ. По отдельности каждая ошибка выглядит умеренно опасной. Вместе они дают атакующему из интернета выполнение произвольного кода на сервере.

Этап 1: сервер доверяет самому себе

Plex по-разному обрабатывает запросы в зависимости от того, откуда они пришли. Запрос из сети должен содержать валидный токен доступа. Запрос с адреса 127.0.0.1 считается внутренним и проходит без авторизации. Логика понятная: локальные компоненты сервера общаются друг с другом, и гонять между ними токены неудобно.

Кроме пользовательских токенов у сервера есть токен администратора, который даёт полный контроль над экземпляром Plex.

Сама по себе схема «localhost без авторизации» работает, пока никто снаружи не может заставить сервер отправить запрос самому себе. Именно это и ломается дальше.

Этап 2: SSRF и валидатор, который проверяет только префикс

Первая уязвимость в цепочке — Server-Side Request Forgery, довольно простая по своей природе: атакующий передаёт серверу URL, и сервер сам идёт по этому адресу. Через неё запрос от имени Plex попадает на его же внутренний интерфейс и получает «локальные» права.

Вторая ошибка усиливает первую. Валидатор URL считает локальным любой адрес, строка которого начинается с 127.0.0.1. По сути это проверка префикса строки вместо разбора хоста. Под такое правило попадают, например, адреса вида 127.0.0.1.attacker.example, которые резолвятся куда угодно. Сервер решает, что работает с собой, применяет правила для локальных запросов и в итоге отправляет токен администратора на URL атакующего.

На практике атака требует серии подготовленных запросов. На выходе у атакующего админский токен чужого сервера.

Этап 3: транскодер как загрузчик кода

Имея токен администратора, злоумышленник ещё не исполняет код, и этот этап тоже нетривиален. Доставка идёт через встроенную функцию транскодирования:

Серверу отдаётся команда воспроизвести видеофайл с определёнными опциями энкодера x264.
В «видеоролике» на самом деле лежит вредоносный код. В процессе он сохраняется на диск сервера как файл с расширением .so.
Последняя ошибка цепочки: сервер загружает и выполняет любой файл с расширением .so, без проверки, откуда он взялся.

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

Хронология

Дата	Событие
конец июля	Zmain передаёт информацию разработчикам Plex
начало сентября	выходит Plex Media Server 1.43.3 с исправлениями
конец сентября	уязвимостям присвоены CVE
середина октября	публикуются детали и Proof of Concept
17 октября	зафиксированы атаки на непропатченные серверы

Между патчем и эксплуатацией прошло больше месяца. Между публикацией PoC и эксплуатацией — один день. Если сервер не обновился за сентябрь, окно для спокойного обновления закрылось ровно в момент выхода эксплойта.

Что проверить на своём сервере

Версия. Всё, что ниже 1.43.3, уязвимо. Номер версии виден в веб-интерфейсе в настройках сервера. В Docker обновление означает свежий образ и пересоздание контейнера; одного перезапуска старого контейнера недостаточно, если тег закреплён на конкретной версии.

Признаки взлома. Атакующие ставят прокси и майнер, поэтому смотреть стоит на:

постоянную загрузку CPU при отсутствии воспроизведения и транскодирования;
незнакомые процессы, запущенные от пользователя Plex (ps -u plex -o pid,cmd на хосте или docker top <container>);
новые прослушиваемые порты (ss -tlnp) и исходящие соединения на неизвестные адреса;
файлы .so в каталогах данных Plex, которых не было в штатной установке.

Если что-то нашлось, обновления мало. Токен администратора мог утечь, поэтому стоит пересоздать контейнер с чистого образа, сменить пароль аккаунта Plex и отозвать авторизованные устройства. Если Plex работал без контейнера и имел доступ к другим данным на хосте, хост лучше считать скомпрометированным целиком.

Экспозиция наружу. Вся цепочка начинается с запроса из сети. Сервер, доступный только из локальной сети или через VPN (WireGuard, Tailscale), атакующему из интернета просто не виден. Удалённый доступ через VPN закрывает и следующую подобную уязвимость, до которой ещё не дошёл патч.

Права процесса. Код выполняется от имени пользователя Plex, поэтому ущерб определяется тем, что этому пользователю доступно. Отдельный непривилегированный UID, медиатека, смонтированная в режиме только для чтения, отсутствие монтирования docker.sock и лишних каталогов хоста сужают последствия до одного контейнера.

Что из этого вынести разработчику

У цепочки три типовые ошибки, каждая из которых встречается далеко за пределами Plex:

Авторизация по IP-адресу источника. Правило «с localhost пускаем всех» превращает любую SSRF в обход аутентификации. Внутренние вызовы тоже лучше подписывать токеном или ходить через Unix-сокет с правами доступа.
Проверка URL строковым сравнением. Хост нужно извлекать парсером URL, резолвить и сравнивать полученный IP со списком разрешённых.
Загрузка плагинов по расширению файла. Если процесс подгружает .so из каталога, куда он же пишет пользовательские данные, любая запись файла становится выполнением кода. Каталог с загружаемыми модулями должен быть недоступен на запись самому сервису.

Из той же недели: в ядре Linux нашли уязвимость CVE-2026-99999 под названием PwnEscape, которая позволяет процессу внутри виртуальной машины читать память хоста. Для тех, кто держит гипервизор с несколькими ВМ, это повод отслеживать обновления ядра на хосте. А пользователям Arch стоит перепроверить установленные AUR-пакеты: в репозитории снова появились вредоносные пакеты, названия которых отличаются от yay и paru на один-два символа.