Archiwa: Privacy - Strona 2 z 10

Fałszywe repozytorium OpenAI na Hugging Face rozprowadzało infostealera i zdobyło szczyt trendów

Wprowadzenie do problemu / definicja

Ekosystem open source oraz platformy udostępniające modele sztucznej inteligencji stają się coraz częstszym celem ataków na łańcuch dostaw. Najnowszy incydent pokazał, że cyberprzestępcy potrafią skutecznie wykorzystać zaufanie do rozpoznawalnych marek, popularność modeli oraz mechanizmy rekomendacji platform, aby skłonić użytkowników do uruchomienia złośliwego kodu.

W opisywanym przypadku fałszywe repozytorium podszywało się pod projekt OpenAI związany z filtrowaniem danych wrażliwych. Zamiast legalnego narzędzia użytkownicy otrzymywali wieloetapowy łańcuch infekcji prowadzący do instalacji infostealera dla systemów Windows.

W skrócie

Fałszywe repozytorium udające model Privacy Filter opublikowany przez OpenAI pojawiło się na platformie Hugging Face i osiągnęło pierwsze miejsce w sekcji trendów. Napastnicy skopiowali opis legalnego projektu niemal jeden do jednego, dzięki czemu zwiększyli wiarygodność złośliwej publikacji.

Po uruchomieniu dostarczonych skryptów ofiara pobierała kolejne komponenty infekcji, których końcowym ładunkiem był malware kradnący dane. Oprogramowanie wykradało informacje z przeglądarek, portfeli kryptowalutowych, Discorda, konfiguracji FileZilla, a także wykonywało zrzuty ekranu i zbierało dane systemowe.

Podszycie pod markę OpenAI i legalny model Privacy Filter
Wysoka widoczność repozytorium dzięki sekcji trendów
Wielostopniowy łańcuch infekcji uruchamiany lokalnie przez użytkownika
Kradzież danych uwierzytelniających, plików i informacji z aplikacji
Silny sygnał ostrzegawczy dla bezpieczeństwa łańcucha dostaw AI

Kontekst / historia

OpenAI udostępniło model Privacy Filter pod koniec kwietnia 2026 roku jako narzędzie do wykrywania i redagowania danych osobowych w nieustrukturyzowanym tekście. Tego rodzaju rozwiązanie mogło szybko zyskać zainteresowanie wśród zespołów rozwijających aplikacje AI z naciskiem na prywatność, zgodność regulacyjną i ochronę danych.

Wkrótce po publikacji legalnego projektu pojawiła się jego złośliwa kopia wykorzystująca typosquatting i podszycie pod markę OpenAI. Atakujący nie poprzestali na podobnej nazwie repozytorium. Skopiowali także kartę modelu oraz opis projektu, co znacząco zwiększyło szansę, że użytkownicy uznają repozytorium za autentyczne i bezpieczne.

Badacze wskazali również na istnienie innych repozytoriów wykorzystujących podobny loader i zbliżoną infrastrukturę. To sugeruje, że nie był to pojedynczy incydent, lecz element szerszej kampanii wymierzonej w użytkowników platform hostujących modele, skrypty i artefakty AI.

Analiza techniczna

Mechanizm ataku opierał się na skryptach uruchamianych lokalnie przez użytkownika. Repozytorium instruowało ofiarę, aby sklonowała projekt i uruchomiła odpowiedni skrypt inicjalizacyjny, w tym plik wsadowy dla Windows lub skrypt Python mający rzekomo przygotować środowisko i uruchomić model.

Kluczowym elementem infekcji był plik loader.py, który rozpoczynał złośliwy łańcuch wykonania. Skrypt wyłączał weryfikację SSL, a następnie dekodował zapisany w Base64 adres URL prowadzący do publicznego zasobu JSON. Taki zasób pełnił rolę pośredniego punktu sterowania, z którego pobierane było aktualne polecenie do wykonania.

Następnie uruchamiany był PowerShell, który pobierał zewnętrzny skrypt wsadowy z infrastruktury kontrolowanej przez atakujących. Drugi etap przygotowywał środowisko do działania malware, obejmując próbę podniesienia uprawnień przez monit UAC, dodanie wyjątków do Microsoft Defender Antivirus, pobranie kolejnego pliku binarnego oraz utworzenie zadania harmonogramu do uruchomienia następnego komponentu.

W końcowym etapie wykonywany był infostealer działający jako jednorazowy launcher z kontekstem uprzywilejowanym. Choć użyto harmonogramu zadań, malware nie ustanawiał klasycznej trwałości po restarcie systemu. Mechanizm ten służył raczej do uruchomienia ładunku końcowego z wyższymi uprawnieniami oraz do szybkiego usuwania elementów pośrednich.

Funkcjonalność złośliwego oprogramowania obejmowała szeroki zakres kradzieży danych i działań wspierających eksfiltrację.

Wykonywanie zrzutów ekranu
Zbieranie danych systemowych
Kradzież informacji z Discorda
Pozyskiwanie danych z portfeli kryptowalutowych i rozszerzeń
Wyszukiwanie wrażliwych plików, w tym konfiguracji FileZilla i fraz seed
Ekstrakcję danych z przeglądarek opartych na Chromium i Gecko

Dodatkowo malware zawierał mechanizmy utrudniające analizę i detekcję. Sprawdzał obecność debuggerów i środowisk sandbox, podejmował próby wykrycia maszyn wirtualnych oraz próbował osłabiać AMSI i ETW, aby utrudnić rejestrację działań przez narzędzia ochronne i telemetryczne. Wykradzione dane były następnie wysyłane do zewnętrznej domeny w formacie JSON.

Konsekwencje / ryzyko

Najważniejszym ryzykiem w tym incydencie było połączenie socjotechniki z zaufaniem do platformy i marki. Użytkownicy pracujący z modelami AI często zakładają, że popularne lub trendujące repozytoria są względnie bezpieczne. Gdy złośliwy projekt wykorzystuje nazwę znanej organizacji i kopiuje oficjalny opis, poziom ostrożności naturalnie spada.

Dla organizacji skutki takiego incydentu wykraczają daleko poza pojedynczą stację roboczą. Infostealer może doprowadzić do przejęcia danych, które następnie zostaną wykorzystane do dalszej kompromitacji środowiska.

Zapisane hasła i sesje przeglądarkowe
Tokeny dostępowe do usług chmurowych
Dane komunikacyjne i konta deweloperskie
Portfele kryptowalutowe
Konfiguracje narzędzi administracyjnych i transferowych
Materiały wrażliwe obecne na ekranie lub lokalnym dysku

W środowiskach deweloperskich i badawczych przejęcie takiego hosta może umożliwić ruch boczny, kompromitację kont w Git, CI/CD, rejestrach pakietów, platformach AI oraz systemach produkcyjnych. Szczególnie niepokojące jest to, że atak nie wykorzystywał klasycznej podatności technicznej, lecz zaufany proces pobierania i uruchamiania zewnętrznych artefaktów.

Istotnym problemem pozostaje także manipulacja metrykami popularności. Jeśli liczba pobrań lub aktywność wokół repozytorium została sztucznie zawyżona, oznacza to, że systemy reputacyjne platform mogą być używane jako narzędzie wpływu na decyzje użytkowników.

Rekomendacje

Organizacje korzystające z modeli AI, skryptów pomocniczych i repozytoriów społecznościowych powinny wdrożyć zasady bezpieczeństwa podobne do tych, które obowiązują przy pracy z pakietami open source i zależnościami programistycznymi.

Po pierwsze, należy weryfikować tożsamość wydawcy. Sama nazwa repozytorium, liczba pobrań czy pozycja w trendach nie mogą być traktowane jako dowód autentyczności. Konieczne jest potwierdzenie, czy projekt pochodzi z oficjalnego profilu producenta i czy jest powiązany z komunikacją dostawcy.

