NIS2/KSC2 starter pack. Czy Twoja firma podlega pod regulację i co z tego wynika? Bezpłatne szkolenie od sekuraka

Konferencja Mega Sekurak Hacking Party w Krakowie – 26-27 października!

Atak supply chain na OpenAI. Dwóch developerów zostało zainfekowanych podmienioną przez hackerów biblioteką TanStack (npm)

15 maja 2026, 12:40 | W biegu | komentarze 2

Jeśli ktoś chce szybko nadrobić zaległości w temacie ostatnich ataków supply chain, to polecam spojrzeć tutaj (Axios), tutaj (Shai-Hulud), tutaj (Bitwarden Cli) czy tutaj (Mini Shai-Hulud – kampania która uderzyła w OpenAI).

W każdym razie OpenAI informuje, że atakujący zaczęli wykradać dane logowania z zainfekowanych komputerów oraz uzyskiwać dostęp do części kodów źródłowych. Z jednej strony OpenAI pisze:

Nie znaleźliśmy żadnych dowodów na to, że uzyskano dostęp do danych użytkowników OpenAI, że nasze systemy produkcyjne lub własność intelektualna zostały naruszone lub że nasze oprogramowanie zostało zmodyfikowane.

Ale jak to w takich marketingowych opowieściach bywa – “nie mamy dowodów” nie oznacza “że coś takiego nie wystąpiło”. Wystarczy nie mieć odpowiednich logów i już “nie ma dowodów” ;-)

Z drugiej strony OpenAI oznajmia, że rotują certyfikaty podpisywania kodu, które potencjalnie mogły dostać się w ręce atakujących. Stary certyfikat podpisujący appki dla MacOS został unieważniony.

Co ciekawe OpenAI, wspomina że po kwietniowej globalnej akcji z infekcją popularnej biblioteki Axios, wprowadzili dodatkowe procedury mające chronić pracowników oraz organizację przed takimi atakami. Ale akurat tych dwóch pracowników nie zastosowało się do procedury (bądź te procedury nie do końca zadziałały):

Do incydentu doszło podczas etapowego wdrażania zabezpieczeń, a dwa urządzenia pracowników, których dotyczył incydent, nie miały zaktualizowanej konfiguracji, która zapobiegłaby pobraniu nowo zaobserwowanego pakietu zawierającego złośliwe oprogramowanie.

This incident occurred during our phased deployment and rollout of these controls, and the two impacted employee devices did not have the updated configurations that would have prevented the download of the newly observed package containing malware.

~ms

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. SeeM

    Wygląda na to, że owa dodatkowa procedura obejmowała między innymi bufor czasowy od momentu publikacji pakietu w npm do możliwości jego zainstalowania.

    To jest jakiś początek. Sam zaczynam wbijać ludziom do głowy, żeby podawali unikalne identyfikatory komponemtów w dockerfile, compose, npm, pip i gdzie się to tylko da. Numer wersji to zaczyna być za mało.

    Odpowiedz
    • Sigma

      czemu nr wersji to za mało?
      np. w takim npm nie da sie opublikować 2x tej samej wersji

      problemem jest brak sztywnych wersji (np. brak lock-files)
      oraz podbijanie zależności to jak wchodzenie w pole minowe
      dzis trzeba wylaczyc wszelkie postinstalle / uzywac lepszych managerow (np. pnpm) / dodatkowych narzedzi (np. safe-chain) i ciagle sie edukować żeby wiedzieć co jeszcze mozna usprawnić

      commit-hash przed niczym nie chroni gdy ktos przejmuje dostęp do repo, a swoje wady ma – np. nie wiesz czy podbiłeś czy zrobiles downgrade; commit mozna wykasować z historii gita i kiedys moze faktycznie zniknąć przy jakimś purge

      Odpowiedz

Odpowiedz