--- service: "Publicasta" schema_version: "1.0" article_id: 577 title: "Luki w jądrze SAP z września 2026 r. wymagają inwentaryzacji i pilnego łatania" language: "pl" default_language: "en" canonical_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=pl" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=pl" api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/sap_overpass_s4get_september_2026_patch_day_response?lang=pl" channel_url: "https://publicasta.com/api/public/v1/channels/cybersecurity" channel_articles: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-10T13:50:50+00:00" updated_at: "2026-09-10T13:50:50+00:00" translations: - language: "ar" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=ar" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=ar" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=ar" - language: "de" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=de" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=de" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=de" - language: "en" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=en" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=en" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=en" - language: "es" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=es" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=es" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=es" - language: "fr" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=fr" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=fr" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=pl" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=pl" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=ru" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=ru" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=zh" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=zh" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=zh" --- # Luki w jądrze SAP z września 2026 r. wymagają inwentaryzacji i pilnego łatania > Dwie krytyczne luki SAP ujawnione 8 września dotyczą podstawowych ścieżek komunikacji i mogą zagrozić całemu środowisku ERP. Sprawdź, co wiadomo, czego nie wiadomo i jak potwierdzić ekspozycję bez czekania na doniesienia o exploitach. Wrześniowy SAP Security Patch Day 2026 obejmuje dwie krytyczne luki, którym organizacje korzystające ze środowisk SAP powinny poświęcić natychmiastową uwagę. Pierwsza to luka o maksymalnym poziomie krytyczności w SAP Kernel, związana z przetwarzaniem Extended Passport. Otrzymała oznaczenie CVE-2026-44756, a laboratoria Onapsis Research Labs nadały jej nazwę OVERPASS. Druga, CVE-2026-58240, dotyczy serwera komunikatów SAP NetWeaver i jest określana jako S4GET. W obu przypadkach podatne systemy można osiągnąć zdalnie, bez uwierzytelnienia. ![Serwerownia przedsiębiorstwa z abstrakcyjną mapą sieci i wskaźnikami poprawek bezpieczeństwa](https://publicasta.com/storage/projects/9/pages/577/2026/09/0eecf113-0be8-4e9f-9929-205dcb47ba8d.webp) Nie chodzi o to, że każda instalacja SAP została już przejęta. Problem polega na tym, że luki znajdują się we współdzielonej infrastrukturze wykorzystywanej przez wiele ścieżek komunikacji. Część z nich administratorzy mogą uznawać za chronioną tylko dlatego, że główna aplikacja biznesowa nie jest bezpośrednio wystawiona do publicznego internetu. Pierwszym zadaniem nie powinno więc być oczekiwanie na głośny raport o włamaniu. Trzeba ustalić, jakie komponenty jądra i serwera komunikatów działają w środowisku, czy są osiągalne z wrogich sieci oraz czy poprawki producenta rzeczywiście zainstalowano i uruchomiono. Ten artykuł koncentruje się na pytaniu obronnym: jak właściciel środowiska SAP może przełożyć ostrzeżenie o wysokiej wadze na dowody dotyczące własnej infrastruktury? ## Co SAP ujawnił 8 września SAP publikuje regularny Security Patch Day w drugi wtorek każdego miesiąca. Biuletyn z września 2026 r. zawiera odpowiednie noty bezpieczeństwa, wersje podatnych produktów oraz poprawki dla wspieranych wydań. Opisywane problemy nie są zwykłymi błędami aplikacji ograniczonymi do jednej opcjonalnej funkcji biznesowej. Dotyczą SAP Kernel i serwera komunikatów NetWeaver, czyli komponentów znajdujących się pod wieloma produktami i protokołami. CVE-2026-44756 opisuje SAP Security Note 3747649. Źródłem problemu jest niewystarczająca walidacja granic podczas przetwarzania danych Extended Passport przez SAP Kernel. Extended Passport to struktura śledzenia przenoszona wraz z żądaniami. W podatnej implementacji spreparowane dane mogą doprowadzić do uszkodzenia pamięci lub innego nieokreślonego zachowania. Rekord CVE opisuje warunek osiągalny przez sieć, z dużym wpływem na poufność, integralność i dostępność. Onapsis ocenia, że praktycznym skutkiem może być wykonanie poleceń systemu operacyjnego na hoście SAP. CVE-2026-58240 opisuje SAP Security Note 3759472. Luka dotyczy braku kontroli uwierzytelnienia w serwerze komunikatów SAP NetWeaver, konkretnie w komponencie oznaczonym BC-CST-MS. Serwer komunikatów koordynuje rejestrację serwerów aplikacyjnych i komunikację w środowisku SAP. Jeżeli system uzna nieautoryzowany komponent za zaufany, granica przeznaczona dla wewnętrznych członków klastra może stać się drogą do szerszego przejęcia. Nie chodzi tu o Europejską Agencję ds. Cyberbezpieczeństwa. Odpowiednie podsumowanie techniczne pochodzi od CERT-EU, zespołu reagowania na incydenty komputerowe dla instytucji, organów, biur i agencji Unii Europejskiej. CERT-EU ocenia ryzyko operacyjne jako poważne, ponieważ obie luki można wykorzystać zdalnie, bez uwierzytelnienia, i zaleca jak najszybsze zastosowanie obu not bezpieczeństwa SAP. ## Dlaczego luka w jądrze wykracza poza jeden punkt końcowy Nazwa OVERPASS może sugerować wąski błąd pojedynczej funkcji. To mylące. Obsługa Extended Passport jest wspólną funkcjonalnością jądra. Onapsis podaje, że podatne przetwarzanie może być osiągalne przez więcej niż jeden protokół i więcej niż jedną warstwę komunikacji z SAP. Wskazywane ścieżki obejmują warstwę internetową, komunikację związaną z SAP GUI oraz połączenia RFC między systemami SAP. Nie oznacza to, że każdy protokół jest wystawiony w każdej instalacji. Oznacza jednak, że stwierdzenie w rodzaju: „interfejs WWW SAP działa za VPN-em” nie wystarcza do zamknięcia dochodzenia. Ten sam kod jądra może znajdować się w systemie osiągalnym przez reverse proxy, rozwiązanie zdalnego dostępu, połączenie partnerskie, wewnętrzny segment integracyjny albo inny system SAP. Właściwe pytanie brzmi: które podatne pliki binarne jądra są zainstalowane, jakie interfejsy je ładują i jakie podmioty sieciowe mogą do nich dotrzeć? To rozróżnienie ma znaczenie podczas triage. Luka może nie wymagać uwierzytelnienia, a jednocześnie nie być publicznie dostępna z internetu. Wystarczyć może atakujący wewnętrzny, przejęta stacja robocza, naruszona sieć partnera albo źle odseparowana strefa zarządzania, jeśli odpowiednia usługa jest osiągalna. Z drugiej strony usługa rzeczywiście odizolowana nadal wymaga załatania, ponieważ założenia dotyczące izolacji mogą się zmienić, a podatny komponent może zostać ponownie użyty po zmianie architektury. Onapsis celowo nie opublikował szczegółów exploita w publicznym ostrzeżeniu. Dla obrońców to użyteczne: informacji wystarcza do ustalenia priorytetów, ale nie zamieniają one artykułu informacyjnego w instrukcję eksploatacji. Nieobecność publicznego proof of concept nie powinna jednak być powodem do odkładania działań. ## Dlaczego S4GET zmienia dyskusję o granicy zaufania Druga luka ma inny mechanizm, lecz podobne konsekwencje. Serwer komunikatów NetWeaver koordynuje komponenty klastra SAP. Taka konstrukcja wymaga odróżnienia prawidłowych serwerów aplikacyjnych od systemów nieautoryzowanych. CVE-2026-58240 wskazuje, że w podatnych wersjach odpowiednia kontrola uwierzytelnienia jest niewystarczająca. Według podsumowania CERT-EU, przygotowanego na podstawie ustaleń badacza, nieuwierzytelniony napastnik mający dostęp do sieci może zarejestrować nieautoryzowany komponent. Onapsis opisuje ryzyko jako możliwość przedstawienia się przez napastnika jako zaufany węzeł i rozpropagowania tego zaufania w klastrze. W razie powodzenia skutkiem może być między innymi wykonanie poleceń systemu operacyjnego z użyciem konta uruchamiającego SAP. Dlatego tak ważna jest lokalizacja sieciowa. Serwer komunikatów nie jest po prostu kolejnym portem, który można zamknąć po zainstalowaniu poprawki. Należy do płaszczyzny sterowania środowiskiem SAP. Jeśli można do niego dotrzeć z sieci użytkowników, szerokiego segmentu serwerowego, sieci partnera albo internetu, liczba osiągalnych podmiotów staje się częścią kalkulacji ryzyka. Filtrowanie sieciowe jest jednak kontrolą kompensującą, a nie zamiennikiem poprawki producenta. Może zmniejszyć ekspozycję na czas przygotowania zmiany, ale nie naprawi wadliwej kontroli zaufania. Onapsis zwraca również uwagę na trudne ograniczenie operacyjne: podatna ścieżka może być powiązana z tym samym publicznie dostępnym portem, którego używają klienci SAP GUI. Nieprzemyślane zablokowanie portu może przerwać prawidłowe logowanie. To ostrzeżenie przed awaryjnymi zmianami zapory wykonywanymi bez udziału właściciela aplikacji. Reakcja powinna łączyć łatanie, sprawdzoną mapę ekspozycji oraz precyzyjnie zakresowane ograniczenia, które zachowują wymagany ruch biznesowy. ## Co jest podatne Listy podatnych wersji są techniczne i należy je porównywać z dokładną inwentaryzacją komponentów SAP, a nie z nazwą produktu wpisaną do skanera. CERT-EU podaje dla CVE-2026-44756 następujące szerokie rodziny wersji: KRNL64NUC 7.22 i 7.22EXT; KRNL64UC 7.22, 7.22EXT, 7.53 i 8.04; KERNEL 7.22, 7.53, 7.54, 7.77, 7.89, 7.93, 8.04, 9.16, 9.18, 9.19 i 9.20; a także WEBDISP 9.16, 9.18, 9.19 i 9.20. Dokładna podatna kompilacja oraz kompilacja poprawiona zależą od noty bezpieczeństwa SAP i kombinacji platformy. W przypadku CVE-2026-58240 podatne rodziny wskazane przez CERT-EU to KERNEL 9.16, 9.18, 9.19 i 9.20. Problem wiąże się z komponentem serwera komunikatów NetWeaver BC-CST-MS. Ogólne wyszukiwanie „serwerów SAP” doprowadzi więc zarówno do fałszywych alarmów, jak i przeoczeń, jeśli nie zostanie powiązane z danymi o zainstalowanych komponentach i poziomie poprawek. Tych list nie należy traktować jako pozwolenia na wnioskowanie o bezpieczeństwie na podstawie innego ciągu wersji. Środowiska SAP często obejmują wiele systemów, stare pliki binarne jądra pozostawione dla zgodności, serwery aplikacyjne na różnych poziomach poprawek, web dispatchery, środowiska deweloperskie i jakościowe oraz połączenia między systemami, których nie ma w tej samej ewidencji co zasobów internetowych. Kompletna reakcja musi uwzględnić wszystkie te elementy. ## Status wykorzystania: pilne działanie nie oznacza potwierdzonego włamania Publiczne dowody dostępne 9 września nie potwierdzają, że któraś z luk jest wykorzystywana masowo w środowisku produkcyjnym. Onapsis podało, że w chwili publikacji swojego ostrzeżenia nie zaobserwowało aktywnego wykorzystania OVERPASS. CERT-EU zaleca natychmiastową remediację, ponieważ techniczny wpływ i brak uwierzytelnienia przy zdalnym dostępie czynią luki wysoce ryzykownymi, a nie dlatego, że raportuje potwierdzoną kampanię przeciwko wszystkim klientom SAP. To rozróżnienie warto zachować. „Krytyczna” to sygnał dotyczący dotkliwości i priorytetu. „Aktywnie wykorzystywana” opisuje obserwowane zachowanie napastników. Te pojęcia nie są wymienne. Odpowiedzialny proces reagowania na incydenty nie powinien ogłaszać włamania na podstawie samego wyniku CVSS ani odrzucać CVE dlatego, że nie udokumentowano jeszcze publicznej kampanii. Zespoły bezpieczeństwa powinny śledzić aktualizacje producenta, komunikaty CERT-EU lub krajowych CERT-ów oraz własną telemetrię. Lokalny materiał dowodowy jest cenniejszy niż ogólne rozmowy w internecie: niespodziewane rejestracje w serwerze komunikatów, nowe procesy uruchomione na koncie systemu operacyjnego SAP, nietypowa aktywność administracyjna, niewyjaśnione zmiany profili lub plików jądra, anomalne połączenia RFC oraz ruch wychodzący z hostów SAP do miejsc, z których firma nie korzysta, powinny prowadzić do eskalacji. Same wskaźniki nie są dowodem, ale pomagają rozstrzygnąć, czy wystarczy łatanie, czy potrzebna jest obsługa incydentu. ## Praktyczna kolejność działań ### 1. Wyznacz właściciela i przestań opierać się na założeniach Wyznacz jedną osobę lub zespół odpowiedzialny za koordynację administratorów SAP Basis, operacji bezpieczeństwa, inżynierii sieciowej oraz właściciela biznesowego systemu. Koordynator powinien rejestrować decyzje i znaczniki czasu. Zapobiega to częstej awarii w korporacyjnym procesie łatania: zespół Basis uważa, że za ekspozycję odpowiada sieć, zespół sieciowy zakłada, że aplikacja została już załatana, a nikt nie ma dowodu, że zmienił się działający proces. Nie zaczynaj wyłącznie od ogólnego skanowania podatności. Zacznij od autorytatywnej ewidencji systemów SAP i potwierdź, które systemy rzeczywiście działają. Uwzględnij produkcję, odtwarzanie po awarii, zapewnienie jakości, rozwój, piaskownice, huby integracyjne, web dispatchery oraz systemy tymczasowe używane podczas migracji lub testów. ### 2. Zmapuj podatne pliki binarne i aktywne ścieżki sieciowe Dla każdego systemu zapisz rodzinę zainstalowanego jądra, dokładny poziom poprawek, system operacyjny, obecność serwera komunikatów, obecność web dispatchera, ekspozycję SAP GUI lub RFC oraz strefy sieciowe, z których można dotrzeć do odpowiednich usług. Porównaj zainstalowaną wersję z poprawioną wersją wskazaną w SAP Security Notes 3747649 i 3759472. Mapa powinna odpowiadać na konkretne pytania: Czy któraś z usług jest przypięta do adresu routowalnego z zewnątrz? Czy stacja robocza użytkownika może połączyć się z nią bezpośrednio? Czy dostęp ma sieć partnera lub integracji? Czy istnieją alternatywne drogi przez load balancer, reverse proxy, koncentrator VPN, host bastionowy albo grupę bezpieczeństwa w chmurze? Czy produkcja i systemy nieprodukcyjne są odseparowane w sposób, który niedawno sprawdzono? Rejestruj dowody, nie tylko wnioski. Zgłoszenie z treścią „brak ekspozycji” jest słabe. Zgłoszenie wskazujące interfejs, regułę zapory, datę ostatniej walidacji i zatwierdzającego właściciela można ponownie ocenić po zmianie architektury. ### 3. Zastosuj poprawki producenta, uruchom system ponownie i zweryfikuj wynik Postępuj zgodnie z opublikowanymi notami bezpieczeństwa SAP i procesem zmian obowiązującym w organizacji. Aktualizacje jądra często wymagają koordynacji między instancjami, systemami operacyjnymi, układami wysokiej dostępności i oknami serwisowymi. Skopiowanie pliku na serwer nie oznacza, że działający proces korzysta z poprawionej kompilacji. Po zmianie zweryfikuj działającą wersję na każdej istotnej instancji. Sprawdź, czy wszystkie serwery aplikacyjne w klastrze używają właściwego poziomu jądra. Osobno sprawdź web dispatchery i inne komponenty. Potwierdź, że nie pominięto węzła przełączania awaryjnego, środowiska odtwarzania po awarii ani instancji wyglądającej na nieaktywną. Jeśli środowisko wykorzystuje automatyzację, zachowaj wynik wdrożenia i porównaj go z niezależnym dowodem z uruchomionego systemu. Kryterium powodzenia nie brzmi: „zadanie instalacji poprawki zakończyło się”. Brzmi: „każda objęta zakresem usługa działa z poprawioną wersją, zmianę zarejestrowano, a ocena osiągalności nadal odpowiada wdrożonej architekturze”. ### 4. Stosuj tymczasowe zabezpieczenia podczas przygotowywania poprawki Jeśli natychmiastowa aktualizacja jest niemożliwa, ogranicz ekspozycję, ale nie zakładaj, że środek tymczasowy usuwa błąd. Ogranicz dostęp do usług SAP do najmniejszego zestawu autoryzowanych sieci. Usuń zbędną ekspozycję internetową. Jeśli pozwala na to projekt biznesowy, ogranicz interfejsy administracyjne i ścieżki serwera komunikatów z sieci użytkowników i partnerów. Sprawdź reguły reverse proxy oraz load balancera, zamiast zmieniać wyłącznie zaporę na serwerze. W przypadku S4GET zachowaj szczególną ostrożność przy szerokim blokowaniu portów. Reguła, która przerywa komunikację SAP GUI lub klastra, może wywołać incydent dostępności, a mimo to nie usunąć każdej drogi do podatnego komponentu. Zmiany wprowadzaj wspólnie z właścicielem SAP Basis, testuj je względem wymaganego ruchu i zachowaj plan wycofania. Jeżeli systemu nie można szybko załatać, udokumentuj przyczynę, zabezpieczenia kompensujące, osobę akceptującą ryzyko oraz termin ponownej oceny. „Załatamy później” nie jest planem ograniczenia ryzyka. ### 5. Sprawdź oznaki przejęcia Łatanie jest konieczne nawet wtedy, gdy nie ma podejrzanych wskaźników. Nie wystarcza natomiast, jeśli istnieje możliwość wcześniejszego dostępu do systemu. Przejrzyj tworzenie procesów w systemie operacyjnym, integralność plików, zadania zaplanowane, definicje usług, dzienniki audytu bezpieczeństwa SAP, logi serwera komunikatów i aplikacji, zdarzenia uwierzytelnienia, zmiany administracyjne oraz połączenia sieciowe z okresu poprzedzającego poprawkę. Zachowaj odpowiednie logi, zanim usuną je okna retencji. Przegląd powinien obejmować konta systemu operacyjnego SAP i uprzywilejowanych użytkowników SAP, ale nie może na tym poprzestać. Napastnik, który dotarł do hosta, może manipulować systemem operacyjnym bez tworzenia oczywistego logowania dialogowego SAP. Szukaj niewyjaśnionych plików binarnych, zmodyfikowanych skryptów startowych, nowych kont lokalnych, nietypowych połączeń wychodzących oraz zmian lokalizacji lub właściciela plików jądra. Jeśli dowody wskazują na przejęcie, izoluj system ostrożnie, wspólnie z zespołem reagowania na incydenty i właścicielem SAP. Nie kasuj maszyny ani nie rotuj wszystkich danych uwierzytelniających w ciemno, zanim nie zbierzesz dowodów potrzebnych do ustalenia zakresu. Rotacja poświadczeń, decyzja o odbudowie systemu i działania związane z ciągłością biznesową powinny wynikać z procedury obsługi incydentu. ## Co ostrzeżenie oznacza dla poszczególnych zespołów Administratorzy SAP Basis powinni potraktować obie noty bezpieczeństwa jako zadanie obejmujące całą inwentaryzację i łatanie krajobrazu SAP. Największym zagrożeniem jest pozostawienie jednej instancji, dispatchera albo środowiska odtwarzania. Zespół Basis powinien również potwierdzić, że poprawione jądro działa, zamiast ufać wyłącznie statusowi systemu wdrożeniowego. Zespoły sieciowe powinny zweryfikować rzeczywiste trasy do usług SAP, także te, które nie wyglądają jak typowa ekspozycja internetowa. Należy przejrzeć grupy bezpieczeństwa, load balancery, polityki VPN, połączenia partnerskie oraz segmentację między sieciami użytkowników, serwerów, rozwoju i zarządzania. Nie należy wykonywać jednowierszowej zmiany zapory bez zrozumienia komunikacji klastra i klientów SAP. Zespoły operacji bezpieczeństwa powinny rozszerzyć monitoring o podejrzaną aktywność wokół hostów SAP i kont systemu operacyjnego. Powinny porównać czas ujawnienia informacji z lokalną telemetrią i zachować dowody, póki logi są dostępne. Zgłoszenie podatności i zgłoszenie incydentu to różne obiekty; jedno nie zastępuje drugiego. Zespoły tożsamości i dostępu powinny przejrzeć uprzywilejowane konta SAP i systemu operacyjnego, jeśli pojawią się oznaki wykorzystania luki. Załatanie oprogramowania nie cofa poleceń, które mogły już zostać wykonane, poświadczeń, które mogły zostać odczytane, ani relacji zaufania, które mogły zostać zmienione. Właściciele biznesowi powinni pomóc zdecydować, które systemy wymagają awaryjnego okna serwisowego, a jaki ruch jest rzeczywiście potrzebny. SAP często obsługuje finanse, produkcję, logistykę, płace, zakupy lub operacje klientów. Reakcja powinna być szybka, lecz pośpieszna awaria może stworzyć własne poważne ryzyko. ## Pytania, na które trzeba odpowiedzieć przed zamknięciem zgłoszenia Rzetelny zapis zamknięcia powinien odpowiadać na wszystkie poniższe pytania: - Które systemy SAP i rodziny jądra sprawdzono? - Które instancje, web dispatchery i serwery komunikatów objęto zakresem? - Jakie dokładne działające wersje zaobserwowano przed aktualizacją i po niej? - Które systemy były osiągalne z internetu, sieci użytkowników, sieci partnerów lub innych systemów SAP? - Czy Security Notes 3747649 i 3759472 zastosowano wszędzie, gdzie było to właściwe? - Czy zweryfikowano wszystkich członków klastra, systemy zapasowe i środowiska odtwarzania po awarii? - Jakich tymczasowych kontroli sieciowych użyto i kto je zatwierdził? - Jakie logi i dane telemetryczne przejrzano pod kątem możliwego wykorzystania? - Czy przegląd wykazał niewyjaśnione procesy, rejestracje, działania administracyjne lub połączenia wychodzące? - Kto zaakceptował pozostałe ryzyko i kiedy zostanie ono ponownie ocenione? Jeśli odpowiedź na którekolwiek pytanie brzmi „nie wiemy”, praca nie jest zakończona. Nadal może być rozsądne przejście do kolejnego kroku operacyjnego, ale niepewność musi zostać wyraźnie zapisana. ## Spokojny wniosek OVERPASS i S4GET są poważne, ponieważ łączą duży potencjalny wpływ ze zdalnym, nieuwierzytelnionym dostępem do współdzielonej infrastruktury SAP. Nie są powodem, by zakładać, że każdy klient SAP został zaatakowany. Publiczne informacje dostępne 9 września nie potwierdzają szerokiego wykorzystania tych luk w środowisku produkcyjnym. Są natomiast powodem, by przestać traktować łatanie jądra SAP jako wąskie zadanie utrzymaniowe. Właściwa reakcja jest metodyczna: zinwentaryzować rzeczywisty krajobraz, zmapować rzeczywiste trasy, zastosować poprawki SAP, ponownie uruchomić i zweryfikować każdy podatny komponent, używać precyzyjnie zakresowanych ograniczeń sieciowych podczas zmiany oraz przejrzeć telemetrię pod kątem wcześniejszego dostępu. Taka kolejność daje coś cenniejszego niż panika albo fałszywe uspokojenie: udokumentowaną odpowiedź na pytanie, co jest wystawione, co naprawiono i czym trzeba się jeszcze zająć. ### Źródła i zakres Fakty techniczne przedstawione w tym artykule opierają się na materiałach SAP Security Patch Day z września 2026 r., ostrzeżeniu CERT-EU dotyczącym obu luk, komunikatach Onapsis Research Labs związanych z odpowiedzialnym ujawnieniem oraz publicznych rekordach CVE wskazanych przez CERT-EU. Remediacja zależna od konkretnego produktu powinna przebiegać zgodnie z aktualnymi notami bezpieczeństwa SAP dostępnymi na koncie klienta SAP Support.