Po drugie, trzeba kontrolować wszystkie skrypty wykonywane lokalnie. Każdy plik typu setup, install, loader, postinstall, bat lub ps1 powinien zostać przeanalizowany przed uruchomieniem. Obejmuje to przegląd kodu, identyfikację zewnętrznych adresów oraz sprawdzenie, czy projekt rzeczywiście wymaga pobierania dodatkowych komponentów.

Po trzecie, warto izolować testowanie nowych modeli i repozytoriów. Najbezpieczniejszym podejściem jest uruchamianie ich w odseparowanych środowiskach laboratoryjnych, maszynach tymczasowych lub sandboxach bez dostępu do produkcyjnych sekretów, portfeli, sesji przeglądarkowych i wrażliwych plików.

Zespoły bezpieczeństwa powinny również rozszerzyć monitoring o zachowania charakterystyczne dla tego typu ataków.

Uruchomienia PowerShell i skryptów wsadowych inicjowane przez narzędzia AI
Modyfikacje wyjątków w Microsoft Defender
Tworzenie krótkotrwałych zadań harmonogramu
Połączenia do nowo obserwowanej infrastruktury z hostów badawczych i deweloperskich
Nietypowe odczyty danych z przeglądarek, portfeli i katalogów konfiguracyjnych

Warto także objąć stacje robocze badaczy AI, deweloperów i analityków silniejszym hardeningiem, ograniczeniami uprawnień lokalnych, kontrolą wykonywania skryptów oraz separacją kont administracyjnych od kont codziennego użytku. Modele, checkpointy, skrypty inferencyjne i narzędzia do fine-tuningu powinny przechodzić formalny proces walidacji bezpieczeństwa.

Podsumowanie

Incydent z fałszywym repozytorium podszywającym się pod OpenAI pokazuje, że łańcuch dostaw AI staje się pełnoprawnym obszarem operacji cyberprzestępczych. Atakujący połączyli typosquatting, kopiowanie treści legalnego projektu, manipulację wiarygodnością oraz wieloetapowy loader prowadzący do uruchomienia infostealera.

Dla obrońców najważniejszy wniosek jest jednoznaczny: modele i repozytoria AI należy traktować jak każdy inny nieufny komponent zewnętrzny. Popularność, rozpoznawalna nazwa i atrakcyjny opis nie mogą zastąpić weryfikacji pochodzenia, analizy kodu oraz bezpiecznego uruchamiania w środowisku izolowanym.

Źródła

The Hacker News — https://thehackernews.com/2026/05/fake-openai-privacy-filter-repo-hits-1.html
HiddenLayer Research — https://hiddenlayer.com/innovation-hub/fake-openai-models-on-hugging-face/
OpenAI Privacy Filter — https://openai.com/index/introducing-privacy-filter/
Panther — https://panther.com/blog/npm-package-trevlo-delivers-valleyrat/

GM zapłaci 12,75 mln dolarów za sprzedaż danych kierowców. Rekordowa ugoda obnaża ryzyka telematyki

Wprowadzenie do problemu / definicja

General Motors zawarł ugodę o wartości 12,75 mln dolarów w związku z zarzutami dotyczącymi gromadzenia i sprzedaży danych kierowców bez zapewnienia odpowiedniej przejrzystości oraz ważnej zgody użytkowników. Sprawa dotyczy przede wszystkim danych behawioralnych i lokalizacyjnych pozyskiwanych z pojazdów korzystających z usług telematycznych, takich jak OnStar i funkcje analizujące styl jazdy.

Z punktu widzenia cyberbezpieczeństwa to ważny precedens pokazujący, że ryzyko nie zawsze wynika z klasycznego ataku lub wycieku. Coraz częściej źródłem problemu staje się sam model przetwarzania danych, zwłaszcza gdy producent pojazdu łączy telemetrykę, analitykę zachowań użytkownika i komercyjne udostępnianie informacji partnerom zewnętrznym.

W skrócie

Kalifornijscy regulatorzy uznali, że dane o stylu jazdy i lokalizacji mogły być zbierane oraz sprzedawane bez właściwego poinformowania kierowców i bez uzyskania świadomej zgody. Według ustaleń informacje miały trafiać do podmiotów zajmujących się analizą ryzyka i obrotem danymi, a cały proceder obejmował lata 2020–2024.

ugoda opiewa na 12,75 mln dolarów,
GM ma wstrzymać sprzedaż takich danych przez pięć lat,
firma musi ograniczyć retencję i doprowadzić do usunięcia części danych u odbiorców,
na producenta nałożono obowiązek wzmocnienia programu zgodności w obszarze prywatności.

To jeden z najmocniejszych sygnałów regulacyjnych dla branży connected car, w której dane pojazdów coraz częściej traktowane są jako zasób biznesowy.

Kontekst / historia

Nowoczesne samochody generują ogromne ilości informacji: od lokalizacji i czasu przejazdu po sposób hamowania, przyspieszania czy korzystania z funkcji bezpieczeństwa. Dla producentów, ubezpieczycieli i brokerów danych takie rekordy mają wysoką wartość, ponieważ pozwalają budować profile ryzyka i modele scoringowe.

Sprawa GM wpisuje się w szerszy trend wzmożonej kontroli praktyk związanych z danymi z pojazdów. Doniesienia medialne z 2024 roku zwróciły uwagę na przekazywanie informacji o zachowaniach kierowców podmiotom powiązanym z rynkiem ubezpieczeniowym. Następnie tematem zajęła się amerykańska Federalna Komisja Handlu, która w styczniu 2025 roku podjęła działania wobec GM i OnStar. W styczniu 2026 roku sfinalizowano porozumienie ograniczające możliwość udostępniania określonych kategorii danych przez pięć lat, a kalifornijska ugoda z maja 2026 roku dołożyła do tego sankcje stanowe i obowiązki naprawcze.

Analiza techniczna

W centrum sprawy znalazł się model przetwarzania danych przez usługi OnStar oraz funkcje Smart Driver. Technicznie oznacza to pozyskiwanie telemetryki pojazdu, zdarzeń drogowych i danych geolokalizacyjnych, ich przesyłanie do infrastruktury producenta, a następnie agregację, analizę i ewentualne udostępnianie partnerom biznesowym.

Taki ekosystem zwykle składa się z kilku warstw. Pierwsza obejmuje zbieranie danych z pojazdu i jego czujników. Druga to transmisja do platformy telematycznej, gdzie rekordy są wiązane z kontem użytkownika, identyfikatorem pojazdu lub usługą subskrypcyjną. Trzecia warstwa dotyczy wykorzystania danych do analiz wewnętrznych lub przekazania ich podmiotom trzecim, na przykład firmom oceniającym ryzyko.

Najważniejsze jest jednak to, że problem nie dotyczył włamania ani incydentu naruszenia poufności przez cyberprzestępcę. Był to przykład niewłaściwego zarządzania danymi w legalnie działającym środowisku technologicznym. W praktyce pokazuje to, że architektura systemu może być zgodna operacyjnie, a jednocześnie niezgodna z zasadami privacy by design, minimalizacji danych i świadomej zgody.

Regulatorzy wskazali kilka krytycznych obszarów:

niewystarczająco jasne informowanie użytkowników o zakresie i celu przetwarzania,
brak zgody spełniającej standard wyraźnej i świadomej akceptacji,
zbyt długą retencję danych,
wykorzystanie informacji do celów wtórnych, w tym sprzedaży.

Połączenie szerokiej telemetrii, ograniczonej transparentności oraz komercjalizacji danych stworzyło istotne ryzyko prawne, operacyjne i reputacyjne.

Konsekwencje / ryzyko

