Archiwa: Security News - Strona 30 z 476

Obywatel Ukrainy przyznał się do udziału w operacji Conti ransomware po ekstradycji z Irlandii

Wprowadzenie do problemu / definicja

Przyznanie się do winy przez obywatela Ukrainy oskarżonego o udział w działalności grupy Conti ponownie zwraca uwagę na skalę i dojrzałość nowoczesnych operacji ransomware. Conti należało do najbardziej destrukcyjnych ekosystemów cyberprzestępczych ostatnich lat, łącząc szyfrowanie danych, kradzież informacji oraz wieloetapowe wymuszenia finansowe wobec organizacji z różnych sektorów.

Sprawa pokazuje, że ransomware nie jest dziś pojedynczym narzędziem, lecz modelem działania opartym na podziale ról, zapleczu programistycznym i wyspecjalizowanych kompetencjach technicznych. To właśnie taki poziom organizacji sprawił, że Conti stało się jednym z najgroźniejszych symboli cyberprzestępczości operacyjnej.

W skrócie

Amerykańskie organy ścigania poinformowały, że Oleksii Oleksiyovych Lytvynenko, obywatel Ukrainy ekstradowany z Irlandii do Stanów Zjednoczonych, przyznał się do udziału w spisku związanym z operacją Conti ransomware. Według ustaleń działał w strukturach grupy w latach 2021–2022 i uczestniczył w działaniach obejmujących kompromitację sieci, szyfrowanie systemów, kradzież danych oraz wymuszanie płatności w kryptowalutach.

oskarżony miał działać w ekosystemie Conti w latach 2021–2022,
brał udział w atakach obejmujących eksfiltrację danych i wdrożenie ransomware,
miał pracować nad komponentem typu loader używanym w łańcuchu infekcji,
sprawa potwierdza rosnącą skuteczność ścigania osób pełniących role techniczne w grupach ransomware.

Kontekst / historia

Conti było jedną z najbardziej rozpoznawalnych grup ransomware działających szczególnie aktywnie w latach 2020–2022. Jej model funkcjonowania stał się przykładem profesjonalizacji cyberprzestępczości: istniał wyraźny podział obowiązków, specjalizacja operatorów, rozwój własnych narzędzi oraz agresywny model podwójnego wymuszenia.

W praktyce oznaczało to, że ofiary były nie tylko pozbawiane dostępu do systemów przez szyfrowanie, ale również narażane na wyciek wcześniej skradzionych danych. Taki schemat zwiększał presję na zapłatę okupu i wzmacniał pozycję przestępców w negocjacjach.

Ataki przypisywane Conti dotknęły organizacje w wielu krajach i branżach, a straty finansowe oraz operacyjne liczono w setkach milionów dolarów. Grupa była też łączona z szerszym zapleczem malware i środowiskami służącymi do uzyskiwania wstępnego dostępu do sieci ofiar.

Analiza techniczna

Z technicznego punktu widzenia sprawa jest istotna, ponieważ pokazuje, że współczesne operacje ransomware opierają się na modularnej architekturze ataku. W tym przypadku oskarżony miał nie tylko dysponować skradzionymi danymi ofiar, ale również uczestniczyć w pracach nad loaderem, czyli komponentem wykorzystywanym do uruchamiania lub dostarczania kolejnych elementów złośliwego oprogramowania.

Loader odgrywa ważną rolę w atakach wieloetapowych. Może odpowiadać za pobranie dodatkowego malware, wdrożenie narzędzi do ruchu lateralnego, ustanowienie trwałości w środowisku oraz przygotowanie systemów do końcowego etapu szyfrowania. Dla operatorów ransomware oznacza to większą elastyczność i możliwość dopasowania łańcucha ataku do konkretnej infrastruktury.

Opisany schemat wpisuje się w dobrze znany model działania Conti: uzyskanie dostępu do środowiska ofiary, eskalacja uprawnień, rozpoznanie infrastruktury, eksfiltracja danych, a następnie wdrożenie ransomware i żądanie okupu. Połączenie kompetencji programistycznych z dostępem do wykradzionych informacji zwiększało skuteczność całej operacji oraz utrudniało obronę po stronie poszkodowanych organizacji.

Konsekwencje / ryzyko

Przyznanie się do winy ma znaczenie nie tylko procesowe, ale także operacyjne dla środowiska cyberbezpieczeństwa. Potwierdza, że organy ścigania są w stanie identyfikować i ścigać osoby odpowiedzialne za konkretne elementy techniczne w strukturach ransomware, a nie wyłącznie anonimowe marki przestępcze.

Dla organizacji najważniejszy wniosek pozostaje niezmienny: nawet jeśli dana grupa formalnie osłabnie lub zniknie z rynku, jej członkowie, narzędzia i know-how mogą być dalej wykorzystywane w nowych kampaniach. Oznacza to trwałe ryzyko dla przedsiębiorstw, administracji i infrastruktury krytycznej.

utrata dostępności systemów i przestoje operacyjne,
wyciek danych wrażliwych i tajemnic biznesowych,
koszty odbudowy środowiska oraz reagowania na incydent,
ryzyko sankcji regulacyjnych i sporów prawnych,
wtórne wykorzystanie skradzionych danych do phishingu, szantażu i dalszych oszustw.

Rekomendacje

Organizacje powinny traktować tę sprawę jako kolejny argument za wdrażaniem obrony wielowarstwowej przeciw ransomware. Kluczowe pozostaje ograniczanie powierzchni ataku poprzez szybkie łatanie systemów, stosowanie uwierzytelniania wieloskładnikowego, segmentację sieci oraz ścisłą kontrolę uprawnień administracyjnych.

W obszarze detekcji warto monitorować nietypowe uruchomienia narzędzi administracyjnych, aktywność loaderów, wzmożone operacje na zasobach plikowych, anomalie w ruchu sieciowym oraz symptomy eksfiltracji danych. Istotną rolę odgrywają także rozwiązania EDR lub XDR, centralizacja logów i korelacja zdarzeń w systemach SIEM.

Z perspektywy odporności operacyjnej niezbędne są kopie zapasowe odseparowane logicznie lub fizycznie od środowiska produkcyjnego, regularne testy odtwarzania, procedury reagowania na incydenty oraz przygotowane scenariusze kryzysowe obejmujące komunikację, aspekty prawne i współpracę z organami ścigania.

regularnie aktualizować systemy i usługi dostępne z internetu,
wymuszać MFA dla dostępu uprzywilejowanego i zdalnego,
wdrażać segmentację sieci i zasadę najmniejszych uprawnień,
utrzymywać kopie zapasowe offline i testować ich odtwarzanie,
prowadzić ćwiczenia tabletop dla zespołów technicznych i kadry zarządzającej.

Podsumowanie

