Wprowadzenie do problemu / definicja
W bibliotece odtwarzacza HTML5 mwEmbed, rozwijanej i dystrybuowanej w ekosystemie Kaltura, ujawniono dwie krytyczne podatności bezpieczeństwa. Problemy dotyczą endpointu mwEmbedLoader.php i mogą pozwolić zdalnemu, nieuwierzytelnionemu atakującemu na odczyt dowolnych plików z serwera, a w określonych warunkach również na zdalne wykonanie kodu. Szczególnie niepokojący jest fakt, że w momencie ujawnienia informacji nie była dostępna poprawka producenta.
W skrócie
Podatności oznaczono jako CVE-2026-19913 oraz CVE-2026-19912. Obie wynikają z niebezpiecznej deserializacji danych w komponencie mwEmbedLoader.php. Atak nie wymaga uwierzytelnienia ani aktywnej sesji, a kluczowym warunkiem jest jedynie dostęp sieciowy do podatnego endpointu.
- CVE-2026-19913 może umożliwić odczyt lokalnych plików z serwera.
- CVE-2026-19912 może prowadzić do zdalnego wykonania kodu w określonych konfiguracjach.
- Ryzyko dotyczy zarówno środowisk samodzielnych, jak i współdzielonych.
- Brak poprawki zwiększa znaczenie działań kompensacyjnych.
Kontekst / historia
Informacje o lukach ujawniono publicznie pod koniec sierpnia 2026 roku. Zgłoszenie przypisano badaczowi bezpieczeństwa Gerjanowi Wemekampowi. Według opublikowanej osi czasu próby kontaktu z producentem rozpoczęły się w marcu 2026 roku, a następnie były eskalowane przez kolejne kanały, w tym przez CERT.
Znaczenie sprawy jest duże, ponieważ mwEmbed pełni rolę komponentu wspierającego odtwarzanie i integrację treści wideo w aplikacjach webowych. Ujawnione szczegóły sugerują również, że podatny endpoint może być eksponowany nie tylko w instalacjach klientów, ale także w środowiskach wielodostępnych, co zwiększa potencjalną skalę incydentu.
Analiza techniczna
Źródłem obu podatności jest niebezpieczne użycie mechanizmu unserialize() w ścieżce przetwarzania danych pobieranych przez komponent PHP. Endpoint mwEmbedLoader.php akceptuje parametr ServiceUrl, który jest następnie wykorzystywany do wykonywania zapytań backendowych. Problem polega na tym, że odpowiedź zwrócona z podanego adresu może zostać przekazana do deserializacji bez odpowiedniej walidacji źródła, schematu i formatu danych.
W przypadku CVE-2026-19913 atakujący może wskazać lokalizację w schemacie file://, co prowadzi do odczytu lokalnego pliku z systemu serwera zamiast prawidłowej odpowiedzi API. Sama deserializacja kończy się błędem, ale skutkiem ubocznym może być ujawnienie pobranej zawartości w komunikacie zwracanym do klienta. W praktyce otwiera to drogę do wycieku plików konfiguracyjnych, poświadczeń i innych wrażliwych danych.
Druga luka, CVE-2026-19912, wykorzystuje ten sam punkt wejścia, lecz zamiast lokalnego pliku opiera się na kontrolowanym przez atakującego zasobie zawierającym złośliwy serializowany obiekt. Następnie parametr uiconf_id może posłużyć do manipulacji ścieżką zapisu, co prowadzi do wyjścia poza docelowy katalog cache. Jeżeli aplikacja korzysta z plikowego backendu cache, a zapis nastąpi do lokalizacji dostępnej z poziomu serwera WWW, kolejne żądanie może doprowadzić do wykonania kodu PHP.
Z technicznego punktu widzenia jest to niebezpieczny łańcuch błędów: zaufanie do zewnętrznego źródła danych, deserializacja bez odpowiednich zabezpieczeń, niewystarczająca sanitacja parametru wpływającego na ścieżkę pliku oraz możliwość wykonania zapisanej treści w kontekście serwera aplikacyjnego.
Konsekwencje / ryzyko
Najbardziej bezpośrednim skutkiem jest naruszenie poufności danych. Odczyt lokalnych plików może ujawnić konfigurację aplikacji, dane dostępowe do baz danych, klucze API, sekrety integracyjne oraz informacje o architekturze wewnętrznej. Tego typu dane często umożliwiają dalszą eskalację ataku.
W scenariuszu zdalnego wykonania kodu ryzyko wzrasta do poziomu krytycznego. Udany atak może prowadzić do instalacji webshella, modyfikacji aplikacji, wycieku danych klientów, trwałego utrzymania dostępu oraz wykorzystania serwera jako punktu wyjścia do dalszych działań w sieci organizacji. W środowiskach współdzielonych zagrożenie może objąć większą liczbę tenantów lub usług działających na tej samej infrastrukturze.
Dodatkowym problemem jest brak dostępnej poprawki w chwili ujawnienia, co zmusza organizacje do wdrażania środków kompensacyjnych na poziomie aplikacji, reverse proxy, WAF oraz polityk dostępu i wykonywania kodu.
Rekomendacje
Organizacje korzystające z Kaltura mwEmbed powinny jak najszybciej ustalić, czy endpoint mwEmbedLoader.php jest publicznie dostępny. Jeśli komponent nie jest niezbędny operacyjnie, najlepszym rozwiązaniem będzie jego wyłączenie lub odcięcie od ruchu z Internetu.
Jeżeli wyłączenie nie jest możliwe, należy zastosować ścisłą listę dozwolonych wartości dla parametru ServiceUrl i ograniczyć go wyłącznie do zaufanych adresów API. Równocześnie trzeba blokować schematy inne niż HTTP i HTTPS, w szczególności file://, oraz odrzucać nietypowe przekierowania i lokalizacje spoza kontrolowanego zakresu.
Parametr uiconf_id powinien być rygorystycznie walidowany pod kątem sekwencji path traversal, separatorów katalogów, ścieżek absolutnych oraz innych prób wpływania na lokalizację zapisu. Dodatkowo warto uniemożliwić wykonywanie skryptów PHP w katalogach cache i tymczasowych poprzez odpowiednią konfigurację serwera WWW i uprawnień systemowych.
- wdrożenie reguł WAF blokujących podejrzane użycie parametrów
ServiceUrliuiconf_id, - ograniczenie ruchu wychodzącego z serwera aplikacyjnego tylko do niezbędnych hostów,
- monitorowanie logów pod kątem odwołań do
mwEmbedLoader.php, błędów deserializacji i prób path traversal, - rotacja sekretów, które mogły znajdować się w lokalnych plikach konfiguracyjnych,
- przegląd integralności systemu pod kątem webshelli, nieautoryzowanych plików i zmian w katalogach cache,
- przygotowanie planu szybkiej aktualizacji lub wycofania komponentu po publikacji poprawki.
Podsumowanie
Luki CVE-2026-19913 i CVE-2026-19912 w Kaltura mwEmbed pokazują, jak groźne może być połączenie zaufania do zewnętrznego źródła danych z deserializacją oraz błędną obsługą ścieżek plików. W praktyce organizacje muszą liczyć się zarówno z ryzykiem wycieku wrażliwych danych z hosta, jak i z możliwością pełnego przejęcia serwera aplikacyjnego. Do czasu pojawienia się poprawki kluczowe pozostają działania kompensacyjne, ograniczenie ekspozycji endpointu i wzmożony monitoring prób wykorzystania podatności.