Dane o stylu jazdy i precyzyjnej lokalizacji należą do informacji wyjątkowo wrażliwych. Na ich podstawie można odtworzyć codzienne trasy, godziny aktywności, miejsca pracy, wizyty w określonych placówkach czy powtarzalne nawyki użytkownika. Nawet jeśli część rekordów zostanie zanonimizowana lub spseudonimizowana, wysoka szczegółowość lokalizacji może umożliwiać ponowną identyfikację osoby.

Ryzyko dotyczy kilku poziomów jednocześnie. Z perspektywy prywatności oznacza utratę kontroli nad własnymi danymi i możliwość dalszego profilowania. Z perspektywy biznesowej może wpływać na ocenę ryzyka ubezpieczeniowego, segmentację klientów czy decyzje o charakterze finansowym. Z perspektywy bezpieczeństwa fizycznego historia lokalizacji może ujawniać wzorce obecności i nieobecności, co czyni takie zbiory atrakcyjnym celem dla cyberprzestępców, stalkerów lub podmiotów prowadzących działania wywiadowcze.

Dla producentów samochodów równie istotne są skutki organizacyjne. Oprócz kosztów finansowych pojawia się konieczność przebudowy procesów compliance, audytu partnerów, zmiany interfejsów zgody i rewizji całej architektury przepływu danych.

Rekomendacje

Firmy rozwijające usługi connected car powinny traktować dane telemetryczne jako zasób wysokiego ryzyka i wdrażać kontrole adekwatne do ich wrażliwości.

stosować ścisłą minimalizację danych i zbierać tylko to, co jest niezbędne do działania usługi,
oddzielać zgodę marketingową i analityczną od ogólnych warunków korzystania z usług,
zapewnić granularność zgód, aby użytkownik mógł akceptować wybrane cele przetwarzania,
prowadzić pełne mapowanie przepływu danych do partnerów zewnętrznych,
ograniczać retencję i automatyzować mechanizmy usuwania danych,
separować dane identyfikujące od danych telemetrycznych i regularnie oceniać ryzyko ponownej identyfikacji,
łączyć kompetencje zespołów security, privacy i product przy projektowaniu modeli biznesowych opartych na danych.

Dla użytkowników najważniejsze jest sprawdzenie ustawień prywatności w pojeździe i aplikacjach producenta. Warto przejrzeć aktywne zgody, wyłączyć opcjonalne funkcje scoringowe i upewnić się, jakie informacje są wysyłane do chmury oraz komu mogą być udostępniane.

Podsumowanie

Ugoda GM z Kalifornią pokazuje, że cyberbezpieczeństwo w motoryzacji nie kończy się na ochronie systemów pokładowych, aplikacji mobilnych czy komunikacji z chmurą. Równie ważne jest zgodne z prawem i bezpieczne zarządzanie danymi generowanymi przez pojazdy.

W tej sprawie problemem nie był klasyczny cyberatak, lecz model przetwarzania informacji, który według regulatorów działał bez dostatecznej transparentności i bez właściwej zgody użytkownika. Dla rynku connected car to czytelny sygnał: dane telemetryczne i lokalizacyjne będą coraz częściej traktowane jako zasób wysokiego ryzyka, a ich niewłaściwe wykorzystanie może prowadzić do strat finansowych, reputacyjnych i operacyjnych.

Źródła

Fałszywe repozytorium OpenAI na Hugging Face rozprowadzało infostealera

Wprowadzenie do problemu / definicja

Ekosystemy udostępniania modeli AI, zestawów danych i narzędzi machine learning coraz częściej stają się celem ataków na łańcuch dostaw. Najnowszy incydent pokazuje, że cyberprzestępcy potrafią skutecznie podszyć się pod wiarygodny projekt związany z OpenAI, aby nakłonić użytkowników do uruchomienia złośliwego kodu. W tym przypadku wykorzystano platformę Hugging Face oraz fałszywe repozytorium imitujące projekt „Privacy Filter”, którego rzeczywistym celem było dostarczenie malware klasy infostealer na systemy Windows.

W skrócie

Złośliwe repozytorium podszywające się pod legalny projekt OpenAI trafiło na listę popularnych zasobów platformy Hugging Face. Według opublikowanych informacji zostało pobrane setki tysięcy razy, zanim zostało usunięte. Mechanizm ataku opierał się na pliku loader.py, który udawał nieszkodliwy komponent AI, a w rzeczywistości pobierał i uruchamiał kolejne etapy infekcji. Finalnym ładunkiem był infostealer napisany w Rust, zdolny do kradzieży danych z przeglądarek, tokenów Discorda, portfeli kryptowalutowych, poświadczeń SSH, FTP i VPN, lokalnych plików oraz informacji systemowych.

Kontekst / historia

Platformy służące do dystrybucji modeli i kodu AI są dziś traktowane przez społeczność jako naturalne źródło komponentów do testów, badań i wdrożeń. To zaufanie stwarza dogodne warunki dla ataków typosquattingowych oraz kampanii polegających na publikowaniu projektów imitujących znane marki i autorów. W analizowanym przypadku napastnicy skopiowali opis legalnego projektu niemal jeden do jednego, wykorzystali nazwę sugerującą powiązanie z OpenAI i zadbali o pozory autentyczności, dzięki czemu repozytorium zdobyło wysoką widoczność.

Badacze bezpieczeństwa wskazali, że incydent nie był wyłącznie prostym przypadkiem publikacji złośliwego skryptu. Kampania wpisuje się w szerszy trend nadużyć wymierzonych w łańcuch dostaw oprogramowania AI, gdzie zagrożenie nie wynika z klasycznego exploita, lecz z uruchomienia pozornie zaufanego komponentu przez samego użytkownika. Dodatkowo zauważono podobieństwa infrastrukturalne do innych operacji wykorzystujących fałszywe pakiety i złośliwe implanty dystrybuowane pod wiarygodnie brzmiącymi nazwami.

Analiza techniczna

Kluczowym elementem kampanii był skrypt loader.py. Nie pełnił on wyłącznie roli prostego droppera, lecz został przygotowany tak, aby wyglądał jak element pomocniczy związany z przetwarzaniem modeli AI. W tle wykonywał jednak działania typowe dla malware loaderów.

Z ustaleń opublikowanych przez badaczy wynika, że skrypt wyłączał weryfikację SSL, dekodował zakodowany w base64 adres zewnętrznego zasobu, a następnie pobierał ładunek w formacie JSON zawierający polecenie PowerShell. Polecenie to było uruchamiane w niewidocznym oknie, co ograniczało szanse wykrycia przez użytkownika. Następnie pobierany był plik wsadowy start.bat, odpowiedzialny za dalsze etapy infekcji.

Łańcuch wykonania obejmował eskalację uprawnień, pobranie finalnego payloadu o nazwie „sefirah”, dodanie go do wyjątków Microsoft Defender oraz uruchomienie właściwego stealer’a. Taki przebieg infekcji wskazuje na próbę trwałego obejścia natywnych mechanizmów ochronnych systemu i minimalizacji ryzyka szybkiego wykrycia.

Końcowy malware został opisany jako infostealer napisany w Rust. Zakres zbieranych danych był szeroki i obejmował:

dane z przeglądarek Chromium i Gecko, w tym cookies, zapisane hasła, klucze szyfrujące, historię oraz tokeny sesyjne,
tokeny Discorda, lokalne bazy danych i klucze główne,
portfele kryptowalutowe oraz rozszerzenia przeglądarkowe związane z walletami,
poświadczenia i pliki konfiguracyjne SSH, FTP i VPN,
wrażliwe pliki lokalne, w tym potencjalnie seedy i klucze portfeli,
informacje o systemie,
zrzuty ekranu z konfiguracji wielomonitorowych.

