Wprowadzenie do problemu / definicja
W LibreOffice oraz Apache OpenOffice ujawniono podatności, które umożliwiają uruchomienie kodu z poziomu odpowiednio przygotowanego arkusza kalkulacyjnego bez wyświetlania klasycznego ostrzeżenia o makrach. Problem dotyczy sposobu, w jaki aplikacje obsługują zewnętrzne źródła danych, pliki bazodanowe ODB oraz komponenty Java ładowane w ramach legalnych funkcji programu.
Z perspektywy użytkownika zagrożenie jest szczególnie istotne, ponieważ otwarcie dokumentu może uruchomić łańcuch działań prowadzących do wykonania kodu bez typowych sygnałów ostrzegawczych. Oznacza to obejście jednego z najczęściej rozpoznawanych mechanizmów ochronnych stosowanych przy pracy z dokumentami biurowymi.
W skrócie
- Podatności dotyczą arkuszy Calc w LibreOffice i Apache OpenOffice.
- Atak nie wykorzystuje klasycznych makr, ale legalne mechanizmy importu danych i obsługi Java.
- LibreOffice załatał lukę oznaczoną jako CVE-2026-63277.
- Zalecana aktualizacja LibreOffice to wersja 26.2.5 lub 26.8.0.
- Apache OpenOffice pozostaje podatny w wersjach do 4.1.16 włącznie w ramach CVE-2026-59265.
- Warunkiem powodzenia ataku jest włączona obsługa Java.
- Opublikowano działający proof-of-concept, choć brak potwierdzeń aktywnego wykorzystywania luk w kampaniach.
Kontekst / historia
Scenariusz ataku zwrócił uwagę badaczy, ponieważ omija klasyczny model zagrożeń kojarzony z dokumentami biurowymi. Przez lata organizacje koncentrowały się głównie na blokowaniu makr i szkoleniu użytkowników, by nie ufali plikom proszącym o ich uruchomienie. W tym przypadku problem leży jednak w zestawieniu kilku natywnych funkcji aplikacji, które same w sobie nie są traktowane jak jednoznacznie niebezpieczne.
Badacze pokazali, iż odpowiednio przygotowany arkusz może wykorzystać automatyczne odświeżanie danych zewnętrznych, a następnie skierować aplikację do pobrania dodatkowych komponentów. LibreOffice udostępnił już poprawki bezpieczeństwa, natomiast Apache OpenOffice zapowiedział usunięcie błędu w przyszłym wydaniu. To kolejny przykład, iż powierzchnia ataku w pakietach biurowych wykracza daleko poza same makra.
Analiza techniczna
Rdzeń ataku stanowi mechanizm database range w arkuszach Calc, czyli zakres komórek powiązany z zewnętrznym źródłem danych. Taki zakres może zostać skonfigurowany do automatycznego odświeżania po otwarciu dokumentu. Złośliwy arkusz wskazuje zdalny plik ODB dostępny przez sieć, który następnie jest pobierany przez aplikację.
Po załadowaniu pliku ODB możliwe jest wskazanie sterownika JDBC oraz lokalizacji jego kodu. Ta lokalizacja może prowadzić do zdalnego pliku JAR zawierającego kod Java. W praktyce pakiet biurowy pobiera wskazany komponent i inicjalizuje go w kontekście własnego procesu, co otwiera drogę do uruchomienia dowolnej logiki dostarczonej przez atakującego.
Kluczowe jest to, iż nie dochodzi tu do wykonania makra w tradycyjnym sensie. Z punktu widzenia mechanizmów ochronnych uruchamiane są legalne funkcje związane z importem danych i obsługą sterowników bazodanowych. W efekcie użytkownik może nie otrzymać komunikatu, który zwykle wzbudzałby podejrzenia.
W demonstracji badacze wykorzystali nieszkodliwe działanie polegające na uruchomieniu kalkulatora systemowego. Ten sam łańcuch może jednak zostać użyty do pobrania kolejnych komponentów, wykonania poleceń systemowych, uzyskania trwałości lub przygotowania gruntu pod dalszy ruch boczny. Testy przeprowadzono w środowiskach Windows i Linux, co wskazuje na wieloplatformowy charakter zagrożenia.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem jest możliwość zdalnego wykonania kodu po samym otwarciu spreparowanego arkusza. Dla kampanii phishingowych to szczególnie atrakcyjny scenariusz, ponieważ brak ostrzeżenia o makrach może zwiększyć wiarygodność dokumentu w oczach odbiorcy.
W środowisku firmowym podatność może prowadzić do przejęcia stacji roboczej, instalacji złośliwego oprogramowania, kradzieży danych lub uruchomienia kolejnych etapów ataku. Dodatkowym problemem jest to, iż wykorzystywany mechanizm bazuje na funkcjach biznesowych obecnych w zwykłym obiegu dokumentów, co utrudnia wykrywanie anomalii wyłącznie na podstawie zachowania pliku.
Szczególnie narażone pozostają organizacje korzystające z Apache OpenOffice, dla którego w momencie ujawnienia informacji nie było jeszcze dostępnej poprawki. W takim przypadku poziom ochrony zależy głównie od konfiguracji środowiska, wyłączenia Java tam, gdzie to możliwe, oraz skuteczności kontroli ruchu i zachowań aplikacji biurowych.
Rekomendacje
Organizacje używające LibreOffice powinny w pierwszej kolejności przeprowadzić aktualizację do wersji zawierających poprawkę i zweryfikować, czy podatne wydania nie pozostają w użyciu na stacjach roboczych. W środowiskach o podwyższonym ryzyku warto potraktować ten proces priorytetowo.
Użytkownicy Apache OpenOffice powinni tymczasowo wyłączyć obsługę Java, jeżeli nie jest ona niezbędna operacyjnie. Do czasu publikacji poprawki należy także ograniczyć otwieranie niezweryfikowanych arkuszy pochodzących z poczty elektronicznej, komunikatorów oraz zewnętrznych repozytoriów plików.
- blokowanie lub inspekcja ruchu wychodzącego inicjowanego przez aplikacje biurowe,
- monitorowanie pobierania plików JAR oraz nietypowych połączeń sieciowych wykonywanych przez pakiety biurowe,
- wdrożenie reguł EDR lub XDR wykrywających uruchamianie procesów potomnych przez aplikacje biurowe,
- ograniczenie lokalnych uprawnień administracyjnych użytkowników końcowych,
- szkolenia uświadamiające, iż aktywna zawartość dokumentów nie ogranicza się wyłącznie do makr,
- dodanie tego scenariusza do działań threat huntingowych prowadzonych przez zespoły SOC i IR.
W analizie incydentów warto zwracać uwagę na ciąg zdarzeń obejmujący otwarcie arkusza, następnie połączenia HTTP lub pobieranie artefaktów Java, a w dalszej kolejności wykonanie procesów systemowych z kontekstu pakietu biurowego.
Podsumowanie
Luki w LibreOffice i Apache OpenOffice pokazują, iż zagrożenia związane z dokumentami biurowymi nie kończą się na makrach. Połączenie automatycznego odświeżania danych zewnętrznych, plików ODB i sterowników JDBC może doprowadzić do wykonania kodu bez standardowych ostrzeżeń bezpieczeństwa.
Dla LibreOffice dostępna jest już poprawka, natomiast użytkownicy Apache OpenOffice powinni wdrożyć środki tymczasowe, przede wszystkim wyłączenie Java oraz bardziej restrykcyjne podejście do nieznanych arkuszy. Dla organizacji to istotny sygnał, iż polityki bezpieczeństwa dokumentów muszą obejmować również mniej oczywiste funkcje aplikacyjne.