Sprawa Oleksii Lytvynenki pokazuje, że operacje ransomware są złożonymi przedsięwzięciami realizowanymi przez osoby posiadające konkretne kompetencje techniczne. Udział w rozwoju komponentów takich jak loader wskazuje na wysoki poziom specjalizacji i organizacji wewnątrz ekosystemu Conti.

Dla obrońców najważniejszy wniosek jest jednoznaczny: skuteczna ochrona przed ransomware wymaga nie tylko działań prewencyjnych, ale także zdolności do szybkiego wykrywania, izolacji incydentu i sprawnego odtworzenia działania organizacji po ataku.

Źródła

FBI rozbiło skalowalną platformę phishingową wspieraną przez AI. Ponad milion fałszywych URL-i w tle operacji

Wprowadzenie do problemu / definicja

Phishing-as-a-Service to model cyberprzestępczy, w którym operatorzy udostępniają gotową infrastrukturę, szablony wiadomości, fałszywe strony logowania oraz narzędzia do zarządzania kampaniami innym przestępcom. Najnowsza operacja amerykańskich służb pokazuje, że połączenie tego modelu z automatyzacją i elementami sztucznej inteligencji znacząco zwiększa skalę oraz skuteczność oszustw.

Rozbita infrastruktura była wykorzystywana do kampanii phishingowych i smishingowych podszywających się pod znane marki. Skala przedsięwzięcia obejmowała tysiące stron i ponad milion fałszywych adresów URL, co pokazuje przemysłowy charakter współczesnych operacji wyłudzających dane.

W skrócie

FBI, we współpracy z partnerami prywatnymi, zakłóciło działanie platformy phishingowej określanej jako Outsider Enterprise.
Infrastruktura służyła do masowego rozsyłania fałszywych wiadomości SMS i przekierowywania ofiar na spreparowane strony.
Operacja obejmowała około 9 tys. fałszywych witryn oraz ponad milion oszukańczych URL-i.
Celem było przechwytywanie danych kart płatniczych, poświadczeń logowania i informacji osobowych.
W sprawie istotną rolę odegrała automatyzacja oraz wykorzystanie AI do zwiększania wiarygodności przynęt.

Kontekst / historia

Outsider Enterprise działał jak zorganizowana usługa dla cyberprzestępców. Zamiast samodzielnie budować strony phishingowe, pisać treści wiadomości i utrzymywać zaplecze techniczne, klienci takiej platformy mogli korzystać z gotowych narzędzi dostarczanych w modelu usługowym.

To wpisuje się w szerszy trend uprzemysłowienia cyberprzestępczości. Dzisiejsze kampanie phishingowe coraz częściej przypominają legalne platformy SaaS: oferują panele administracyjne, zestawy szablonów, mechanizmy testowania oraz kanały zarządzania kampanią. Dzięki temu próg wejścia dla mniej zaawansowanych przestępców znacząco spada, a liczba ataków rośnie.

W analizowanym przypadku szczególne znaczenie miały kampanie SMS podszywające się pod rozpoznawalne marki. Taki kanał dystrybucji zwiększa szansę na kliknięcie, ponieważ użytkownicy często traktują wiadomości tekstowe jako bardziej bezpośrednie i pilne niż e-mail.

Analiza techniczna

Techniczny schemat działania opierał się na klasycznym, lecz bardzo skalowalnym łańcuchu ataku. Najpierw ofiara otrzymywała wiadomość SMS zawierającą przynętę, zwykle stylizowaną na komunikat od zaufanej firmy. Następnie kliknięcie prowadziło do fałszywej witryny imitującej legalny serwis, gdzie następowało przechwycenie danych uwierzytelniających, danych osobowych lub informacji płatniczych.

Kluczową cechą tej infrastruktury była modułowość. Operatorzy utrzymywali tysiące witryn oraz ogromną liczbę adresów URL, co utrudniało skuteczne blokowanie na poziomie domen, sygnatur i reputacji. Taki model pozwalał szybko zastępować zablokowane zasoby nowymi i utrzymywać ciągłość kampanii nawet przy aktywnych działaniach obronnych.

Przejęcie serwerów administracyjnych, kont testowych i zasobów wspierających zaplecze operacyjne wskazuje, że nie chodziło o pojedynczą kampanię, lecz o cały ekosystem przestępczy. Z perspektywy obrońcy problemem jest nie tylko sama wiadomość phishingowa, ale zdolność przeciwnika do masowego generowania kolejnych wariantów treści i infrastruktury.

Dodatkowym czynnikiem była rola AI. Automatyzacja mogła wspierać tworzenie przekonujących komunikatów, lokalizację językową, zmianę tonu wiadomości, generowanie wariantów pod konkretne marki oraz szybkie dostosowywanie kampanii do reakcji użytkowników. To sprawia, że phishing staje się bardziej adaptacyjny i trudniejszy do wykrycia wyłącznie metodami statycznymi.

Konsekwencje / ryzyko

Największym problemem pozostaje skala. Gdy przestępcy operują tysiącami stron i milionami URL-i, tradycyjne podejście oparte na ręcznym zgłaszaniu oraz usuwaniu pojedynczych domen staje się niewystarczające. Organizacje muszą zakładać, że część kampanii ominie zabezpieczenia i trafi do użytkowników końcowych.

Ryzyko obejmuje kilka warstw. Użytkownicy indywidualni mogą stracić środki finansowe, dane kart płatniczych i dostęp do kont. Firmy są narażone na przejęcie poświadczeń pracowników, co może prowadzić do wtórnych incydentów, takich jak nieautoryzowany dostęp do poczty, oszustwa BEC, eskalacja uprawnień czy ruch boczny w środowisku.

Istotne są także skutki wizerunkowe i operacyjne. Podszywanie się pod znane marki osłabia zaufanie do legalnej komunikacji cyfrowej i zwiększa koszty obsługi incydentów, fraudu oraz kontaktu z klientami. Połączenie modelu usługowego z AI oznacza dodatkowo, że zaawansowane techniki socjotechniczne stają się dostępne szerokiemu gronu przestępców jako gotowy produkt.

Rekomendacje

Organizacje powinny traktować smishing i phishing wielokanałowy jako trwały element krajobrazu zagrożeń. Skuteczna obrona wymaga podejścia wielowarstwowego, obejmującego zarówno technologię, jak i procedury.

wdrażanie filtrowania wiadomości i ruchu WWW w oparciu o reputację, heurystykę i analizę behawioralną,
rozwijanie ochrony urządzeń mobilnych i mechanizmów wykrywania podejrzanych wiadomości SMS,
stosowanie MFA odpornego na phishing, najlepiej opartego na kluczach sprzętowych lub passkey,
monitorowanie przejętych poświadczeń i anomalii logowania,
wykrywanie nowych domen oraz monitorowanie podszywania się pod markę,
automatyzowanie blokad IOC i szybkiej wymiany informacji między SOC, CERT i dostawcami usług.