Skradzione dane były kompresowane i eksfiltrowane do serwera C2. Dodatkowo malware zawierał rozbudowane mechanizmy antyanalityczne, obejmujące wykrywanie środowisk wirtualnych, sandboxów, debuggerów i narzędzi analitycznych, co utrudniało zarówno analizę ręczną, jak i automatyczne wykrywanie przez systemy bezpieczeństwa.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem tego typu incydentów jest przełamanie zaufania do publicznych repozytoriów wykorzystywanych w pracy badawczej i deweloperskiej. W praktyce zagrożeni są nie tylko indywidualni użytkownicy testujący modele AI, ale również zespoły data science, inżynierowie MLOps, programiści oraz organizacje automatycznie pobierające zasoby z publicznych hubów.

Ryzyko operacyjne jest wysokie z kilku powodów. Infostealery umożliwiają szybkie przejęcie tożsamości cyfrowej ofiary poprzez kradzież ciasteczek, tokenów sesyjnych i zapisanych haseł. Obecność danych kryptowalutowych i kluczy dostępowych zwiększa prawdopodobieństwo bezpośrednich strat finansowych. Z kolei kompromitacja poświadczeń SSH, FTP czy VPN może prowadzić do wtórnego dostępu do infrastruktury firmowej, ruchu bocznego i kolejnych etapów ataku.

Dodatkowym problemem jest skala potencjalnego oddziaływania. Sama liczba pobrań nie musi odpowiadać liczbie realnych ofiar, ponieważ mogła zostać sztucznie zawyżona, jednak fakt osiągnięcia wysokiej pozycji w trendach pokazuje, że platformy z treściami AI mogą być skutecznym kanałem dystrybucji malware. To istotny sygnał ostrzegawczy dla organizacji, które dotąd koncentrowały się głównie na ryzykach związanych z pakietami npm, PyPI czy repozytoriami Git, a mniej uwagi poświęcały repozytoriom modeli ML.

Rekomendacje

Organizacje korzystające z publicznych repozytoriów AI powinny wdrożyć kontrolę pochodzenia i integralności pobieranych zasobów. Każdy model, skrypt lub dataset pobierany z zewnętrznej platformy powinien być traktowany jak niezweryfikowany komponent strony trzeciej.

ograniczyć uruchamianie kodu pomocniczego do odizolowanych środowisk testowych,
blokować wykonywanie skryptów pobieranych razem z modelami, jeśli nie przeszły przeglądu bezpieczeństwa,
wymuszać analizę statyczną i dynamiczną plików Python, batch i PowerShell przed użyciem,
monitorować połączenia wychodzące z hostów badawczych i stacji data science,
stosować allowlisting aplikacji oraz reguły EDR wykrywające nietypowe uruchomienia PowerShell i modyfikacje wyjątków Defendera,
weryfikować reputację autora, historię projektu, nazewnictwo i oznaki typosquattingu,
rozdzielić środowiska badawcze od systemów produkcyjnych oraz kont uprzywilejowanych,
stosować rotację poświadczeń przechowywanych w przeglądarkach i zabraniać ich używania na hostach testowych.

Jeżeli użytkownik uruchomił pliki z podejrzanego repozytorium, odpowiedź na incydent powinna zakładać pełną kompromitację stacji roboczej. Zalecane działania obejmują ponowną instalację systemu, reset i rotację wszystkich zapisanych poświadczeń, unieważnienie aktywnych sesji przeglądarkowych, wymianę seed phrase i kluczy portfeli kryptowalutowych oraz przegląd logów pod kątem dalszej aktywności z użyciem przejętych danych.

Podsumowanie

Incydent z fałszywym repozytorium OpenAI na Hugging Face pokazuje, że bezpieczeństwo łańcucha dostaw w obszarze AI staje się równie krytyczne jak w tradycyjnym ekosystemie oprogramowania. Atak nie wymagał wykorzystania zaawansowanej podatności w platformie — wystarczyło wiarygodne podszycie się pod znany projekt, odpowiednio przygotowany loader i skuteczny infostealer. Dla zespołów bezpieczeństwa to wyraźny sygnał, że modele, skrypty i artefakty ML powinny podlegać tym samym rygorom weryfikacji co biblioteki programistyczne, kontenery i pakiety z publicznych rejestrów.

Źródła

BleepingComputer — https://www.bleepingcomputer.com/news/security/fake-openai-repository-on-hugging-face-pushes-infostealer-malware/

Popularne rozszerzenia przeglądarek sprzedają dane użytkowników. Rosnące ryzyko dla prywatności i firm

Wprowadzenie do problemu / definicja

Rozszerzenia przeglądarek od lat zwiększają funkcjonalność Chrome, Edge i innych platform opartych na nowoczesnych silnikach webowych. Problem polega jednak na tym, że działają one w uprzywilejowanym środowisku i często otrzymują bardzo szeroki dostęp do aktywności użytkownika. Najnowsze ustalenia badaczy pokazują, że część popularnych dodatków nie ogranicza się do deklarowanych funkcji, lecz wykorzystuje uprawnienia do komercyjnego przetwarzania i udostępniania danych.

Z perspektywy cyberbezpieczeństwa nie chodzi wyłącznie o klasyczne złośliwe oprogramowanie. Coraz częściej zagrożeniem staje się legalnie działający komponent, który w granicach przyznanych uprawnień zbiera informacje o zachowaniach użytkownika i przekazuje je partnerom biznesowym, brokerom danych lub platformom analitycznym.

W skrócie

Według opisywanych badań problem dotyczy dziesiątek popularnych rozszerzeń przeglądarek, z których korzysta łącznie około 6,5 mln użytkowników. Wśród nich znajdują się dodatki oferujące tapety, narzędzia produktywności, usługi tymczasowej poczty czy wsparcie przy wypełnianiu formularzy.

Kluczowym problemem jest model biznesowy części tych rozwiązań. Użytkownik otrzymuje pozornie przydatne narzędzie, ale w praktyce płaci za nie własnymi danymi, historią przeglądania i informacjami o aktywności w sieci.

Kontekst / historia

Ryzyko związane z rozszerzeniami przeglądarek jest znane od lat. Badacze bezpieczeństwa wielokrotnie wskazywali, że dodatki browserowe są trudnym do kontrolowania elementem powierzchni ataku, ponieważ mogą działać na wielu stronach jednocześnie i uzyskiwać dostęp do treści przetwarzanych w przeglądarce.

Sytuację komplikuje fakt, że nawet legalnie opublikowane rozszerzenia mogą z czasem zmienić właściciela, politykę prywatności, zakres żądanych uprawnień albo sposób monetyzacji. Oznacza to, że narzędzie uznawane wcześniej za bezpieczne może po aktualizacji stać się źródłem istotnego ryzyka dla prywatności i zgodności.

Obecny przypadek wpisuje się w szerszy trend komercjalizacji danych telemetrycznych i behawioralnych. Różnica polega na tym, że informacje nie są pozyskiwane wyłącznie przez skrypty reklamowe osadzone na stronach, lecz bezpośrednio z poziomu przeglądarki użytkownika, co daje znacznie głębszy wgląd w jego aktywność.

Analiza techniczna

Z technicznego punktu widzenia rozszerzenia mogą uzyskiwać dostęp do odczytu i modyfikacji danych na odwiedzanych stronach, reagować na zdarzenia sieciowe, przechowywać informacje lokalnie oraz komunikować się z zewnętrznymi serwerami. Jeśli dodatek otrzymuje uprawnienia obejmujące wszystkie odwiedzane witryny, może potencjalnie analizować adresy URL, zawartość stron, metadane sesji oraz interakcje użytkownika.

W opisywanym scenariuszu szczególnie istotne jest to, że zagrożenie nie musi wynikać z ukrytego malware. Część rozszerzeń działa formalnie zgodnie z zaakceptowanymi przez użytkownika uprawnieniami, ale wykorzystuje je do szerokiego zbierania danych i ich dalszej monetyzacji. To przesuwa problem z obszaru typowo technicznego do strefy prywatności, zgodności i przejrzystości modelu działania.

Najważniejsze ryzyka techniczne obejmują:

zbieranie historii przeglądania i wzorców zachowań użytkownika,
korelację danych pomiędzy różnymi serwisami i sesjami,
analizę formularzy oraz treści wprowadzanych do pól wejściowych,
dostęp do dokumentów, CV, danych kontaktowych i informacji biznesowych,
przekazywanie danych do brokerów, partnerów reklamowych i platform analitycznych.

Szczególnie duże zagrożenie pojawia się w środowiskach firmowych. Rozszerzenie zainstalowane przez pracownika może uzyskać wgląd w dane przetwarzane w systemach SaaS, skrzynkach pocztowych, panelach administracyjnych, aplikacjach HR czy narzędziach finansowych, nawet jeśli jego instalacja była motywowana prywatną wygodą.

Konsekwencje / ryzyko

Dla użytkowników indywidualnych konsekwencją może być utrata kontroli nad danymi, śledzenie aktywności oraz wtórne wykorzystanie informacji przez nieznane podmioty. W praktyce oznacza to większą ekspozycję na profilowanie, nadużycia reklamowe, a także ryzyko powiązania danych z różnych usług i urządzeń.

Dla organizacji stawka jest znacznie wyższa. Rozszerzenia mogą prowadzić do ujawnienia danych biznesowych, naruszenia tajemnicy przedsiębiorstwa, ekspozycji danych klientów, a nawet osłabienia zgodności z wymaganiami regulacyjnymi i wewnętrznymi politykami bezpieczeństwa.

Nie można też pomijać ryzyka łańcucha dostaw. Dodatek, który dziś jedynie gromadzi telemetrykę, jutro może zostać zaktualizowany o bardziej agresywne funkcje, takie jak wstrzykiwanie skryptów, przekierowania ruchu, manipulacja treścią stron czy przechwytywanie sesji użytkownika.

Najbardziej zagrożone są:

dane osobowe i wrażliwe przetwarzane w aplikacjach webowych,
dane logowania, tokeny i informacje sesyjne,
treści formularzy oraz dokumentów otwieranych w przeglądarce,
informacje handlowe, HR i finansowe,
zgodność z politykami ochrony danych i wymaganiami bezpieczeństwa.

Rekomendacje

Organizacje powinny traktować rozszerzenia przeglądarek jako pełnoprawny element powierzchni ataku. Oznacza to potrzebę inwentaryzacji używanych dodatków, oceny ich uprawnień, analizy modelu prywatności oraz stałego nadzoru nad zmianami wprowadzanymi przez producentów.

Rekomendowane działania obejmują:

wdrożenie listy dozwolonych rozszerzeń w środowisku firmowym,
blokowanie instalacji dodatków spoza zatwierdzonego katalogu,
regularny przegląd nadanych uprawnień, szczególnie dostępu do wszystkich stron,
usuwanie rozszerzeń o niejasnym modelu biznesowym lub nadmiernych żądaniach dostępu,
separację profili prywatnych i służbowych w przeglądarce,
monitorowanie ruchu wychodzącego generowanego przez dodatki,
szkolenie użytkowników z ryzyk związanych z rozszerzeniami browserowymi.

Użytkownicy indywidualni również powinni ograniczyć liczbę instalowanych dodatków do minimum. Przed instalacją warto sprawdzić wydawcę, zakres uprawnień, politykę prywatności oraz to, czy deklarowana funkcja rzeczywiście wymaga tak szerokiego dostępu do danych przeglądania.

Podsumowanie

Sprawa popularnych rozszerzeń sprzedających dane użytkowników pokazuje, że współczesne zagrożenia dla prywatności i bezpieczeństwa coraz częściej wynikają nie z jawnie złośliwego kodu, lecz z modeli biznesowych opartych na eksploatacji danych. Rozszerzenie może działać zgodnie z regulaminem i jednocześnie stanowić realne ryzyko dla użytkownika oraz organizacji.

Dla zespołów bezpieczeństwa oznacza to konieczność objęcia ekosystemu rozszerzeń ścisłym nadzorem. Dla użytkowników to jasny sygnał, że wygoda oferowana przez darmowe dodatki może mieć wysoką cenę w postaci utraty prywatności i ekspozycji wrażliwych informacji.

Źródła

UK Biobank: dane zdrowotne 500 tys. uczestników wystawione na sprzedaż po nadużyciu dostępu badawczego

Wprowadzenie do problemu / definicja

Incydent dotyczący UK Biobank pokazuje, jak poważne ryzyko wiąże się z udostępnianiem dużych zbiorów danych medycznych do celów badawczych. Nawet jeśli dane są pseudonimizowane lub pozbawione bezpośrednich identyfikatorów, ich skala, szczegółowość oraz obecność informacji genetycznych, obrazowych i behawioralnych sprawiają, że pozostają one wyjątkowo wrażliwe.

W praktyce naruszenie bezpieczeństwa nie musi oznaczać ujawnienia nazwisk, adresów czy numerów telefonów, aby stanowiło poważny problem prywatności. W przypadku rozbudowanych zbiorów biomedycznych zagrożeniem staje się także możliwość ponownej identyfikacji osób na podstawie korelacji wielu pozornie anonimowych atrybutów.

W skrócie

UK Biobank poinformował o incydencie, w ramach którego dane dotyczące około 500 tys. uczestników zostały wystawione na sprzedaż na platformach e-commerce w Chinach. Według dostępnych informacji zbiór został wcześniej legalnie pobrany przez trzy instytucje badawcze w Chinach, które następnie miały naruszyć warunki dostępu do danych.

Organizacja zawiesiła dostęp wskazanym podmiotom i rozpoczęła dochodzenie. Ogłoszenia sprzedażowe zostały usunięte, jednak sam incydent wywołał pytania o skuteczność modelu zaufanego badacza oraz o to, czy deidentyfikacja jest wystarczającą ochroną w przypadku tak bogatych zbiorów zdrowotnych.

Kontekst / historia

UK Biobank to jeden z najważniejszych na świecie zasobów danych biomedycznych, wykorzystywany w badaniach nad nowotworami, chorobami neurodegeneracyjnymi, schorzeniami układu krążenia oraz zależnościami między genetyką, stylem życia i stanem zdrowia. Projekt od lat opiera się na modelu kontrolowanego dostępu dla zweryfikowanych instytucji badawczych.

Współczesna nauka coraz mocniej korzysta z platform współdzielonych, przetwarzania chmurowego i współpracy transgranicznej. Zwiększa to wartość badawczą danych, ale jednocześnie rozszerza powierzchnię ataku i utrudnia egzekwowanie polityk bezpieczeństwa po stronie partnerów. W tym przypadku problem nie przypomina klasycznego włamania do centralnej infrastruktury, lecz nadużycie legalnie przyznanego dostępu.

Taki scenariusz jest szczególnie niebezpieczny z perspektywy cyberbezpieczeństwa, ponieważ omija wiele tradycyjnych mechanizmów obronnych skoncentrowanych na zewnętrznym intruzie. Jeżeli dane zostały poprawnie pobrane przez uprawniony podmiot, głównym wyzwaniem staje się kontrola nad ich dalszym wykorzystaniem, kopiowaniem i dystrybucją.

Analiza techniczna

Dostępne informacje sugerują, że problem pojawił się już po udostępnieniu danych uprawnionym odbiorcom. Oznacza to naruszenie modelu kontroli użycia danych po ich wydaniu, a nie wyłącznie kompromitację systemu źródłowego. Tego typu incydenty pokazują ograniczenia podejścia, w którym znaczna część zabezpieczeń opiera się na procedurach, umowach i zaufaniu do partnera.

Technicznie taki przypadek może wynikać z kilku klas słabości: niewystarczającego data governance po stronie odbiorcy, braku skutecznych ograniczeń eksportu, słabej telemetryzacji działań użytkowników uprzywilejowanych oraz niedostatecznego monitorowania nietypowych wzorców użycia danych. Jeżeli dane mogą zostać wyeksportowane poza kontrolowane środowisko analityczne, organizacja traci możliwość wymuszania polityk DLP, monitoringu i ograniczeń kopiowania.

