Mandiant i Google Threat Intelligence Group (GTIG) w analizie opublikowanej 25 września 2026 r. opisali ponowną masową eksploatację CVE-2026-35273 w Oracle PeopleSoft przez UNC6240 (ShinyHunters). Według badaczy nowa fala obchodziła część reguł WAF. Właściciel aplikacji biznesowej powinien więc potwierdzić poprawkę, sprawdzić, czy zabezpieczenie zastępcze działa, i przejrzeć ślady włamania.

Czy na pytanie o usunięcie podatności w PeopleSoft wystarczy odpowiedź, że dodano regułę WAF? Przy przeglądzie własnej aplikacji poprośmy o dowód wdrożenia poprawki oraz osobny wynik testu zabezpieczenia zastępczego. Punktem wyjścia jest ustalenie Mandiant i GTIG: badacze wykryli web shelle na dziesiątkach systemów w wielu sektorach. W rozmowie z administratorem skupmy się więc na tym, co rzeczywiście sprawdzono po zmianie konfiguracji. Jeżeli potwierdzenie dotyczy tylko włączenia reguły, pozostawmy otwarte pytanie, czy reguła blokuje atak i w jakim stanie jest sama aplikacja. Przegląd PeopleSoft powinien też objąć okres ekspozycji, ponieważ informacja o wykonaniu aktualizacji odpowiada na inne pytanie niż ustalenie, czy wcześniej doszło do włamania.

Zakodowana ścieżka podważyła założenia części reguł WAF

Według analizy Mandiant i GTIG obejście ochrony opierało się na różnicach w interpretacji zakodowanej ścieżki. Reguła WAF i aplikacja inaczej traktowały jej zapis, co pozwalało atakującym dotrzeć do podatnego elementu PeopleSoft. Opis dotyczy części reguł; nie daje podstaw do uznania wszystkich zabezpieczeń tego typu za nieskuteczne.

Przy teście własnej reguły WAF uwzględnijmy zatem sposób interpretacji ścieżki przez aplikację. Wynik powinien pokazywać, czy zabezpieczenie zatrzymuje również zakodowany zapis, a opis próby wskazywać sprawdzoną konfigurację. Samo potwierdzenie blokady jednego zapisu ścieżki nie powinno wystarczać do zatwierdzenia ochrony przed CVE-2026-35273.

Z tego mechanizmu wyprowadzamy praktyczny warunek odbioru zabezpieczenia: administrator PeopleSoft powinien wykazać, że test obejmuje założenie, na którym oparto blokadę. Jeżeli zakres próby pozostaje nieznany, zapiszmy ten brak w ocenie reguły WAF. Nie przypisujmy regule szerszej ochrony, niż potwierdzono podczas sprawdzenia.

Regułę WAF oceniajmy po wyniku testu jej założeń, a nie po samym fakcie wdrożenia.

Wpis o regule WAF nie potwierdza wdrożenia poprawki

W dokumentacji własnego PeopleSoft rozdzielmy potwierdzenie aktualizacji, wynik testu WAF oraz przegląd śladów włamania. Dla każdej pozycji wskażmy osobę odpowiedzialną i materiał, na którym oparto status. Gdy dostępna jest tylko informacja o zmianie reguły, stan wdrożenia poprawki dla CVE-2026-35273 oznaczmy jako niepotwierdzony.

Poprośmy wykonawcę o pokazanie wyniku przypisanego do konkretnej instalacji PeopleSoft. Jeżeli dokument przewiduje test reguły, ustalmy, czy rzeczywiście go wykonano i co obejmował. Rozbieżności między procedurą a wykonaniem zapiszmy jako zadania do wyjaśnienia przed zatwierdzeniem ochrony aplikacji.

Po potwierdzeniu aktualizacji PeopleSoft pozostawmy osobne zadanie dotyczące okresu ekspozycji. Jego zakres powinien obejmować poszukiwanie śladów włamania oraz ocenę sekretów związanych z aplikacją. Ustalenie badaczy o web shellach uzasadnia taki przegląd, ale nie rozstrzyga, czy do naszej instalacji ktoś się włamał. Tę odpowiedź zapiszmy dopiero na podstawie lokalnego sprawdzenia, z wyraźnym wskazaniem jego zakresu oraz brakujących danych.

Zabezpieczenie zastępcze PeopleSoft potrzebuje właściciela i terminu