Równie ważne są działania procesowe i edukacyjne.

regularne szkolenia użytkowników z rozpoznawania smishingu i fałszywych stron płatności,
proste procedury zgłaszania podejrzanych wiadomości z poziomu urządzeń mobilnych,
playbooki reagowania na incydenty związane z kradzieżą poświadczeń i danych kartowych,
ćwiczenia phishingowe obejmujące także kanał SMS, a nie tylko e-mail,
współpraca z operatorami telekomunikacyjnymi, dostawcami chmury i partnerami prawnymi przy zgłaszaniu nadużyć.

Dla użytkowników końcowych podstawowe zasady pozostają niezmienne: nie klikać w linki z nieoczekiwanych wiadomości, weryfikować nadawcę innym kanałem, samodzielnie wpisywać adres usługi w przeglądarce oraz natychmiast zgłaszać podejrzane komunikaty. Jeśli dane zostały podane na fałszywej stronie, należy niezwłocznie zmienić hasło, sprawdzić aktywność konta i skontaktować się z bankiem lub wystawcą karty.

Podsumowanie

Rozbicie Outsider Enterprise pokazuje, że nowoczesny phishing funkcjonuje dziś jak dojrzała usługa cyberprzestępcza, a sztuczna inteligencja staje się dla niej naturalnym akceleratorem. Skala operacji, obejmująca tysiące witryn i ponad milion URL-i, potwierdza, że zagrożenie wykracza daleko poza proste, pojedyncze oszustwa.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że model reaktywny nie wystarcza. Potrzebne są automatyzacja, lepsza ochrona poświadczeń, silniejsze zabezpieczenia mobilne oraz zdolność szybkiego reagowania na kampanie, które mogą być odtwarzane niemal natychmiast po ich częściowym zablokowaniu.

Źródła

CISA dodaje krytyczną lukę Ivanti Sentry do katalogu KEV i wyznacza pilny termin łatania

Wprowadzenie do problemu / definicja

Amerykańska agencja CISA dopisała podatność CVE-2026-10520 dotyczącą Ivanti Sentry do katalogu Known Exploited Vulnerabilities. Taki status oznacza, że luka jest wykorzystywana w rzeczywistych atakach lub istnieją wiarygodne przesłanki wskazujące na aktywną eksploatację. Problem dotyczy krytycznej podatności typu OS command injection, która może umożliwić zdalne wykonanie kodu z uprawnieniami roota bez uwierzytelnienia.

W skrócie

Luka CVE-2026-10520 wpływa na Ivanti Sentry, czyli bramę bezpieczeństwa pośredniczącą między urządzeniami mobilnymi a zasobami firmowymi. Podatność została oceniona maksymalnie w skali CVSS i umożliwia nieautoryzowanemu atakującemu przejęcie kontroli nad systemem.

CISA włączyła błąd do katalogu KEV.
Amerykańskie agencje federalne otrzymały termin wdrożenia poprawek do 14 czerwca 2026 r.
Publicznie dostępne instancje mogły zostać zaatakowane krótko po publikacji poprawek.
Zagrożone są wersje wcześniejsze niż R10.5.2, R10.6.2 oraz R10.7.1.

Kontekst / historia

Ivanti Sentry jest wykorzystywany w środowiskach korporacyjnych do ochrony komunikacji między urządzeniami mobilnymi a systemami wewnętrznymi. Ze względu na swoją pozycję architektoniczną pełni rolę punktu zaufania i kontroli ruchu, dlatego każda krytyczna podatność w tym komponencie ma szczególnie poważne znaczenie operacyjne.

Dodanie luki do katalogu KEV nie jest wyłącznie formalnością. W praktyce oznacza to, że organizacje powinny traktować problem jako aktywne zagrożenie wymagające natychmiastowej reakcji. W przypadku podmiotów federalnych bardzo krótki termin usunięcia podatności podkreśla wysoką ocenę ryzyka oraz pilny charakter remediacji.

Analiza techniczna

CVE-2026-10520 to podatność typu OS command injection w Ivanti Sentry. Tego rodzaju błąd występuje, gdy aplikacja lub komponent systemowy nieprawidłowo przetwarza dane wejściowe i dopuszcza wstrzyknięcie komend systemowych. Jeżeli luka jest osiągalna zdalnie i nie wymaga uwierzytelnienia, atakujący może przesłać specjalnie przygotowane żądanie prowadzące do uruchomienia poleceń na systemie operacyjnym urządzenia.

Najpoważniejszym aspektem tej luki jest możliwość uzyskania zdalnego wykonania kodu z uprawnieniami roota. W praktyce daje to pełną kontrolę nad podatnym urządzeniem, możliwość instalacji trwałych mechanizmów dostępu, modyfikacji konfiguracji, przechwytywania ruchu oraz wykorzystania bramy jako punktu wejścia do dalszego ruchu bocznego w sieci organizacji.

Według dostępnych informacji problem dotyczy wersji wcześniejszych niż R10.5.2, R10.6.2 oraz R10.7.1. Oznacza to, że organizacje utrzymujące starsze wydania pozostają narażone do czasu skutecznego wdrożenia aktualizacji. Istotne jest również to, że obserwatorzy zagrożeń raportowali próby wykorzystania luki oraz oznaki backdooringu niektórych publicznie dostępnych instancji, co sugeruje bardzo krótki czas między ujawnieniem szczegółów a rozpoczęciem działań ofensywnych.

Konsekwencje / ryzyko

Ryzyko związane z eksploatacją Ivanti Sentry jest wysokie z kilku powodów. Po pierwsze, urządzenie znajduje się na styku sieci zaufanej i komunikacji mobilnej, więc jego kompromitacja może umożliwić obejście klasycznych granic bezpieczeństwa. Po drugie, uzyskanie uprawnień roota oznacza pełne przejęcie appliance’u. Po trzecie, tego typu systemy często mają dostęp do wrażliwych danych uwierzytelniających, polityk dostępu, kanałów synchronizacji oraz ruchu aplikacyjnego.

W praktyce udany atak może prowadzić do kradzieży danych, utraty integralności konfiguracji, przejęcia sesji administracyjnych, dalszej penetracji środowiska wewnętrznego oraz ustanowienia trwałej obecności w infrastrukturze. Jeżeli podatna instancja jest wystawiona do internetu, okno ekspozycji znacząco rośnie, a czas reakcji staje się kluczowym czynnikiem ograniczającym skutki incydentu.

Rekomendacje

Organizacje korzystające z Ivanti Sentry powinny priorytetowo zidentyfikować wszystkie instancje tego rozwiązania, zweryfikować ich wersje i niezwłocznie przeprowadzić aktualizację do wydań usuwających podatność. Samo wdrożenie poprawek może jednak nie być wystarczające, jeśli system był wcześniej dostępny z internetu i mógł zostać skompromitowany.