Kluczowe znaczenie ma także charakter samego zbioru. Dane medyczne i genomowe mają wysoką wartość identyfikacyjną. Nawet bez bezpośrednich identyfikatorów zestaw takich cech jak płeć, wiek, miesiąc i rok urodzenia, status socjoekonomiczny, informacje o stylu życia, wyniki badań biologicznych czy dane obrazowe może umożliwiać częściową lub pełną reidentyfikację po połączeniu z innymi bazami. W przypadku danych genetycznych ryzyko to jest jeszcze większe.

Z perspektywy architektury bezpieczeństwa incydent obnaża słabość modelu trusted researcher. Jeżeli organizacja dopuszcza pobieranie pełnych pakietów danych poza własne środowisko, realnie rezygnuje z części kontroli nad cyklem życia informacji. W takich warunkach znaczenia nabierają bezpieczne enklawy danych, analiza in situ, zdalne pulpity bez swobodnego eksportu oraz mechanizmy fingerprintingu i watermarkingu.

Konsekwencje / ryzyko

Najpoważniejszym ryzykiem pozostaje możliwość reidentyfikacji uczestników i wtórnego wykorzystania danych zdrowotnych poza pierwotnym celem badawczym. Problem dotyczy nie tylko prywatności, ale również potencjalnych skutków prawnych, reputacyjnych i społecznych. Dane medyczne połączone z genomiką i informacjami behawioralnymi mogą zostać użyte do profilowania lub tworzenia modeli predykcyjnych bez zgody zainteresowanych osób.

Dla organizacji naukowych taki incydent oznacza utratę zaufania uczestników, ryzyko zaostrzenia zasad dostępu do danych oraz możliwe ograniczenie współpracy międzynarodowej. Dla samych projektów biobankowych to sygnał, że klasyczne założenie o wystarczalności deidentyfikacji przestaje być przekonujące w epoce masowej analityki danych i zaawansowanych technik korelacyjnych.

Istotne jest również ryzyko łańcucha dostępu. Nawet jeśli centralny operator zachowuje wysoki poziom zabezpieczeń, słabszym ogniwem może być partner badawczy, laboratorium, podwykonawca lub użytkownik końcowy. Właśnie dlatego incydenty oparte na nadużyciu autoryzowanego dostępu bywają trudniejsze do wykrycia i bardziej kosztowne niż klasyczne włamania.

Rekomendacje

Organizacje udostępniające dane badawcze powinny ograniczać możliwość pobierania pełnych zbiorów poza kontrolowane środowiska analityczne. Preferowany model to bezpieczne platformy obliczeniowe z silnym IAM, segmentacją, pełnym logowaniem aktywności oraz mechanizmami zapobiegania wyciekom danych.

stosowanie zasady minimalnego dostępu i minimalnego zakresu danych,
wprowadzenie kontroli eksportu wyników opartej na zatwierdzaniu,
ciągły monitoring zachowań użytkowników i instytucji partnerskich,
wdrożenie watermarkingu i data fingerprintingu,
regularne audyty zgodności po stronie odbiorców danych,
egzekwowanie zasad lokalizacji przetwarzania,
szybkie unieważnianie dostępu i rotacja poświadczeń po wykryciu naruszeń.

W przypadku danych o najwyższej wrażliwości warto wdrażać privacy-enhancing technologies, takie jak kontrolowane enklawy danych, bezpieczne środowiska wykonawcze, ograniczenia kopiowania czy federacyjne modele analityczne. Niezbędne jest również traktowanie partnerów badawczych jako podmiotów wysokiego ryzyka w procesach third-party risk management.

Dla zespołów bezpieczeństwa kluczowe znaczenie mają scenariusze wykrywania obejmujące masowy eksport danych, nietypowe harmonogramy pobrań, tworzenie nieautoryzowanych kopii oraz użycie niezatwierdzonych repozytoriów. W praktyce oznacza to konieczność korelacji logów aplikacyjnych, danych z systemów IAM, rozwiązań chmurowych, CASB i DLP w ramach jednego procesu analitycznego.

Podsumowanie

Incydent UK Biobank nie jest wyłącznie kolejnym przypadkiem naruszenia prywatności danych medycznych. To przykład systemowego problemu w środowiskach badawczych, gdzie największym zagrożeniem może być nie zewnętrzny atak, lecz utrata kontroli nad danymi po ich legalnym udostępnieniu.

Nawet brak bezpośrednich identyfikatorów nie eliminuje ryzyka, gdy chodzi o duże i bogate semantycznie zbiory zdrowotne oraz genomowe. Najważniejsza lekcja dla sektora ochrony zdrowia i nauki jest jasna: bezpieczeństwo danych musi obejmować cały cykl życia informacji, a nie kończyć się w momencie przyznania dostępu uprawnionemu badaczowi.

Źródła

UK Biobank – A message to our participants: UK Biobank data security update
https://www.ukbiobank.ac.uk/news/a-message-to-our-participants-uk-biobank-data-security-update
GOV.UK – Minister of State statement to the House of Commons: 23 April 2026
https://www.gov.uk/government/speeches/minister-of-state-statement-to-the-house-of-commons-23-april-2026
GOV.UK – National Data Guardian statement on UK Biobank data advertised for sale in China
https://www.gov.uk/government/news/national-data-guardian-statement-on-uk-biobank-data-advertised-for-sale-in-china
Associated Press – Health data of 500,000 members of a UK project offered for sale online in China
https://apnews.com/article/adc0585cebc36e988654a8a2c94f17e0
Sky News – Medical data of half a million Britons listed for sale on Chinese website, government says
https://news.sky.com/story/medical-data-of-half-a-million-britons-listed-for-sale-on-chinese-website-government-says-13535387

Apple łata błąd iOS pozwalający odzyskać usunięte powiadomienia Signal

Wprowadzenie do problemu / definicja

Apple opublikowało poprawki dla iOS i iPadOS usuwające błąd w komponencie Notification Services, który powodował nieoczekiwane zachowywanie na urządzeniu powiadomień oznaczonych do usunięcia. Problem miał istotny wymiar prywatności, ponieważ treść powiadomień z komunikatorów takich jak Signal mogła pozostać dostępna lokalnie nawet po usunięciu aplikacji.

W praktyce oznaczało to osłabienie założeń bezpieczeństwa opartych na krótkiej retencji danych i minimalizacji śladów pozostających na urządzeniu. Choć nie doszło do złamania szyfrowania end-to-end, podatność pokazała, że warstwa systemowa może utrwalać dane poza kontrolą samej aplikacji.

W skrócie

Podatność oznaczona jako CVE-2026-28950 została usunięta w aktualizacjach iOS 26.4.2, iPadOS 26.4.2, iOS 18.7.8 oraz iPadOS 18.7.8. Błąd wynikał z problemu z logowaniem i retencją danych, przez co powiadomienia przeznaczone do usunięcia mogły pozostać zapisane lokalnie.

problem dotyczył systemowej obsługi powiadomień, a nie samego protokołu Signal,
na urządzeniu mogły pozostawać fragmenty wiadomości i metadane,
aktualizacja ma blokować dalsze utrwalanie takich danych,
według deklaracji producenta poprawka usuwa również wcześniej zachowane wpisy.

Kontekst / historia

Sprawa zyskała rozgłos po doniesieniach, że podczas analizy kryminalistycznej iPhone’a udało się odzyskać przychodzące wiadomości Signal z bazy powiadomień, mimo że sama aplikacja została wcześniej usunięta. To ważne rozróżnienie: problem nie oznacza obejścia szyfrowania komunikatora, lecz nieprawidłowe zarządzanie danymi po stronie systemu operacyjnego.

