Plex2Shell: майнери и бекдор в Plex сървъри

Публично достъпни Plex Media Server инсталации се превземат от нападатели без нито една валидна парола. На 16 октомври изследователят Зак Мейн публикува пълното техническо описание и PoC код за верига от четири уязвимости, наречена Plex2Shell, а още на следващия ден — 17 октомври — honeypot сървър с уязвима версия е бил експлоатиран в реална атака. Товарът: майнер за Monero на базата на XMRig и прокси бекдор за Linux, който пуска чужд трафик през домашния ви IP адрес.

Поправката съществува от 3 август. Проблемът е, че много хора така и не са я инсталирали.

Какво представлява Plex2Shell

Веригата включва четири CVE, които поединично изглеждат скучни, а събрани заедно дават изпълнение на произволен код през порт 32400 с правата на самата Plex услуга (uid=1000(plex)):

• CVE-2026-96652 (CVSS 5.3) — SSRF през /player/timeline. Endpoint-ът проверява само че header-ът X-Plex-Token съществува, но не и дали стойността е валидна. Атакуващият регистрира фалшив плейър с измислен token и принуждава сървъра да прати POST заявки накъдето му трябва.
• CVE-2026-96654 (CVSS 6.9) — счупена проверка в API-то на агентите отваря searchOne, който нормално е достъпен само за удостоверени заявки от loopback.
• CVE-2026-96655 (CVSS 5.3) — втори SSRF, този път през /video/:/transcode/universal.
• CVE-2026-96656 (CVSS 8.6) — контрол над външен път, който позволява ELF shared object да бъде записан и изпълнен в директорията с кодеци.

Най-елегантният ход е в средата на веригата. Мейн инжектира URL от вида http://127.0.0.1.<атакуващ>.sslip.io в плъгин функцията GetResultFromNetwork. Проверката е по префикс, така че сървърът решава, че говори със себе си, и прикачя admin token-а на собственика — а DNS записът сочи към машината на нападателя. Токенът изтича наготово.

С админски права остава последната стъпка: промяна на настройките на транскодера (TranscoderH264Options), така че x264 да запише декодирани кадри във файл в папката с кодеци. Понеже тази папка се зарежда без проверка на подпис, внимателно сглобен ELF файл с конструктор се изпълнява при следващото зареждане на библиотеката.

Какво инсталират атакуващите

Според наблюденията на изследователя, който държи honeypot-а (публикувани в boredhackerblog) и преразказани от The Hacker News, атаките идват от IP адресите 91.92.40.202, 176.65.139.228 и 45.194.92.222, с user agent Python-urllib/3.10. Товарът се дърпа от 217.60.194.116 като файлове с имена docker и x.

Вътре има два бинарни файла с обезоръжаващо откровени имена. Първият, mylovelyminer, е XMRig майнер, който копае към ota.proxystream.st. Вторият, myawesomeproxy, е reverse прокси бекдор за Linux, който при стартиране показва следното съобщение:

Running this software on any of your devices makes you agree to the potential external use of your internet traffic.

Преведено: трафикът ви се продава. Същата инфраструктура — global.relay.proxystream.st — е била маркирана още през август 2026 г. във връзка с ботнета AISURU. Моделът е познат: домашните IP адреси се препродават като „резидентни прокси“, точно както при евтините Android телефони, превърнати в прокси мрежа.

Хронологията не е в полза на Plex

Датите са важни, защото обясняват защо толкова сървъри са уязвими през октомври:

• 27 юли 2026 — Мейн докладва уязвимостите на Plex.
• 3 август 2026 — пуснат е Plex Media Server 1.43.3.10861 с лаконичната бележка, че TranscoderH264Options и TranscoderH264OptionsOverride вече не могат да се променят през мрежата (PM-5766).
• 4 август 2026 — Plex потвърждава и изплаща bug bounty.
• 1 септември 2026 — компанията разпраща известия и имейли, че версии 1.43.2 и по-стари трябва да се обновят.
• 16 октомври 2026 — публикувани са анализът и PoC код, 81 дни след доклада.
• 17 октомври 2026 — първата експлоатация в реални условия, по-малко от 24 часа по-късно.

Поправката е влязла в редовния канал за обновления без отделен security бюлетин. Ако сте от хората, които са изключили автоматичните обновления или въртят Plex в Docker контейнер с фиксиран tag, най-вероятно сте точно в уязвимия диапазон.

Какво да направите сега

Минимумът е обновяване до 1.43.3.10861 или по-нова версия. След това си струва да огледате машината за следи:

# подозрителни процеси
ps aux | grep -Ei "mylovelyminer|myawesomeproxy|xmrig"

# новопоявили се .so файлове в папката с кодеци (Linux пакет)
ls -lt "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Codecs/"

Ако намерите нещо, обновяването няма да го махне — компрометираната машина трябва да се чисти отделно. Проверете и изходящите връзки към proxystream.st, както и необяснимо натоварен CPU в часове, в които никой не гледа нищо.

Дългосрочно: Plex няма работа директно в интернет на порт 32400. Отдалеченият достъп през relay сървърите на Plex или през VPN струва малко удобство, но премахва целия клас атаки, при които някой сканира целия IPv4 диапазон за медийни сървъри.

Поуката

Случаят подрежда три неприятни факта един до друг: уязвимостта е била поправена два месеца и половина преди атаките, нападателите са се нуждаели от под 24 часа, за да превърнат публичен PoC в работеща кампания, а целта не е била съдържанието ви, а процесорът и интернет връзката ви. Същата логика видяхме и при бекдора в Rank Math PRO — домашните и малките сървъри са привлекателни именно защото никой не ги наблюдава.

Прозорецът между „има патч“ и „има експлойт“ продължава да се стеснява. При Plex2Shell той беше един ден.