Przeprowadzić natychmiastowy przegląd ekspozycji internetowej wszystkich instancji Ivanti Sentry.
Zaktualizować systemy do wersji R10.5.2, R10.6.2, R10.7.1 lub nowszych zgodnie z obsługiwanym torem produktu.
Przeanalizować logi systemowe i sieciowe pod kątem nietypowych żądań, uruchomień poleceń oraz śladów zdalnej aktywności administracyjnej.
Zweryfikować integralność urządzeń i poszukać oznak backdoorów, nowych kont, nietypowych zadań oraz zmian konfiguracyjnych.
Przeprowadzić rotację poświadczeń administracyjnych i wszystkich sekretów, które mogły być dostępne z poziomu appliance’u.
Ograniczyć zaufanie do podejrzanej instancji poprzez segmentację sieci i kontrolę komunikacji do czasu zakończenia dochodzenia.
Objąć system wzmożonym monitoringiem EDR, NDR i SIEM, jeśli pozwala na to architektura środowiska.
Przygotować scenariusz incident response zakładający, że niezałatana instancja mogła zostać przejęta.

W środowiskach o podwyższonym poziomie krytyczności warto traktować niezałataną lub publicznie wystawioną instancję jako potencjalnie naruszoną i prowadzić działania dochodzeniowe równolegle z procesem aktualizacji.

Podsumowanie

CVE-2026-10520 w Ivanti Sentry to krytyczna podatność umożliwiająca zdalne wykonanie kodu jako root bez uwierzytelnienia. Dodanie jej do katalogu KEV przez CISA oraz krótki termin remediacji wskazują na wysoki poziom zagrożenia i realne ryzyko eksploatacji. Dla organizacji korzystających z tego rozwiązania priorytetem powinny być szybkie łatanie, weryfikacja możliwej kompromitacji oraz przegląd całej ścieżki zaufania związanej z dostępem mobilnym do zasobów przedsiębiorstwa.

Źródła

Security Affairs — https://securityaffairs.com/193557/security/u-s-cisa-adds-ivanti-sentry-flaw-to-its-known-exploited-vulnerabilities-catalog-and-urges-patching-by-june-14.html
CVE Record: CVE-2026-10520 — https://www.cve.org/CVERecord?id=CVE-2026-10520
CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Ivanti Security Advisory: Ivanti Sentry CVE-2026-10520 — https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Sentry-CVE-2026-10520

CISA dodaje krytyczną lukę Oracle PeopleSoft PeopleTools do katalogu KEV

Wprowadzenie do problemu / definicja

Amerykańska agencja CISA dodała podatność CVE-2026-35273 dotyczącą Oracle PeopleSoft Enterprise PeopleTools do katalogu Known Exploited Vulnerabilities. Taki krok oznacza, że luka jest aktywnie wykorzystywana w rzeczywistych atakach i wymaga pilnej reakcji ze strony administratorów oraz zespołów bezpieczeństwa.

Problem dotyczy komponentu Environment Management i może prowadzić do zdalnego wykonania kodu bez uwierzytelnienia. W praktyce oznacza to, że napastnik posiadający dostęp sieciowy do podatnego punktu końcowego może przejąć kontrolę nad systemem bez użycia prawidłowych danych logowania.

W skrócie

CVE-2026-35273 to krytyczna podatność RCE o ocenie CVSS 9.8.
Luka dotyczy Oracle PeopleSoft Enterprise PeopleTools, w szczególności komponentu Environment Management.
Atak nie wymaga uwierzytelnienia ani interakcji użytkownika.
CISA umieściła podatność w katalogu KEV, potwierdzając aktywną eksploatację.
Według dostępnych analiz luka była wykorzystywana jako zero-day.

Kontekst / historia

Oracle PeopleSoft PeopleTools to warstwa technologiczna wspierająca działanie aplikacji PeopleSoft wykorzystywanych w środowiskach korporacyjnych, administracyjnych i akademickich. Z tego powodu każda krytyczna podatność w tym komponencie może wpływać na systemy odpowiedzialne za kadry, finanse, obsługę studentów czy procesy administracyjne.

Znaczenie sprawy wzrosło po ujawnieniu informacji o aktywnej kampanii ataków prowadzonej jeszcze przed oficjalnym nagłośnieniem zagrożenia. Dostępne raporty wskazują, że aktywność obserwowano od końca maja do początku czerwca 2026 roku, co sugeruje okres pełnoprawnej eksploatacji typu zero-day. Szczególnie często wskazywano organizacje ze szkolnictwa wyższego, które przechowują duże wolumeny danych osobowych i operują rozbudowanymi wdrożeniami PeopleSoft.

Analiza techniczna

Podatność CVE-2026-35273 dotyczy komponentu Environment Management w Oracle PeopleSoft Enterprise PeopleTools. Technicznie jest to luka umożliwiająca zdalne wykonanie kodu przez sieć bez potrzeby wcześniejszego uwierzytelnienia, co znacząco obniża próg wejścia dla atakującego.

Kluczowym elementem powierzchni ataku jest Environment Management Hub, często identyfikowany jako PSEMHUB. Jeżeli usługa jest wystawiona i osiągalna z sieci, napastnik może uzyskać wykonanie kodu na serwerze aplikacyjnym. Taki dostęp otwiera drogę do instalacji narzędzi post-eksploatacyjnych, rekonesansu środowiska oraz dalszego ruchu bocznego.

Analizy incydentów wskazują, że po uzyskaniu dostępu napastnicy wdrażali oprogramowanie do zdalnego zarządzania, przygotowywali infrastrukturę dowodzenia i kontroli, badali konfiguracje PeopleSoft i WebLogic, a następnie przemieszczali się do kolejnych systemów. W części przypadków wykorzystywano także automatyzację do rozprzestrzeniania się w środowisku oraz mechanizmy kompresji i eksfiltracji danych.

Oracle potwierdziło, że zagrożone są wspierane wersje PeopleTools 8.61 i 8.62, a starsze, niewspierane wydania również mogą pozostawać narażone. To szczególnie ważne dla organizacji, które utrzymują starsze instalacje z powodów operacyjnych, budżetowych lub zgodnościowych.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2026-35273 należy uznać za bardzo wysokie. Zdalne wykonanie kodu bez uwierzytelnienia w systemie klasy enterprise może oznaczać pełne przejęcie serwera obsługującego wrażliwe procesy biznesowe i administracyjne.

W zależności od architektury środowiska kompromitacja może prowadzić do dostępu do danych osobowych, danych płacowych, informacji identyfikacyjnych, dokumentacji wewnętrznej oraz poświadczeń technicznych. Dla uczelni i dużych organizacji publicznych lub prywatnych może to oznaczać incydent o szerokiej skali operacyjnej i reputacyjnej.

