Dwie krytyczne luki — jedna we wbudowanej usłudze pulpitu zdalnego Apple, druga w platformie e-commerce SAP — w mniej niż tydzień przeszły od biuletynu bezpieczeństwa do rzeczywistych ataków. Okno na łatanie liczy się dziś w dniach, a nie miesiącach.
Sierpień 2026 roku przyniósł dwie historie o wykorzystaniu luk, które należy zestawić obok siebie. W pierwszej atakujący przejmują uprawnienia roota na Macach wystawionych do Internetu przez obejście uwierzytelniania w macOS Screen Sharing i instalują koparki kryptowalut. W drugiej atakujący zaczęli sondować lukę zdalnego wykonania kodu o maksymalnej krytyczności w SAP Commerce Cloud zaledwie trzy dni po tym, jak SAP udostępnił poprawkę.
Żadna z tych luk nie jest podręcznikowym zero-dayem. Obie zostały załatane zanim zaobserwowano publiczne wykorzystanie. Ta różnica ma znaczenie i jest prawdopodobnie bardziej niewygodnym wnioskiem: atakujący nie potrzebowali tajnego exploita ani nieznanego błędu. Potrzebowali opublikowanego biuletynu i organizacji, które jeszcze go nie zastosowały.
Co się stało
macOS Screen Sharing — CVE-2026-65400
Apple wydało aktualizację poza cyklem 6 sierpnia 2026 roku, naprawiającą lukę uwierzytelniania w Screen Sharing, funkcji pulpitu zdalnego wbudowanej w macOS. Apple opisało problem jako kwestię uwierzytelniania rozwiązaną przez ulepszone zarządzanie stanem i udostępniło poprawki w macOS Tahoe 26.6.1, macOS Sequoia 15.7.9 i macOS Sonoma 14.8.9.
Holenderskie Narodowe Centrum Cyberbezpieczeństwa (NCSC-NL) opublikowało następnego dnia komunikat nawołujący organizacje do aktualizacji. 12 sierpnia zmieniło ten komunikat, aby potwierdzić coś poważniejszego: otrzymało zgłoszenie o aktywnym nadużyciu wobec wielu systemów, w których port TCP 5900 był osiągalny z Internetu. W każdym przypadku zgłoszonym agencji atakujący uzyskali dostęp roota i zainstalowali koparkę kryptowaluty Monero.
Ocena krytyczności została od tego czasu przepisana. CISA pierwotnie oceniła lukę na 7,1 6 sierpnia, używając wektora zakładającego, że atakujący potrzebuje pewnego poziomu uprawnień i może osiągnąć tylko częściowy wpływ. 14 sierpnia CISA zastąpiła go wektorem niewymagającym żadnych uprawnień i dającym pełne naruszenie poufności, integralności i dostępności — podnosząc ocenę do 9,8 (krytyczna). Dzień później jej ocena luki zmieniła się z „niepodlegającej automatyzacji” na podlegającą automatyzacji, co jest zgodne z masowym przejmowaniem nienadzorowanych Maców w celu kopania kryptowalut.
CVE-2026-65400 nie jest też odosobnionym błędem. Pod koniec lipca Apple załatało co najmniej cztery inne problemy w screensharingd, demonie stojącym za Screen Sharing. Trzy otrzymały identyfikatory CVE. Według doniesień czwarty został naprawiony po cichu i był najpoważniejszy w grupie, pozwalając nieuwierzytelnionym atakującym na zdalne wykonanie kodu jako root.
SAP Commerce Cloud — CVE-2026-58231
11 sierpnia 2026 roku, w ramach sierpniowego Security Patch Day, SAP opublikowało Security Note 3771065, dotyczącą luki w rozszerzeniu Data Hub Adapter dla SAP Commerce Cloud. Luka ma wynik CVSS 10,0 — maksymalny możliwy.
Trzy dni później, 14 sierpnia, firma zajmująca się analizą zagrożeń Defused zgłosiła pierwsze próby wykorzystania trafiające w jej honeypoty. W tym momencie nie było publicznego exploita proof-of-concept ani wcześniejszego zgłoszenia nadużyć w środowisku naturalnym. KEVIntel, który obsługuje własne sensory i prywatne honeypoty, niezależnie potwierdził obserwowanie ataków i odnotował 15 sierpnia, że PoC stał się od tego czasu dostępny. SAP powiedziało BleepingComputer, że zna te doniesienia i prowadzi analizę.
Dotknięte wersje to SAP Commerce Cloud COM_CLOUD 2211 i COM_CLOUD 2211-JDK21. W chwili pisania tego tekstu ani CVE-2026-58231, ani CVE-2026-65400 nie zostały dodane do katalogu Known Exploited Vulnerabilities CISA.
Jak działają ataki
Mówiąc prosto, obie luki pozwalają atakującemu ominąć drzwi frontowe.
macOS Screen Sharing używa protokołu VNC na porcie 5900 i opiera się na procesie uwierzytelniania typu wyzwanie–odpowiedź (Secure Remote Password), aby zweryfikować, kto się łączy. Analiza firmy bezpieczeństwa Huntress wykazała, że atakujący może sprawić, by usługa traktowała nieuwierzytelnione połączenie tak, jakby przeszło już uwierzytelnianie — to desynchronizacja maszyny stanów. Połączenie jest następnie obsługiwane z uprzywilejowanym dostępem.
Kluczowy szczegół operacyjny: ponieważ obejście następuje przed oceną normalnego uwierzytelniania, kroki utwardzania, po które sięgnęłaby większość administratorów, nic nie dają. Zmiana hasła Screen Sharing, wyłączenie starszego dostępu hasłem VNC i usunięcie autoryzowanych kont użytkowników znajdują się za ścieżką kodu, którą luka pokonuje. Atakujący nigdy do nich nie dociera. Jedynymi skutecznymi odpowiedziami są załatanie lub wyłączenie usługi.
Luka w SAP Commerce Cloud łączy dwie słabości: niewystarczające kontrole autoryzacji i niewystarczającą walidację danych wejściowych. Nieuwierzytelniony atakujący może nadużyć domyślnego klienta uwierzytelniania, aby dotrzeć do funkcji w Data Hub Adapter, które nie walidują prawidłowo tego, co otrzymują, a następnie przesłać do tych funkcji spreparowane dane, aby wykonać dowolny kod i naruszyć wewnętrzne komponenty. Nie są wymagane żadne poświadczenia ani interakcja użytkownika.
Dwa terminy warte zdefiniowania:
- Obejście uwierzytelniania — system zostaje oszukany, by uwierzyć, że udowodniłeś już swoją tożsamość.
- Data Hub Adapter — komponent SAP Commerce Cloud, który importuje dane i wymienia je z innymi systemami, takimi jak ERP lub platformy magazynowe. Znajduje się na granicy integracji, dlatego jego przejęcie jest tak cenne.
Dlaczego to ważne
Okno między poprawką a atakiem się załamało. Trzy dni dla luki SAP o maksymalnej krytyczności, około tygodnia dla błędu macOS. Miesięczne cykle łatania i kwartalne okna zmian nie działają w takiej skali czasu.
Publiczny proof-of-concept jest akceleratorem, a nie warunkiem wstępnym. Atakujący zaczęli sondować lukę SAP, zanim opublikowano jakikolwiek PoC — sam biuletyn dawał wystarczająco wskazówek. Po stronie macOS pojawienie się publicznego kodu exploita zbiegło się z widocznym skokiem wykorzystania.
Kopanie kryptowalut nie jest nieszkodliwym skutkiem. Koparka jest dowodem, że atakujący uzyskał roota na maszynie i mógł wdrożyć cokolwiek. Cryptojacking jest często tym, co zwykli aktorzy robią z dostępem, którego nie mogą od razu spieniężyć w inny sposób — a dostęp można odsprzedać.
Oceny krytyczności są tymczasowe. CVE-2026-65400 został przeklasyfikowany z wysokiej na krytyczną osiem dni po ujawnieniu. Zespoły, które raz go przeanalizowały, przy 7,1, i poszły dalej, mogły obniżyć priorytet błędu, który okazał się dostępem roota przed uwierzytelnieniem.
Kogo to dotyczy
macOS (CVE-2026-65400):
- Każdy Mac z macOS Tahoe, Sequoia lub Sonoma poniżej poprawionych wersji z włączonym Screen Sharing.
- Najwyższe ryzyko: systemy, w których port 5900 jest osiągalny z Internetu. Huntress zidentyfikował dziesiątki tysięcy potencjalnie narażonych Maców, przy czym szczególnie wyraźnie występowały systemy Apple typu bare-metal hostowane w Internecie — hosting Maców w chmurze, floty budujące CI/CD, punkty końcowe dostępu zdalnego.
- Screen Sharing jest domyślnie wyłączony, więc nie jest to ekspozycja powszechna. Jest to ekspozycja wszędzie tam, gdzie funkcję włączono i pozostawiono osiągalną.
SAP (CVE-2026-58231):
- Wdrożenia SAP Commerce Cloud (dawniej Hybris) na COM_CLOUD 2211 lub 2211-JDK21 z włączonym dotkniętym rozszerzeniem Data Hub Adapter.
- Najpilniejsze: wdrożenia, w których funkcja importu Data Hub jest osiągalna z niezaufanej sieci. Platforma ta zwykle stanowi podstawę sklepów detalicznych i B2B oraz integruje się z systemami ERP, CRM, płatności, magazynowymi i realizacji zamówień.
Co mogą zrobić atakujący
Na przejętym Macu: dostęp roota, który w zaobserwowanych przypadkach został użyty do instalacji koparki Monero. Przy takim poziomie dostępu atakujący może też zdalnie otwierać aplikacje, czytać pliki, zmieniać ustawienia bezpieczeństwa, instalować mechanizmy utrwalania i używać hosta jako przyczółka do otaczającej sieci.
Na przejętej instancji SAP Commerce Cloud: dowolne wykonanie kodu i naruszenie wewnętrznych komponentów, z wysokim wpływem na poufność, integralność i dostępność. Ze względu na to, z czym platforma jest połączona, realistyczne cele dalsze obejmują kradzież danych klientów i zamówień, manipulowanie cenami lub transakcjami, przygotowanie ransomware i ruch boczny do ERP i innych systemów zaplecza.
Dla kontekstu historycznego: CVE-2025-31324, porównywalna luka CVSS 10,0 w SAP NetWeaver wykorzystywana w 2025 roku, została uzbrojona zarówno przez klastry szpiegowskie powiązane z Chinami — publicznie śledzone jako UNC5221, UNC5174 i CL-STA-0048 — jak i przez grupy cyberprzestępcze, w tym BianLian i RansomExx. Krytyczne luki SAP przyciągają obie kategorie atakujących.
Co powinni zrobić użytkownicy i organizacje
Dla macOS:
- Zaktualizuj teraz do macOS Tahoe 26.6.1, Sequoia 15.7.9 lub Sonoma 14.8.9 (lub nowszych).
- Wyłącz Screen Sharing, gdzie nie jest potrzebny: Ustawienia systemowe → Ogólne → Udostępnianie → Udostępnianie ekranu. To skuteczne tymczasowe złagodzenie, jeśli nie możesz natychmiast zainstalować poprawki.
- Zablokuj port 5900 na obwodzie. Żadna usługa pulpitu zdalnego Maca nie powinna być wystawiona bezpośrednio do Internetu. Wymagaj VPN lub hosta bastionowego.
- Nie polegaj na zmianie haseł. Zmiana hasła Screen Sharing lub VNC nie łagodzi tej luki.
- Szukaj śladów włamania na narażonych systemach. Zwracaj uwagę na nieoczekiwanie wysokie użycie CPU, nieznane procesy i LaunchDaemons, nowe mechanizmy utrwalania na poziomie roota, połączenia wychodzące do pul koparek i połączenia przychodzące na port 5900 sprzed instalacji poprawki. Załatanie nie wyrzuci atakującego, który już rezyduje w systemie.
- Zweryfikuj flotę, nie zakładaj. Potwierdź rzeczywiste zainstalowane numery kompilacji przez MDM, zamiast ufać, że automatyczne aktualizacje się zakończyły.
Dla SAP Commerce Cloud:
- Zastosuj Security Note 3771065 i zaktualizuj do 2211.55, 2211-jdk21.17 lub nowszego obsługiwanego wydania.
- Zbuduj i wdróż ponownie. Pobranie poprawionego pakietu nie jest remediacją. Zaktualizowana aplikacja musi zostać wdrożona, a zespoły powinny zweryfikować wersję faktycznie uruchomioną w produkcji oraz w środowiskach stagingowych i testowych.
- Użyj IP Filter Set jako tymczasowej kontroli, gdy aktualizacja wymaga dłuższego planowania, ograniczając punkt końcowy importu Data Hub Adapter wyłącznie do zaufanych systemów Data Hub.
- Najpierw nadaj priorytet instancjom osiągalnym z zewnątrz, a potem przechodź do wnętrza.
- Przejrzyj logi pod kątem podejrzanych żądań do punktu końcowego importu Data Hub Adapter sięgających co najmniej 11 sierpnia, wraz z wszelkim nieoczekiwanym wykonywaniem procesów, nowymi plikami lub połączeniami wychodzącymi z serwerów aplikacji.
Dla obu, i dla następnej:
- Traktuj CVSS 10,0 i potwierdzone wykorzystanie w środowisku naturalnym jako wyzwalacze awaryjnych procedur zmian, a nie normalnej kolejki łatania.
- Utrzymuj dokładny inwentarz tego, co jest wystawione do Internetu. Obie te historie są w gruncie rzeczy historiami o ekspozycji.
- Sprawdzaj ponownie oceny krytyczności luk, które już przeanalizowałeś. Oceny się zmieniają.
Podsumowanie
Najbardziej użyteczny wniosek z tych dwóch incydentów ma niewiele wspólnego z samym Apple czy SAP.
Żadna z tych luk nie była zero-dayem. Obie zostały załatane, zanim ktokolwiek zaobserwował ich wykorzystywanie. Dostawcy wykonali swoją część w terminie, o który obrońcy zawsze proszą — a mimo to atakujący wygrali w kilku sieciach wyłącznie dlatego, że opublikowanie poprawki i jej zastosowanie dzielą dni procesów organizacyjnych.
Ta zwłoka jest teraz powierzchnią ataku. Opublikowany biuletyn to mapa drogowa i staje się publiczny w chwili, gdy publiczna staje się poprawka. W przypadku systemów wystawionych do Internetu „zrobimy to w następnym oknie serwisowym” nie jest już decyzją neutralną — to wyliczone ryzyko z mierzalnym okresem połowicznego rozpadu.
Zakładaj, że zegar wykorzystania zaczyna tykać, gdy poprawka zostaje wydana, a nie gdy pojawia się exploit.
