Plex Media Server przed wersją 1.43.3.10861 ma cztery podatności z ocenami 4.3, 6.5, 4.3 i 7.2: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 i CVE-2026-96656. Żadna nie przekracza progu Critical, a jedna wymaga nawet uprawnień admina. Połączone dają jednak zdalne wykonanie kodu bez żadnego logowania. Writeup „Plex2Shell” ukazał się 16 października, a rano 17 października honeypot zobaczył pierwszy atak. 19 października Plex napisał, że podatności są „actively and widely exploited”. Poprawka jest dostępna od września. Jeśli Twoja polityka mówi „Critical w 7 dni, Medium w kwartale”, ten łańcuch wciąż leży w kolejce.
PR:L): SSRF przez /player/timeline. NVD: „An attacker using any X-Plex-Token value can include a full URL in the 'protocol' parameter and force the Plex server to POST to the attacker’s chosen destination”. Kluczowe jest słowo „any”: wektor mówi PR:L, ale token może mieć dowolną wartość.PR:N): brak neutralizacji wartości URL w searchOne, co pozwala „call other plugins’ functions and supply their own parameters”.PR:L): według NVD uwierzytelniony użytkownik może kazać serwerowi łączyć się z dowolnym adresem przez parametr ścieżki /video/:/transcode/universal. Plex w wątku z 19.10 opisuje ten sam numer inaczej: „Disclosure of the server owner’s admin token”. Opisy się rozjeżdżają, więc mapowanie numeru na etap łańcucha traktuj ostrożnie.PR:H): admin może zapisać plik, który zostanie wykonany. NVD: opcja TranscoderH264Options „is appended verbatim to x264’s option string on every transcode”, a „at startup, all .so files are run without signature, execute bit, or symbol checks”.Attack path
Według writeupu zmain.info. Badacz wymienia cztery CVE, ale nie przypisuje numerów do etapów, więc numery w nawiasach to moje dopasowanie na podstawie opisów NVD:
Dlaczego żaden próg CVSS tego nie łapie
Każda ocena jest policzona osobno i każda osobno jest uczciwa. SSRF, która tylko wysyła POST, to faktycznie 4.3. Zapis pliku, który wymaga konta admina, to faktycznie 7.2, bo PR:H mocno obniża wynik. Problem w tym, że CVSS ocenia pojedyncze ogniwo i zakłada, że warunek PR:H jest barierą. W Plex2Shell ten warunek spełnia kradzież tokenu właściciela z wcześniejszych etapów. Badacz pisze, że atakujący dostaje dostęp admina „without ever having real credentials”.
Najwyższy wynik w łańcuchu to 7.2, z wektorem wymagającym uprawnień admina. Reguła „zamykaj Critical (9.0+) w 7 dni” nie obejmie żadnego z nich. Reguła „High w 30 dni” obejmie tylko CVE-2026-96656, i to na końcu kolejki, bo „wymaga admina”. Tymczasem od writeupu do pierwszego ataku na honeypocie minął jeden dzień. Ten sam mechanizm opisywałem przy FortiOS CVE-2025-61624 (Medium „tylko dla admina” w KEV jako krok do roota) i przy dwóch Windows EoP z KEV. Ocena ogniwa nie mówi nic o jego pozycji w łańcuchu. Podobnie przy Cochise (CVSS 3.7 jako początek łańcucha do RCE).
Praktyczna reguła: jeśli kilka CVE dostaje poprawkę w tym samym buildzie, a co najmniej jedno ma PR:N lub „dowolny token”, a inne daje wykonanie kodu, licz je razem. Priorytet ustawia najgorszy możliwy skutek łańcucha z warunkiem wejścia najsłabszego ogniwa. Tu daje to RCE z PR:N.
Oś czasu: sześć tygodni na patch, jeden dzień na exploit
Kto zaktualizował we wrześniu, ma problem z głowy. Kto czekał na CVE, KEV albo „sygnał eksploatacji”, dostał go w dniu, w którym exploit był już w obiegu. To samo zjawisko skracania czasu od publikacji do ataku opisywałem przy WordPress CVE-2026-87902.
Co dokładnie widział honeypot (i czego nie wiemy)
Dowód eksploatacji z 17.10 pochodzi z jednego honeypota jednego autora (boredhackerblog), z podatną wersją Plex. Autor widział żądanie do /player/timeline/subscribe z parametrem wskazującym na host sslip.io na porcie 8952 i user agentem Python-urllib/3.10. Po odblokowaniu ruchu wychodzącego honeypot pobrał pliki z 217.60.194.116: plik związany z Dockerem i spakowany UPX binarny „x”, który autor określa jako koparkę. Na hoście pojawiły się też xmrig i proxyware „myawesomeproxy” oraz ruch do proxystream[.]st. Adresy atakujących według posta: 91.92.40.202, 176.65.139.228, 45.194.92.222. Hashe SHA-256 są w poście.
Czego z tego nie wiadomo: skali. Autor nie podaje liczby prób ani zainfekowanych hostów, pisze tylko o „more activity”. Część payloadów mogła umknąć, bo ruch wychodzący był początkowo zablokowany. Podobieństwo do botnetu Aisuru autor sygnalizuje, ale go nie potwierdza. Analiza „myawesomeproxy” nie jest skończona. Słowo „widely” pochodzi od Plex, nie od honeypota, i Plex nie podaje liczb. Skala eksploatacji pozostaje niezweryfikowana.
Gdzie stoi Plex: home lab, NAS i shadow IT
Badacz pisze, że Plex „listens on port 32400 and is often exposed directly to the internet”. Plex to typowy przykład oprogramowania, którego nie ma w CMDB: stoi na NAS-ie w małym biurze, na serwerze „przy okazji”, w kontenerze na hoście deweloperskim albo w domu pracownika, który łączy się VPN-em z firmą. Aktualizacje idą ręcznie albo przez sklep NAS-a. Plex sam pisał w lipcu, że „not all app stores (e.g. QNAP, etc.) will have the update immediately”.
Dla VE oznacza to trzy pytania. (1) Czy wiesz, gdzie u Ciebie działa Plex? Skan własnych zakresów na TCP 32400 (wewnątrz i z zewnątrz) znajdzie więcej niż inwentarz oprogramowania. (2) Co widzi konto usługi Plex? Kod wykonuje się z uprawnieniami procesu Plex Media Server. Na NAS-ie to zwykle zamontowane udziały z danymi firmy, na hoście z Dockerem być może coś więcej. Plex sam każe przejrzeć „mounted shares and stored credentials”. (3) Czyje to jest? Serwer w domu pracownika nie jest Twój, ale jego adres IP może trafić do sieci proxy, a z tego hosta pracownik łączy się z firmą. Autor honeypota zwraca uwagę, że serwery Plex na adresach domowych mogą służyć jako proxy.
Jak sprawdzić wersję i co z danymi w skanerze
(1) Plex: „open Plex Web, go to Settings → General” i sprawdź pełny numer builda. Próg to 1.43.3.10861, a nie samo „1.43.3”. Build 1.43.3.10828 z lipca (wątek wydań, do którego linkuje NVD) jest poniżej progu. (2) Aktualizacja zależy od platformy: instalator z Downloads (Windows, macOS), pakiet .deb/.rpm (Linux), menedżer aplikacji vendora NAS-a albo instalacja ręczna, Docker według README. (3) Uwaga na dane CPE. W rekordach NVD wszystkich czterech CVE konfiguracja CPE w chwili pobrania (19.10) ma versionEndExcluding 1.43.0.10861, a opis mówi „before 1.43.3.10861”. Wygląda to na literówkę w CPE, ale skaner, który dopasowuje wyłącznie po CPE, może uznać buildy 1.43.0–1.43.3 sprzed 10861 za niepodatne. To moje wnioskowanie z rekordu, nie sprawdzałem, jak zachowują się konkretne skanery. Zamykaj finding po numerze builda z Plex Web, nie po wyniku dopasowania CPE.
Przy okazji: CSAF CISA VA-26-266-01 obejmuje też piąte CVE, CVE-2026-96651 (path traversal przez /system/agents/media/get, 6.5), które według NVD pozwala odczytać m.in. PlexOnlineToken. Nie jest wymienione w łańcuchu Plex2Shell, ale zamyka je ten sam build.
Co powinien zrobić VE
(1) Zinwentaryzuj wszystkie instancje Plex (skan TCP 32400, NAS-y, kontenery) i zaktualizuj do 1.43.3.10861 lub nowszej. (2) Jeśli instancja była starsza i dostępna z internetu, nie zamykaj zgłoszenia patchem. Plex pisze wprost: „assume it may be compromised”. Szukaj procesów uruchomionych przez Plex o nazwach typu myawesomeproxy, mylovelyminer, x12345, nieznanych plików .so/.dll w katalogu Codecs, połączeń do proxystream[.]st i stałego obciążenia CPU bez odtwarzania. Dorzuć adresy i hashe z posta boredhackerblog. (3) Przy kompromitacji lub braku pewności: czysta instalacja zamiast ponownego użycia katalogu danych, a minimum to wyczyszczenie Codecs i przegląd Preferences.xml pod kątem opcji transkodera, których nie ustawiałeś. Potem wylogowanie wszystkich urządzeń, zmiana hasła konta Plex i przegląd tego, do czego miało dostęp konto usługi. To już remediacja przechodząca w hunting, a nie patch. (4) Wyłącz Remote Access, jeśli nie jest potrzebny, i nie przekierowuj portu 32400 wprost. (5) Popraw politykę: CVE zamykane tym samym buildem, z których jedno ma PR:N, a inne daje wykonanie kodu, oceniaj jako jeden łańcuch. Brak w KEV i SSVC „exploitation none” sprzed miesiąca nie są tu argumentem. Vendor potwierdził eksploatację wcześniej, niż zaktualizowały się katalogi.
Powiązane na blogu
- FortiOS CVE-2025-61624 — Medium „tylko dla admina” w KEV jako krok w łańcuchu
- Windows: dwa EoP 7.8 w KEV — pozycja w łańcuchu ważniejsza niż ocena
- Cochise CVE-2026-90623 — CVSS 3.7 na początku łańcucha do RCE
- WordPress CVE-2026-87902 — exploit half-life krótszy niż SLA
Źródła
- Plex Forum — Important security update for Plex Media Server v1.43.2 and earlier (01.09.2026, aktualizacja CVE 19.10.2026) — forums.plex.tv
- Plex Forum — Plex Media Server, ogłoszenie 1.43.3.10828 (14.07.2026, referencja NVD) — forums.plex.tv
- zmain.info — Plex2Shell: Unauthenticated RCE in Plex Media Server (16.10.2026) — zmain.info
- boredhackerblog — Plex vulnerabilities being exploited in the wild (17.10.2026, aktualizacje 17–18.10) — boredhackerblog.info
- NVD — CVE-2026-96652 — nvd.nist.gov
- NVD — CVE-2026-96654 — nvd.nist.gov
- NVD — CVE-2026-96655 — nvd.nist.gov
- NVD — CVE-2026-96656 — nvd.nist.gov
- NVD — CVE-2026-96651 — nvd.nist.gov
- CISA CSAF VA-26-266-01 — Plex Media Server (23.09.2026) — github.com/cisagov
- CISA Known Exploited Vulnerabilities Catalog (CVE-2026-96652, -96654, -96655, -96656 nieobecne w wersji 2026.10.16) — cisa.gov
Nota redakcyjna: stan informacji 19 października 2026, wieczór, na podstawie wątku bezpieczeństwa Plex (post z 01.09.2026 i aktualizacja z 19.10.2026), writeupu zmain.info z 16.10.2026, posta boredhackerblog z 17.10.2026 (z aktualizacjami z 17–18.10), rekordów NVD (status „Analyzed”, opublikowane 23.09.2026), CSAF CISA VA-26-266-01 i katalogu CISA KEV w wersji 2026.10.16, w którym żadnego z tych CVE nie ma. Oceny CVSS 3.1 pochodzą od CNA w rekordach NVD (te same wartości w CSAF CISA). Dowód eksploatacji z 17.10 pochodzi z jednego honeypota. Stwierdzenie o szerokiej eksploatacji pochodzi od Plex, bez liczb. Nie weryfikowałem: skali eksploatacji, liczby serwerów Plex dostępnych z internetu, daty wydania builda 1.43.3.10861 (wątek wydań wskazany przez NVD dotyczy 1.43.3.10828), przypisania CVE do etapów łańcucha (badacz go nie podaje, a opisy CVE-2026-96655 w NVD i u Plex się różnią), powiązania z botnetem Aisuru ani zachowania skanerów wobec rozbieżności CPE w NVD. Reguła oceniania CVE z jednego builda jako łańcucha to ocena autora, a nie wskazanie Plex ani CISA.