W tekście o Crunchyrollu opisywaliśmy, jak wejście przez zewnętrznego partnera obsługowego — firmę TELUS Digital obsługującą support — dało atakującemu dostęp do narzędzi operacyjnych organizacji: Zendeska, Jiry, Slacka. Tam zagrożeniem był partner z dostępem do działania w imieniu firmy. Case HackerOne/Navia pokazuje drugi wariant tego samego wzoru: partner bez dostępu do narzędzi operacyjnych, ale z dostępem do danych — i to wystarczyło. Navia Benefit Solutions nie miała wglądu w systemy produkcyjne HackerOne. Miała dane pracowników. I właśnie te dane stały się przedmiotem ataku.
To właśnie czyni ten incydent tak interesującym. HackerOne — firma kojarzona z bezpieczeństwem, bug bounty i ofensywnym security — nie została tu opisana jako ofiara włamania do własnych systemów produkcyjnych. Źródłem problemu była Navia Benefit Solutions, zewnętrzny administrator świadczeń pracowniczych. Navia wykryła podejrzaną aktywność 23 stycznia 2026 roku, ale śledztwo wykazało, że nieautoryzowany dostęp trwał od 22 grudnia 2025 do 15 stycznia 2026 — przez niemal miesiąc bez wykrycia.
HackerOne i Navia: kto jest kim
To warto uporządkować od razu. HackerOne to platforma z obszaru cyberbezpieczeństwa, zarządzająca ponad 1 950 programami bug bounty i obsługująca klientów takich jak Goldman Sachs, GitHub, Anthropic czy Departament Obrony USA. Navia Benefit Solutions to zupełnie inny rodzaj podmiotu: administrator świadczeń pracowniczych obsługujący FSA, HSA, HRA i COBRA dla ponad 10 000 pracodawców w Stanach Zjednoczonych. W tym układzie nie mówimy o dwóch podobnych podmiotach, tylko o relacji: firma bezpieczeństwa i zewnętrzny partner administracyjny od danych pracowniczych.
To rozróżnienie ma znaczenie. Bez niego łatwo odczytać ten incydent jako "breach HackerOne". Tymczasem HackerOne wprost wskazało w zgłoszeniu do Maine Attorney General, że źródłem naruszenia nie były jego własne systemy, lecz Navia.
Co się stało i jak
Wektor ataku jest teraz publicznie znany. Według oświadczenia HackerOne i relacji The Register oraz BleepingComputer, przyczyną był błąd typu BOLA — Broken Object Level Authorization — w środowisku Navii. BOLA to klasa podatności API, w której aplikacja nie weryfikuje poprawnie, czy zalogowany użytkownik ma prawo dostępu do konkretnego obiektu danych. W praktyce oznacza to, że atakujący mógł odpytywać API Navii o rekordy innych użytkowników, nie będąc do tego uprawnionym. To nie był atak wymagający skomplikowanego exploita. Wymagał zidentyfikowania słabo zabezpieczonego punktu dostępu do danych i systematycznego odpytywania go.
Dostęp trwał od 22 grudnia 2025 do 15 stycznia 2026. W tym oknie atakujący miał dostęp do danych osobowych pracowników i ich rodzin: numerów Social Security, imion i nazwisk, adresów, numerów telefonów, dat urodzenia, adresów e-mail oraz dat rejestracji i zakończenia planów świadczeń zdrowotnych. Navia potwierdziła, że nie zostały ujawnione dane roszczeń ani informacje finansowe, ale to nie zmienia wiele w warstwie ryzyka. Taki zestaw danych wystarczy do phishingu, socjotechniki, podszywania się i bardzo precyzyjnego profilowania ofiar.
Łączna skala breachu Navii to 2 697 540 osób zgłoszonych do Maine Attorney General. W przypadku HackerOne dotyczyło to 287 pracowników. Wśród innych znanych ofiar jest Washington State Health Care Authority, której naruszono rekordy sięgające siedem lat wstecz, obejmujące około 27 000 aktywnych i byłych członków PEBB oraz 5 600 z programu SEBB. Żadna grupa ransomware nie wzięła dotychczas odpowiedzialności za atak.
Opóźnione powiadomienie jako osobny problem
W tym case ciekawy jest też wątek procesu zgłoszenia — i tu pojawia się drugi wymiar problemu z partnerami zewnętrznymi. Navia wykryła naruszenie 23 stycznia. Listy do dotkniętych firm datowała na 20 lutego. HackerOne twierdzi, że otrzymało ten list dopiero w marcu — ponad sześć tygodni po wykryciu incydentu. Spotkanie wyjaśniające między obiema firmami odbyło się 13 marca.
HackerOne publicznie sformułowało swoje oczekiwania: czeka na wyjaśnienie przyczyn opóźnienia i zapowiedziało przegląd polityk bezpieczeństwa Navii. Zaznaczyło też, że rozważa "inne możliwości dla dostawcy świadczeń", jeśli te standardy nie będą satysfakcjonujące.
To nie jest tylko detal proceduralny. Sześć tygodni między wykryciem a powiadomieniem klienta to okno, w którym organizacja nie mogła rotować danych, ostrzegać pracowników ani oceniać ryzyka wtórnego. Problem nie kończył się więc na samym naruszeniu — obejmował też tempo i jakość przepływu informacji po incydencie.
Nie bez znaczenia: to już drugi raz
Cybernews zwraca uwagę na szerszy kontekst: to już drugi incydent związany z zewnętrznym dostawcą dla HackerOne w ciągu kilku miesięcy. We wrześniu 2025 roku firma była wśród ofiar naruszenia Salesforce przeprowadzonego przez grupę Scattered LAPSUS$ Hunters, do którego doszło przez aplikację Drift obsługiwaną przez Salesloft. Dwa naruszenia przez zewnętrznych partnerów w odstępie kilku miesięcy to nie pech. To sygnał systemowy, który sugeruje, że łańcuch zaufania do zewnętrznych operatorów procesów wymaga takiej samej uwagi jak infrastruktura własna — niezależnie od tego, jak dojrzałe jest bezpieczeństwo głównego produktu.
Co ten case naprawdę mówi o partnerach zewnętrznych
Najważniejsza lekcja nie brzmi "firma bezpieczeństwa też bywa ofiarą" — to banalne. Ważniejsza jest struktura tego incydentu. BOLA w Navii nie miała żadnego bezpośredniego związku z systemami produkcyjnymi HackerOne. Nie było włamania przez VPN, nie było ataku na infrastrukturę bug bounty, nie było kompromitacji żadnego z 1 950 programów. Była podatność w zewnętrznym systemie administracyjnym, który HackerOne wybrało do obsługi świadczeń pracowniczych. I to wystarczyło, żeby dane 287 pracowników — wraz z danymi ich rodzin — znalazły się w zasięgu atakującego.
BOLA należy do klas błędów obecnych na liście OWASP API Security Top 10 od kilku lat. Pytanie "czy testujecie swoje API pod kątem BOLA i podobnych błędów autoryzacji" jest dziś konkretne i zasadne — nie wymaga rozbudowanego audytu, żeby znaleźć się na liście pytań przed podpisaniem umowy z zewnętrznym operatorem danych.
Podsumowanie
To nie wygląda na wejście przez główny system. To wygląda na wejście przez partnera, który miał przetwarzać "tylko" dane administracyjne, przez podatność API, którą można było wykryć standardowymi testami bezpieczeństwa.
Crunchyroll pokazał, że partner z dostępem do narzędzi operacyjnych jest częścią Twojej powierzchni ataku. HackerOne/Navia pokazuje, że partner z dostępem wyłącznie do danych — też.
To razem sugeruje pytanie, które warto zadać sobie przed kolejnym przeglądem vendor risk: czy mapa partnerów zewnętrznych w Twojej organizacji w ogóle rozróżnia te dwa modele? I czy wymagania bezpieczeństwa są do nich dostosowane — czy są takie same dla wszystkich, bo tak jest łatwiej?
Źródła
- The Register — o podatności BOLA jako wektorze ataku, opóźnionym powiadomieniu i stanowisku HackerOne wobec Navii.
- BleepingComputer — o zakresie danych dotkniętych pracowników HackerOne i treści zgłoszenia do Maine AG.
- SecurityWeek — o skali breachu Navii (2 697 540 osób) i oknie nieautoryzowanego dostępu.
- Cybernews — o wcześniejszym incydencie HackerOne przez Salesforce/Drift we wrześniu 2025.
- Washington State Health Care Authority — o skali naruszenia dla członków PEBB i SEBB.