Dodatkowym zagrożeniem jest ruch boczny. Po przejęciu węzła PeopleSoft atakujący może próbować rozszerzyć dostęp na inne serwery aplikacyjne, repozytoria konfiguracyjne, harmonogramy zadań i systemy powiązane. W słabo segmentowanych środowiskach pojedyncza luka może stać się punktem wyjścia do kampanii ransomware albo długotrwałej operacji szpiegowskiej.

Nie można też wykluczyć długiej obecności napastnika w infrastrukturze. Wykorzystanie legalnych lub półlegalnych narzędzi administracyjnych utrudnia wykrycie, ponieważ część aktywności może przypominać zwykłe działania operacyjne prowadzone przez administratorów.

Rekomendacje

Organizacje korzystające z Oracle PeopleSoft powinny potraktować tę podatność jako priorytet krytyczny. W pierwszej kolejności należy zastosować poprawki i środki zaradcze opublikowane przez Oracle dla wspieranych wersji 8.61 i 8.62.

Jeżeli pełne załatanie nie jest możliwe natychmiast, konieczne jest ograniczenie powierzchni ataku. W środowiskach wieloserwerowych zalecane jest wyłączenie usługi Environment Management Hub, natomiast w środowiskach jednoserwerowych warto rozważyć usunięcie aplikacji PSEMHUB zgodnie z wytycznymi producenta. Należy również zablokować zewnętrzny dostęp do ścieżek związanych z PSEMHUB oraz interfejsów nasłuchujących bramy integracyjnej.

przeprowadzić przegląd logów PeopleSoft i WebLogic pod kątem nietypowych żądań do komponentów Environment Management,
zweryfikować obecność narzędzi zdalnego zarządzania, niestandardowych agentów i nowych zadań systemowych,
sprawdzić połączenia wychodzące do nietypowych hostów i usług TLS,
przeanalizować pliki konfiguracyjne pod kątem nieautoryzowanych zmian,
wymusić rotację poświadczeń administracyjnych i technicznych w razie podejrzenia kompromitacji,
wdrożyć segmentację sieci oraz ograniczyć komunikację PeopleSoft z systemami niekrytycznymi,
uruchomić działania threat hunting pod kątem ruchu bocznego i artefaktów pozostawionych przez automatyzację ataku.

W przypadku organizacji publicznie udostępniających komponenty PeopleSoft uzasadnione jest również wykonanie pełnego przeglądu ekspozycji internetowej oraz testów bezpieczeństwa skoncentrowanych na aplikacjach ERP.

Podsumowanie

Dodanie CVE-2026-35273 do katalogu KEV potwierdza, że luka w Oracle PeopleSoft PeopleTools nie jest wyłącznie zagrożeniem teoretycznym, lecz realnym wektorem ataku wykorzystywanym w środowiskach produkcyjnych. Połączenie braku uwierzytelnienia, możliwości zdalnego wykonania kodu i potwierdzonej aktywnej eksploatacji czyni z niej jeden z najpilniejszych problemów bezpieczeństwa dla administratorów tej platformy.

Dla organizacji oznacza to konieczność natychmiastowego łatania, ograniczania ekspozycji komponentu PSEMHUB oraz przeprowadzenia działań detekcyjnych pod kątem już istniejącej kompromitacji. Zwłoka w reakcji może znacząco zwiększyć skalę potencjalnych strat technicznych, operacyjnych i prawnych.

Źródła

Security Affairs — https://securityaffairs.com/193574/security/u-s-cisa-adds-oracle-peoplesoft-enterprise-peopletools-flaw-to-its-known-exploited-vulnerabilities-catalog.html
Oracle Security Alert Advisory – CVE-2026-35273 — https://www.oracle.com/security-alerts/alert-cve-2026-35273.html
CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
CVE Record: CVE-2026-35273 — https://www.cve.org/CVERecord?id=CVE-2026-35273

ShinyHunters wykorzystuje lukę zero-day w Oracle PeopleSoft do ataków na uczelnie

Wprowadzenie do problemu / definicja

Nowo ujawniona podatność zero-day w Oracle PeopleSoft PeopleTools stała się elementem aktywnej kampanii prowadzonej przez grupę ShinyHunters. Luka oznaczona jako CVE-2026-35273 dotyczy komponentu Environment Management Hub i umożliwia zdalne wykonanie kodu bez uwierzytelnienia. Ze względu na szerokie wykorzystanie PeopleSoft w obszarach administracji, kadr, płac oraz obsługi studentów, incydent szczególnie mocno uderza w sektor szkolnictwa wyższego.

W skrócie

Atakujący wykorzystywali podatność CVE-2026-35273 od 27 maja do 9 czerwca 2026 r., jeszcze przed publikacją oficjalnych ostrzeżeń bezpieczeństwa. Problem otrzymał krytyczną ocenę CVSS 9.8 i pozwalał na pełne przejęcie podatnego systemu bez logowania. Według dostępnych ustaleń kampania objęła ponad 100 organizacji, z czego znaczną część stanowiły uczelnie, głównie w Stanach Zjednoczonych.

luka umożliwia zdalne wykonanie kodu bez uwierzytelnienia,
celem były instancje PeopleSoft wystawione do Internetu,
w działaniach poeksploatacyjnych obserwowano m.in. użycie MeshCentral,
atakom towarzyszyły rozpoznanie środowiska, próby ruchu bocznego i eksfiltracja danych.

Kontekst / historia

PeopleSoft pozostaje jednym z najważniejszych systemów ERP wykorzystywanych przez duże organizacje, w tym uniwersytety i instytucje publiczne. Platforma obsługuje procesy kadrowe, finansowe i administracyjne, a także przechowuje duże ilości danych osobowych oraz operacyjnych. Z tego powodu od lat stanowi atrakcyjny cel dla grup specjalizujących się w wymuszeniach i kradzieży danych.

Opisana kampania wpisuje się w szerszy trend ataków na sektor edukacyjny, który często zmaga się z rozproszoną infrastrukturą, rozbudowanymi integracjami i opóźnieniami w aktualizacjach. W tym przypadku kluczowe znaczenie miało nie tylko wykorzystanie luki zero-day, ale również selektywne wyszukiwanie organizacji, których komponent Environment Management Hub był publicznie dostępny.

Analiza techniczna

Podatność CVE-2026-35273 dotyczy Oracle PeopleSoft Enterprise PeopleTools, a konkretnie komponentu odpowiedzialnego za Environment Management. Jej charakter umożliwia zdalne wykonanie kodu bez wcześniejszego uwierzytelnienia, co oznacza, że przeciwnik może przejąć podatny serwer bez znajomości danych dostępowych.

Ataki koncentrowały się na endpointach PSEMHUB, czyli instancjach Environment Management Hub wystawionych do sieci publicznej. Komponent ten odpowiada za funkcje pomocnicze związane z zarządzaniem agentami i środowiskiem PeopleSoft. Istotne jest to, że jego ograniczenie lub wyłączenie nie powinno wpływać na podstawowe sesje użytkowników korzystających z przeglądarkowej architektury systemu.