Właściciel aplikacji powinien przypisać odpowiedzialność za utrzymywanie zabezpieczenia zastępczego dla CVE-2026-35273. W ustaleniu zapiszmy, kto odbiera wynik testu WAF, kto potwierdza poprawkę i kto zatwierdza zakończenie stosowania rozwiązania zastępczego. Dzięki takiemu zapisowi podczas przeglądu można sprawdzić konkretne zobowiązania wskazanych osób.

Datę wycofania zabezpieczenia zastępczego powiążmy z potwierdzonym wdrożeniem poprawki PeopleSoft. Jeśli aktualizacja pozostaje niepotwierdzona, właściciel powinien ponownie ocenić decyzję i określić termin uzupełnienia dowodów. Sam upływ wpisanej daty nie powinien uruchamiać usunięcia reguły WAF. Warunek zakończenia rozwiązania zastępczego musi być równie sprawdzalny jak warunek jego przyjęcia.

W informacji dla zarządu o PeopleSoft pokażmy zakres niewiedzy: brak potwierdzenia poprawki, nieprzetestowane założenia WAF albo nieprzejrzany okres ekspozycji. Każdy taki brak przypiszmy do zadania z wykonawcą i terminem.

Zabezpieczenie zastępcze dla PeopleSoft powinno mieć właściciela oraz datę wycofania zależną od potwierdzonej poprawki.

Polski właściciel PeopleSoft powinien sprawdzić własną ekspozycję

Analiza Mandiant i GTIG opisuje systemy w wielu sektorach na świecie, bez wskazania polskich ofiar. Polski właściciel PeopleSoft powinien potraktować ją jako przesłankę do kontroli swojej aplikacji. Globalny zakres obserwacji nie pozwala ustalić, czy atak dotknął konkretną organizację w Polsce.

Przegląd okresu ekspozycji PeopleSoft oprzyjmy na danych o własnej instalacji. Data 25 września oznacza publikację analizy; nie przyjmujmy jej automatycznie za początek ani koniec lokalnej ekspozycji. Jeśli granic tego okresu nie można potwierdzić, wskażmy to w zleceniu przeglądu zamiast zastępować brakującą wiedzę datą artykułu.

Ocenę sekretów uwzględnijmy w tym samym zleceniu dotyczącym PeopleSoft. Zapiszmy w nim odpowiedzialność za dalsze działania po sprawdzeniu. Nie zakładajmy ich przejęcia bez ustaleń dotyczących naszej aplikacji. Jeżeli przegląd nie pozwoli ocenić ich bezpieczeństwa, zapiszmy w raporcie dla właściciela PeopleSoft, że tego nie oceniono.

Co z tym zrobić w poniedziałek

Każdy z poniższych kroków dotyczących PeopleSoft zaplanuj na 30 minut. Wynikiem ma być konkretne ustalenie lub zlecenie dalszej pracy; pełna aktualizacja, test i przegląd śladów wymagają odrębnego zaplanowania.

  1. Sprawdź potwierdzenie poprawki dla CVE-2026-35273. Odszukaj zapis wdrożenia dla swojej instalacji i dowód jego weryfikacji. Jeśli ich brakuje, wpisz status „niepotwierdzone”, osobę odpowiedzialną i termin uzyskania potwierdzenia. Oddziel plan aktualizacji od jej udokumentowanego wykonania.
  2. Przejrzyj zakres testu reguły WAF. Sprawdź, czy obejmował interpretację zakodowanej ścieżki. Zapisz wynik albo zleć uzupełnienie próby i wskaż wykonawcę. Ustal właściciela zabezpieczenia zastępczego, planowaną datę wycofania i warunek potwierdzenia poprawki przed tym działaniem.
  3. Zleć przegląd okresu ekspozycji PeopleSoft. W krótkim opisie zadania uwzględnij ślady włamania, web shelle i ocenę sekretów. Wskaż znane granice okresu, braki danych, wykonawcę oraz termin przedstawienia ustaleń. Samo zlecenie przeglądu nie powinno otrzymać statusu potwierdzającego brak kompromitacji.

Przy PeopleSoft uzależniajmy akceptację zabezpieczenia zastępczego od dowodu, że działa, oraz od wskazanej odpowiedzialności. Decyzję o jego wycofaniu oprzyjmy na potwierdzeniu poprawki dla CVE-2026-35273. Przegląd śladów z okresu ekspozycji zakończmy własnym ustaleniem, z opisem tego, czego nie udało się sprawdzić.

Źródła

Redakcja cyberinsight.pl.