Incydent wpisuje się w szerszą debatę o tym, jak wiele informacji o komunikacji użytkownika może wyciekać poza aplikację szyfrowaną. Nawet jeśli treść rozmowy jest chroniona kryptograficznie, system nadal przetwarza podglądy wiadomości, nazwy nadawców, znaczniki czasu czy identyfikatory wątków, czyli dane, które również mają wartość operacyjną i śledczą.

Problem nie ogranicza się wyłącznie do Signala. Każda aplikacja wyświetlająca wrażliwe treści w powiadomieniach może zwiększać powierzchnię ujawnienia danych, szczególnie gdy urządzenie trafi w ręce podmiotu dysponującego fizycznym dostępem do sprzętu.

Analiza techniczna

Z opisu producenta wynika, że źródłem problemu był błąd typu logging issue, naprawiony przez improved data redaction. Oznacza to, że systemowa usługa odpowiedzialna za obsługę powiadomień nieprawidłowo przechowywała dane, które powinny zostać usunięte lub zredagowane.

W praktyce powiadomienie push może zawierać wiele elementów wrażliwych, które po zapisaniu w artefaktach systemowych stają się cennym źródłem informacji podczas analizy forensic.

nazwę nadawcy,
fragment wiadomości,
metadane konwersacji,
informacje czasowe,
identyfikatory powiązane z aplikacją lub konkretnym wątkiem.

To klasyczny przykład zjawiska data remanence, czyli rezydualnego pozostawania danych po operacji usunięcia. Użytkownik może zakładać, że usunięcie aplikacji automatycznie eliminuje wszystkie związane z nią ślady, podczas gdy część informacji może nadal pozostawać w warstwie systemowej, cache, logach lub kopiach zapasowych.

Dodatkowym problemem jest to, że nawet bezpieczny komunikator nie ma pełnej kontroli nad tym, jak system prezentuje i obsługuje powiadomienia. Signal oferuje opcje ograniczenia widoczności treści w notyfikacjach, ale takie ustawienia jedynie redukują ryzyko ekspozycji i nie eliminują skutków błędów po stronie systemu operacyjnego.

Konsekwencje / ryzyko

Najpoważniejsze ryzyko dotyczy prywatności użytkowników narażonych na zajęcie urządzenia, analizę powłamaniową lub przeszukanie cyfrowe. W takich scenariuszach lokalnie zachowane powiadomienia mogą ujawnić treść komunikacji nawet wtedy, gdy aplikacja została już usunięta.

ujawnienie fragmentów poufnych rozmów,
korelacja kontaktów i aktywności użytkownika,
odtworzenie osi czasu komunikacji,
naruszenie tajemnicy zawodowej lub operacyjnej,
zwiększenie skuteczności analiz śledczych i wywiadowczych.

Dla organizacji ryzyko jest równie istotne. Powiadomienia na urządzeniach firmowych mogą zawierać dane handlowe, ustalenia wewnętrzne, kody jednorazowe, informacje o klientach lub szczegóły incydentów. Jeśli takie dane pozostają w artefaktach systemowych dłużej niż zakłada polityka bezpieczeństwa, może dojść do naruszenia zasady minimalizacji danych oraz wymagań compliance.

Warto podkreślić, że opisany przypadek nie wskazuje na zdalne przejęcie telefonu. Zagrożenie dotyczy przede wszystkim sytuacji, w których osoba trzecia uzyskuje fizyczny dostęp do urządzenia i może poddać je analizie. Dla dziennikarzy, prawników, aktywistów, menedżerów czy administracji publicznej to w pełni realistyczny model zagrożeń.

Rekomendacje

Priorytetem jest jak najszybsza instalacja aktualizacji iOS lub iPadOS zawierającej poprawkę. W tym przypadku aktualizacja nie tylko ogranicza dalsze utrwalanie danych, ale według deklaracji Apple ma również usuwać wcześniej nieprawidłowo zachowane wpisy powiadomień.

wymusić aktualizację urządzeń Apple do wersji zawierających poprawkę,
ograniczyć treść powiadomień na ekranie blokady i w centrum powiadomień,
w komunikatorach ustawić tryb wyświetlania „tylko nazwa” albo całkowicie ukryć nazwę i treść,
przeanalizować politykę MDM pod kątem ekspozycji danych w powiadomieniach,
uwzględnić artefakty Notification Services w modelowaniu zagrożeń i procedurach mobile forensics,
szkolić użytkowników, że usunięcie aplikacji nie zawsze oznacza całkowite usunięcie wszystkich śladów,
stosować silne zabezpieczenia urządzeń, w tym aktualny kod blokady, biometrię i kontrolę fizycznego dostępu.

W organizacjach o podwyższonych wymaganiach bezpieczeństwa warto rozważyć politykę ograniczającą używanie pełnych podglądów wiadomości na ekranie blokady. To szczególnie istotne tam, gdzie przetwarzane są dane wrażliwe, informacje regulowane lub komunikacja operacyjna związana z incydentami.

Podsumowanie

Poprawka Apple usuwa błąd prywatności w iOS i iPadOS, który prowadził do zachowywania na urządzeniu powiadomień przeznaczonych do usunięcia. Problem nie podważa bezpieczeństwa kryptograficznego Signal, ale pokazuje, że dane z bezpiecznych komunikatorów mogą zostać ujawnione przez warstwę systemową.

Dla użytkowników indywidualnych oznacza to konieczność szybkiej aktualizacji i przeglądu ustawień powiadomień. Dla organizacji to kolejny sygnał, że bezpieczeństwo komunikacji mobilnej należy oceniać szerzej niż tylko przez pryzmat szyfrowania end-to-end.

Źródła

Apple Fixes iOS Flaw That Let FBI Recover Deleted Signal Messages — https://thehackernews.com/2026/04/apple-patches-ios-flaw-that-stored.html
About the security content of iOS 18.7.7 and iPadOS 18.7.7 — https://support.apple.com/en-us/126793
In-App Notification Options – Signal Support — https://support.signal.org/hc/en-us/articles/360043273491-In-App-Notification-Options
Troubleshooting Notifications – Signal Support — https://support.signal.org/hc/en-us/articles/360007318711-Troubleshooting-Notifications
Phone Number Privacy and Usernames – Signal Support — https://support.signal.org/hc/en-us/articles/6712070553754-Phone-Number-Privacy-and-Usernames

Ukryty pasażer w sesji bankowej: jak przekierowania przez Taboola kierowały ruch do Temu

Wprowadzenie do problemu / definicja

Bezpieczeństwo nowoczesnych aplikacji webowych nie zależy już wyłącznie od jakości własnego kodu i konfiguracji serwera. Coraz większe znaczenie ma to, jakie skrypty, piksele i usługi zewnętrzne są uruchamiane w przeglądarce użytkownika oraz gdzie finalnie trafia generowany przez nie ruch. Opisany przypadek pokazuje ryzyko tzw. pierwszego zaufanego skoku, gdy organizacja ufa jednemu dostawcy, ale nie ma pełnej widoczności dalszych przekierowań wykonywanych już po stronie klienta.

W praktyce oznacza to, że nawet na zalogowanych stronach bankowych lub finansowych może dojść do komunikacji z domeną, której operator serwisu nie przewidział jako końcowego odbiorcy danych telemetrycznych. Nie musi to oznaczać klasycznego wycieku haseł czy numerów rachunków, ale może prowadzić do niejawnego profilowania aktywności użytkownika w kontekście sesji uwierzytelnionej.

W skrócie

Podczas audytu europejskiej platformy finansowej ustalono, że komponent powiązany z Taboola inicjował żądanie na zalogowanych stronach użytkowników, po czym odpowiedź HTTP 302 przekierowywała ruch do endpointu śledzącego w domenie Temu. Szczególne znaczenie miał nagłówek umożliwiający uwierzytelnione żądania międzydomenowe, co mogło sprzyjać przesyłaniu identyfikatorów i ciasteczek w komunikacji cross-origin.