Po uzyskaniu dostępu operatorzy wdrażali narzędzia służące do utrzymania obecności w środowisku i dalszej eksploracji. W analizowanych incydentach pojawiały się zmodyfikowane agenty MeshCentral, maskowane nazwami przypominającymi legalne usługi chmurowe. Następnie wykonywano polecenia administracyjne w celu rozpoznania hosta, identyfikacji zasobów oraz przygotowania ruchu bocznego, w tym z użyciem poświadczeń SSH. W kolejnych etapach dane kompresowano przy użyciu Zstandard i przygotowywano do eksfiltracji.

Cały schemat działania wskazuje na wysoki poziom automatyzacji. Atakujący łączyli szybkie skanowanie podatnych instancji z natychmiastowym wdrażaniem narzędzi do zdalnego zarządzania i uruchamianiem skryptów poeksploatacyjnych. To model typowy dla grup nastawionych na wymuszenie, gdzie czas pomiędzy uzyskaniem dostępu a kradzieżą danych jest maksymalnie skracany.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem kampanii jest ryzyko wycieku danych wrażliwych. W środowisku uczelni mogą to być dane studentów, pracowników, kandydatów, informacje kadrowe, płacowe, finansowe oraz dane operacyjne związane z funkcjonowaniem instytucji.

Z perspektywy bezpieczeństwa organizacji zagrożenie ma kilka warstw. Zdalne wykonanie kodu na systemie ERP może doprowadzić do kompromitacji krytycznych procesów biznesowych. Dodatkowo PeopleSoft często jest zintegrowany z katalogami tożsamości, serwerami aplikacyjnymi oraz innymi usługami zaplecza, co zwiększa ryzyko ruchu bocznego. Nawet bez wdrożenia szyfrowania systemów sama kradzież danych może zostać wykorzystana jako skuteczne narzędzie nacisku.

Istotnym problemem jest także możliwość opóźnionego wykrycia incydentu. Jeśli organizacja nie była świadoma ekspozycji EMHub do Internetu, aktywność przeciwnika mogła przez pewien czas wyglądać jak legalne działania administracyjne. To utrudnia identyfikację kompromitacji na podstawie standardowych alertów aplikacyjnych.

Rekomendacje

Organizacje korzystające z Oracle PeopleSoft powinny potraktować tę sprawę priorytetowo. Pierwszym krokiem powinno być natychmiastowe wdrożenie oficjalnych poprawek i zaleceń producenta dla obsługiwanych wersji PeopleTools 8.61 oraz 8.62. Równolegle należy sprawdzić, czy komponent Environment Management Hub jest dostępny z Internetu, i w miarę możliwości całkowicie odciąć go od sieci publicznej.

wyłączyć EMHub, jeśli nie jest niezbędny operacyjnie,
ograniczyć dostęp do endpointów PSEMHUB wyłącznie do zaufanych segmentów sieci,
przeanalizować logi serwerów aplikacyjnych, WebLogic, reverse proxy i WAF z okresu od 27 maja do 9 czerwca 2026 r.,
wyszukać ślady użycia MeshCentral oraz nietypowych agentów imitujących legalne usługi,
sprawdzić hosty pod kątem nowych procesów, zadań, binariów i połączeń wychodzących,
przeprowadzić reset poświadczeń administracyjnych i technicznych w razie podejrzenia kompromitacji,
objąć monitoringiem serwery powiązane z PeopleSoft i systemy zintegrowane.

Warto pamiętać, że web application firewall może ograniczyć część prób wykorzystania luki, ale nie zastępuje poprawki ani zmiany ekspozycji usługi. Kluczowe znaczenie mają segmentacja sieci, minimalizacja powierzchni ataku i szybkie działania dochodzeniowe.

Podsumowanie

Kampania ShinyHunters pokazuje, jak groźne są niezałatane i publicznie dostępne komponenty zaplecza systemów ERP. CVE-2026-35273 łączy brak wymogu uwierzytelnienia, możliwość zdalnego wykonania kodu oraz wysoki potencjał operacyjny dla grup wymuszeniowych. Dla sektora szkolnictwa wyższego oznacza to pilną potrzebę patchowania, ograniczenia ekspozycji EMHub oraz szczegółowego przeglądu środowiska pod kątem oznak kompromitacji.

Źródła

Atak grupy Handala na amerykańskie wodociągi ujawnia słabości styku IT i OT

Wprowadzenie do problemu / definicja

Incydent przypisywany powiązanej z Iranem grupie Handala pokazuje, jak duże ryzyko dla operatorów infrastruktury krytycznej może wynikać z pozornie drugorzędnych systemów technicznych. Według dostępnych informacji atakujący uzyskali dostęp do środowiska California Water Service, obejmującego zarówno dane klientów, jak i narzędzie wspierające precyzyjne operacje terenowe oparte na korekcji GNSS.

To ważny przykład naruszenia, w którym komponent pomocniczy nie był jedynie peryferyjnym elementem infrastruktury, lecz potencjalnym punktem wejścia do znacznie bardziej wrażliwych zasobów biznesowych. Z perspektywy cyberbezpieczeństwa szczególnie istotne jest tu nie tylko samo włamanie, ale architektura połączeń między światem IT i OT.

W skrócie

Napastnicy mieli opublikować próbkę danych o rozmiarze około 5 GB jako dowód skutecznego włamania. Z opisu incydentu wynika, że naruszenie objęło co najmniej dwa obszary: bazę rozliczeniową klientów oraz wewnętrzną instancję RTKBase, czyli otwartoźródłową platformę GNSS używaną przez zespoły terenowe.

naruszono dane osobowe i rozliczeniowe klientów,
ujawniono dostęp do środowiska RTKBase,
pojawiają się pytania o właściwą segmentację sieci,
nie potwierdzono sabotażu OT ani SCADA, ale ryzyko eskalacji pozostaje realne.

Kontekst / historia

Handala od dłuższego czasu funkcjonuje jako aktor prowadzący operacje o charakterze hacktywistycznym, informacyjnym i destrukcyjnym. Grupa bywa łączona z irańskim ekosystemem operacji cybernetycznych i była wcześniej wiązana z kradzieżą danych, publikacją wykradzionych materiałów oraz presją psychologiczną wobec ofiar.

Atak na operatora wodociągowego wpisuje się w szerszy trend wzrostu zagrożeń wobec infrastruktury krytycznej w Stanach Zjednoczonych. Amerykańskie agencje od dłuższego czasu ostrzegają sektor wodny przed aktywnością podmiotów powiązanych z Iranem, szczególnie wobec systemów dostępnych z internetu, komponentów przemysłowych i urządzeń zarządzania zdalnego.

W tym ujęciu incydent nie wygląda na jednostkowe zdarzenie, lecz na praktyczne potwierdzenie wcześniej sygnalizowanego scenariusza zagrożeń. Sektor wodociągowy staje się atrakcyjnym celem nie tylko ze względu na znaczenie operacyjne, ale również potencjalny efekt psychologiczny i propagandowy.

Analiza techniczna

Najciekawszym elementem technicznym tej sprawy jest wykorzystanie środowiska RTKBase. To lekkie, webowe rozwiązanie wdrażane często na prostym sprzęcie, używane do obsługi korekcji GNSS i usług NTRIP dla prac terenowych. Jeżeli panel administracyjny takiej platformy zostaje wystawiony do internetu, może stać się łatwym celem, zwłaszcza gdy organizacja traktuje go jako narzędzie pomocnicze, a nie zasób o podwyższonym ryzyku.

Z dostępnych opisów wynika, że ujawnione zostały dane uwierzytelniające do platformy RTKBase oraz informacje o infrastrukturze sieciowej i punktach montowania NTRIP dla wielu dystryktów. Taka ekspozycja ma podwójne znaczenie: potwierdza realny dostęp do systemu i jednocześnie może odsłaniać potencjalne ścieżki dalszego poruszania się po sieci.

Najpoważniejszy wniosek dotyczy prawdopodobnego braku odpowiedniej separacji pomiędzy systemem wspierającym operacje terenowe a środowiskiem rozliczeniowym. W poprawnie zaprojektowanej architekturze komponent taki jak RTKBase nie powinien umożliwiać przejścia do systemów zawierających dane osobowe klientów. Jeśli jednak wspólne poświadczenia, zaufanie sieciowe, błędna segmentacja lub niewłaściwe reguły routingu umożliwiły pivoting, niszowy punkt wejścia mógł zostać przekształcony w pełnowymiarowy incydent naruszenia danych.

Dodatkowym czynnikiem ryzyka jest profil samego aktora. Grupa Handala była wcześniej łączona z działaniami destrukcyjnymi, w tym z użyciem narzędzi typu wiper. Oznacza to, że publikacja danych może stanowić jedynie jeden z etapów operacji, a nie jej zakończenie. W środowisku infrastruktury krytycznej taki scenariusz jest szczególnie niebezpieczny, ponieważ faza rozpoznania i wycieku może poprzedzać próbę zakłócenia działania usług.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem incydentu jest naruszenie poufności danych klientów. W zależności od zakresu wycieku mogą to być nazwiska, adresy, numery telefonów, dane kont oraz informacje rozliczeniowe. Taki zestaw danych zwiększa ryzyko phishingu ukierunkowanego, oszustw podszywających się pod dostawcę usług komunalnych oraz skuteczniejszych kampanii inżynierii społecznej.

Pośrednie ryzyko dotyczy bezpieczeństwa operacyjnego. Nawet jeśli nie doszło do ingerencji w SCADA, dozowanie chemikaliów czy sterowanie procesem uzdatniania wody, sam fakt możliwego powiązania systemu pomocniczego z siecią korporacyjną pokazuje, że granica między IT i OT mogła być zbyt słaba. W praktyce oznacza to ryzyko dalszej eskalacji, sabotażu, wymuszeń lub działań destrukcyjnych w kolejnych etapach kampanii.

Incydent ma również wymiar strategiczny. Operatorzy infrastruktury krytycznej są coraz częściej celem nie tylko grup nastawionych na zysk, ale też podmiotów realizujących cele polityczne, odwetowe i psychologiczne. W takim modelu nawet ograniczone włamanie może zostać wykorzystane do wywołania presji społecznej i osłabienia zaufania do usług publicznych.

Rekomendacje

Organizacje z sektora wodnego powinny potraktować ten przypadek jako sygnał do pilnego przeglądu architektury styku IT i OT. W pierwszej kolejności należy zidentyfikować wszystkie systemy pomocnicze wystawione do internetu, w tym platformy GNSS, NTRIP, telemetrię, zdalne panele serwisowe oraz urządzenia administracyjne działające na niestandardowych portach.

wdrożyć twardą segmentację sieciową między systemami terenowymi, billingiem i środowiskami administracyjnymi,
ograniczyć komunikację zgodnie z zasadą najmniejszych uprawnień,
przeprowadzić pełną rotację poświadczeń dla kont administracyjnych, usług i integracji,
włączyć MFA wszędzie tam, gdzie jest to możliwe,
ukryć interfejsy administracyjne za VPN, bastionami lub zaufanymi bramami dostępu,
przeprowadzić retrospective hunting pod kątem logowań, eksportów danych i prób ruchu lateralnego,
zweryfikować, czy systemy OT i serwery pomocnicze nie współdzielą kont, kluczy SSH ani relacji zaufania,
przygotować scenariusze reagowania obejmujące zarówno wyciek danych, jak i potencjalny etap destrukcyjny.

Istotne jest również zabezpieczenie kopii offline oraz gotowość do izolacji segmentów i przejścia na procedury ręczne. W sektorze usług komunalnych odporność operacyjna jest równie ważna jak sama prewencja.

Podsumowanie

Przypadek California Water Service pokazuje, że najsłabszym ogniwem infrastruktury krytycznej nie musi być główny system sterowania. Często większym problemem okazuje się poboczny komponent techniczny, który został niewłaściwie wystawiony do internetu i niedostatecznie odseparowany od reszty środowiska.

Wyciek danych klientów jest poważnym incydentem samym w sobie, ale jeszcze ważniejszy jest płynący z niego wniosek architektoniczny. Każdy system operacyjny, nawet pomocniczy, może stać się punktem wejścia do znacznie szerszej kompromitacji. Dla operatorów wodociągów i innych usług komunalnych to wyraźne ostrzeżenie, że cyberbezpieczeństwo musi obejmować cały ekosystem IT i OT.

Źródła

npm 12 zaostrzy wykonywanie skryptów i utrudni ataki na łańcuch dostaw

Wprowadzenie do problemu / definicja

Ekosystem npm pozostaje jednym z fundamentów współczesnego rozwoju aplikacji opartych na JavaScript i Node.js. Jednocześnie od lat jest też atrakcyjnym celem ataków na łańcuch dostaw oprogramowania, ponieważ proces instalacji zależności może uruchamiać kod jeszcze zanim aplikacja zostanie zbudowana lub uruchomiona.

Zapowiedziane zmiany w npm 12 mają ograniczyć to ryzyko poprzez odejście od modelu domyślnego wykonywania skryptów instalacyjnych w zależnościach. Nowe podejście opiera się na zasadzie jawnego zaufania, w której wykonywanie określonych skryptów będzie wymagało świadomej zgody ze strony projektu.

W skrócie