To przykład zagrożenia, którego nie wykrywają standardowe kontrole skupione wyłącznie na liście zaakceptowanych dostawców. Formalnie zaufany partner może bowiem stać się punktem wejścia do szerszego łańcucha zależności reklamowych i trackingowych.

Kontekst / historia

Współczesne serwisy internetowe bardzo często korzystają z narzędzi reklamowych, analitycznych, rekomendacyjnych i pomiarowych dostarczanych przez zewnętrznych partnerów. Model ten jest wygodny biznesowo i operacyjnie, ale tworzy zależności, które trudno w pełni prześledzić. Zaufanie do jednego dostawcy często obejmuje także jego podwykonawców, partnerów technologicznych i endpointy, które pojawiają się dopiero w czasie wykonywania kodu w przeglądarce.

W badanym przypadku problem został zauważony podczas audytu przeprowadzonego w lutym 2026 roku. Ustalenia wskazały, że ruch inicjowany na stronach zalogowanego użytkownika nie kończył się na zatwierdzonej domenie pośrednika, lecz był przekierowywany dalej do zewnętrznego systemu śledzącego. To ważny sygnał ostrzegawczy dla branż regulowanych, gdzie strony po zalogowaniu powinny być traktowane jako obszar podwyższonego zaufania.

Analiza techniczna

Mechanizm działania był relatywnie prosty, ale trudny do uchwycenia przez klasyczne zabezpieczenia. Przeglądarka użytkownika na zalogowanej stronie wykonywała żądanie GET do domeny powiązanej z Taboola. Następnie serwer odpowiadał kodem HTTP 302 Found, a przekierowanie prowadziło do endpointu API w domenie Temu.

W analizowanym łańcuchu istotną rolę odgrywał nagłówek Access-Control-Allow-Credentials: true. W kontekście żądań cross-origin ma on znaczenie dla sytuacji, w których przeglądarka może przesyłać poświadczenia, takie jak ciasteczka czy inne identyfikatory sesyjne. Samo jego występowanie nie oznacza jeszcze kompromitacji konta, ale w połączeniu z ruchem z obszaru uwierzytelnionego zwiększa ryzyko korelacji aktywności użytkownika z zewnętrznym profilem trackingowym.

Problem wynika z faktu, że wiele mechanizmów kontrolnych ocenia głównie punkt początkowy komunikacji. Jeżeli pierwsza domena znajduje się na liście dozwolonej polityki bezpieczeństwa, cały proces może wyglądać na zgodny z oczekiwaniami. Tymczasem rzeczywisty cel końcowy może ujawniać się dopiero po przekierowaniu lub dynamicznym wywołaniu po stronie klienta.

Zapory WAF skupiają się głównie na ruchu kierowanym do aplikacji, a nie na pełnym zachowaniu przeglądarki użytkownika.
Analiza statyczna wykrywa obecność dozwolonego skryptu lub piksela, ale nie pokazuje dynamicznych przekierowań wykonywanych w runtime.
Polityki CSP często kontrolują źródła początkowe, lecz nie zawsze zapewniają pełną widoczność końcowych destynacji ruchu.
Monitoring aplikacyjny nie musi obejmować mapowania zależności fourth-party, czyli podmiotów ukrytych za bezpośrednim dostawcą.

To sprawia, że do powstania istotnego ryzyka nie jest potrzebna klasyczna luka typu XSS, RCE czy przejęcie sesji. Wystarczy, że zewnętrzny komponent obecny na stronie zalogowanego użytkownika przekaże metadane, identyfikatory przeglądarki lub informacje o kontekście wizyty do nieoczekiwanego odbiorcy.

Konsekwencje / ryzyko

Najpoważniejsze skutki dotyczą prywatności, zgodności regulacyjnej i nadzoru nad łańcuchem dostaw aplikacji webowej. Nawet jeśli nie doszło do bezpośredniego ujawnienia danych logowania, sama możliwość powiązania aktywności użytkownika banku z zewnętrznym systemem śledzącym może rodzić poważne pytania o legalność, przejrzystość i zakres przetwarzania danych.

Utrata kontroli nad środowiskiem stron zalogowanych, które powinny pozostawać maksymalnie odseparowane od ekosystemu reklamowego.
Ryzyko naruszenia zasad minimalizacji danych i rozliczalności wobec regulatorów oraz audytorów.
Ryzyko reputacyjne wynikające z połączenia sesji bankowej z mechanizmami profilowania reklamowego.
Ryzyko fourth-party, gdy zatwierdzony dostawca korzysta z dalszych integracji nieuwzględnionych w procesie oceny.
Niska wykrywalność incydentu, jeśli organizacja nie monitoruje pełnych łańcuchów żądań wykonywanych w przeglądarce.

W sektorach finansowych, medycznych i innych środowiskach wrażliwych podobne przypadki mogą mieć znaczenie nie tylko techniczne, ale również prawne i biznesowe. Odpowiedzialność organizacji nie kończy się bowiem na wskazaniu, że zaakceptowano jedynie bezpośredniego partnera.

Rekomendacje

Organizacje powinny przyjąć założenie, że kontrola nad skryptami zewnętrznymi nie może ograniczać się do sprawdzenia nazwy dostawcy i podstawowej listy domen. Potrzebne jest połączenie środków technicznych, procesowych i architektonicznych.

Maksymalnie ograniczać obecność narzędzi reklamowych, rekomendacyjnych i trackingowych na stronach zalogowanych.
Monitorować pełne łańcuchy runtime, w tym przekierowania 3xx, wywołania fetch i XHR oraz dynamicznie ładowane zasoby.
Rozszerzyć proces vendor risk management o relacje third-party i fourth-party.
Regularnie przeglądać polityki CSP, ustawienia connect-src, zasady cookies oraz reguły dotyczące poświadczeń cross-origin.
Uzupełnić klasyczne testy bezpieczeństwa o analizę zachowania rzeczywistej przeglądarki po zalogowaniu.
Włączać zespoły AppSec, privacy i legal do wspólnej oceny komponentów zewnętrznych w obszarach uwierzytelnionych.
Utrzymywać aktualną inwentaryzację wszystkich domen, endpointów i przekierowań obserwowanych po stronie klienta.

Najważniejsza zmiana dotyczy podejścia: zaufanie do jednego dostawcy nie może automatycznie obejmować całego łańcucha zależności, który ujawnia się dopiero w czasie wykonywania kodu w przeglądarce użytkownika.

Podsumowanie

Opisany przypadek pokazuje, że realne zagrożenia dla aplikacji webowych coraz częściej wynikają nie z klasycznych błędów programistycznych, lecz z braku widoczności nad ruchem inicjowanym przez zewnętrzne komponenty. Przekierowanie ruchu z zalogowanych stron bankowych przez zaufany piksel do zewnętrznego endpointu trackingowego ujawnia słabość modeli bezpieczeństwa opartych wyłącznie na liście zaakceptowanych partnerów.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że analiza runtime, kontrola zależności fourth-party i ścisła separacja obszarów marketingowych od transakcyjnych stają się dziś równie ważne jak tradycyjne testy podatności. W środowiskach regulowanych taka zmiana perspektywy nie jest już opcją, lecz koniecznością.

Źródła

The Hacker News — Hidden Passenger? How Taboola Routes Logged-In Banking Sessions to Temu — https://thehackernews.com/2026/04/hidden-passenger-how-taboola-routes.html
MDN Web Docs — Access-Control-Allow-Credentials — https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials
MDN Web Docs — Content Security Policy (CSP) — https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
OWASP — Third-Party JavaScript Management Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html
PCI Security Standards Council — PCI DSS Documentation Library — https://www.pcisecuritystandards.org/document_library/