Najważniejsza zmiana polega na tym, że npm 12 ma domyślnie blokować wykonywanie skryptów preinstall, install i postinstall pochodzących z zależności, o ile nie zostaną one wcześniej zatwierdzone. Ograniczenia obejmą również niejawne budowanie natywnych modułów przez node-gyp, skrypty prepare dla zależności z Gita, źródeł lokalnych i linków oraz automatyczne rozwiązywanie zależności pochodzących z repozytoriów Git i zdalnych archiwów.

domyślne blokowanie skryptów instalacyjnych w zależnościach,
większa kontrola nad pakietami natywnymi i procesem builda,
ograniczenie ryzykownych źródeł zależności spoza rejestru,
przejście z modelu implicit trust do modelu allowlisty.

Kontekst / historia

Zmiana jest odpowiedzią na rosnącą liczbę incydentów supply chain w ekosystemie JavaScript. W wielu przypadkach atakujący wykorzystywali mechanizm automatycznego uruchamiania skryptów podczas npm install, aby wykonać złośliwy kod na stacjach deweloperskich, w środowiskach CI/CD oraz w procesach budowania.

Taki wektor ataku jest szczególnie groźny, ponieważ działa na bardzo wczesnym etapie cyklu życia aplikacji. Jeśli kompromitacji ulegnie pojedyncza zależność, złośliwy kod może uzyskać dostęp do tokenów, sekretów, kluczy publikacyjnych lub innych wrażliwych danych obecnych w środowisku budowania.

Przez lata automatyczne wykonywanie skryptów było uznawane za wygodne i praktyczne rozwiązanie dla autorów bibliotek. Jednak wraz ze wzrostem liczby incydentów bezpieczeństwa stało się jasne, że ten sam mechanizm tworzy zbyt szeroką powierzchnię ataku.

Analiza techniczna

W npm 12 skrypty preinstall, install i postinstall w zależnościach nie będą już uruchamiane automatycznie. Oznacza to, że projekt będzie musiał jawnie dopuścić zaufane pakiety do wykonywania kodu na etapie instalacji.

Istotną częścią zmian jest również ograniczenie niejawnego uruchamiania node-gyp. Dotąd obecność pliku binding.gyp mogła prowadzić do automatycznej przebudowy modułu natywnego, nawet bez jawnie zdefiniowanego skryptu instalacyjnego. W nowym modelu także ta ścieżka ma zostać zablokowana, jeśli nie zostanie wyraźnie dopuszczona.

Zmiany obejmą też skrypty prepare dla zależności pobieranych z niestandardowych źródeł, takich jak repozytoria Git, zależności typu file: czy link:. W praktyce oznacza to dodatkową ochronę przed wykonaniem nieautoryzowanej logiki pochodzącej spoza standardowego rejestru pakietów.

npm 12 ma również ograniczyć domyślne rozwiązywanie zależności Git oraz zdalnych archiwów. To ważne, ponieważ takie źródła zwiększają nie tylko złożoność procesu instalacji, ale również ryzyko niekontrolowanego pobrania i wykonania kodu.

Wersje npm 11.16.0 i nowsze udostępniają już mechanizmy przygotowawcze. Narzędzie npm approve-scripts --allow-scripts-pending pozwala sprawdzić, które pakiety próbowałyby uruchamiać skrypty, a następnie zbudować kontrolowaną listę wyjątków zapisywaną w konfiguracji projektu.

Konsekwencje / ryzyko

Z punktu widzenia cyberbezpieczeństwa to jedna z najważniejszych zmian w npm od lat. Ograniczenie automatycznego wykonania kodu podczas instalacji znacząco utrudnia przeprowadzenie wielu ataków supply chain, szczególnie tych nastawionych na przejęcie środowisk deweloperskich i pipeline’ów CI/CD.

Jednocześnie nowy model może spowodować skutki operacyjne. Część legalnych pakietów wykorzystuje skrypty instalacyjne do kompilacji komponentów natywnych, pobierania binariów, generowania zasobów lub przygotowania artefaktów. Po wdrożeniu npm 12 niektóre projekty mogą wymagać dodatkowej konfiguracji albo ręcznego zatwierdzenia wybranych zależności.

Największe ryzyko dotyczy organizacji, które nie przygotują się do zmiany wcześniej. W starszych kodbazach, monorepo i środowiskach automatyzacji nowe zasady mogą prowadzić do błędów instalacji, przerw w buildach i opóźnień wdrożeń.

Rekomendacje

Zespoły korzystające z Node.js powinny już teraz przeprowadzić przegląd zależności uruchamiających skrypty podczas instalacji. Wczesne przygotowanie pozwoli ograniczyć problemy operacyjne i jednocześnie poprawić widoczność ryzyka w łańcuchu dostaw.

zaktualizować środowiska deweloperskie i CI do wersji npm obsługujących nowe mechanizmy kontroli,
uruchomić przegląd zależności z użyciem funkcji zatwierdzania skryptów,
zatwierdzać wyłącznie pakiety niezbędne i wcześniej zweryfikowane,
preferować precyzyjne wyjątki dla konkretnych wersji zamiast szerokich reguł,
przeanalizować użycie zależności z Gita, file: i link:,
ograniczyć korzystanie ze zdalnych archiwów jako źródeł pakietów,
przetestować pipeline’y CI/CD przed przejściem na npm 12,
monitorować zmiany w package.json, lockfile’ach i politykach allowlisty.

Dla zespołów AppSec i DevSecOps jest to również dobry moment, aby wzmocnić governance wokół pakietów open source. Blokowanie skryptów nie zastępuje skanowania podatności, kontroli integralności buildów ani ochrony sekretów, ale stanowi bardzo ważną warstwę prewencyjną.

Podsumowanie

npm 12 wprowadza fundamentalną zmianę w podejściu do bezpieczeństwa instalacji zależności. Domyślne blokowanie skryptów, ograniczenie niejawnych ścieżek wykonania przez node-gyp oraz zaostrzenie zasad dla zależności gitowych i zdalnych wzmacniają ochronę przed atakami na łańcuch dostaw.

Dla zespołów programistycznych oznacza to konieczność przeglądu procesów i zależności, ale z perspektywy bezpieczeństwa jest to ruch w stronę bardziej przewidywalnego i kontrolowanego modelu zaufania.

Źródła

SecurityWeek — NPM 12 Will Change Script Execution Behavior to Prevent Supply Chain Attacks — https://www.securityweek.com/npm-12-will-change-script-execution-behavior-to-prevent-supply-chain-attacks/
GitHub Changelog — Upcoming breaking changes for npm v12 — https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/
npm Docs — npm approve-scripts — https://docs.npmjs.com/cli/v11/commands/npm-approve-scripts/
npm Docs — npm install — https://docs.npmjs.com/cli/install/
npm Docs — Scripts — https://docs.npmjs.com/cli/v11/using-npm/scripts/