Czarny październik: co zostało zhakowane i jak się chronić

2026-10-23 • Daniel Agrici • AI zagraniczne •nowość •waga 3/5 •17 min czytania

Przegląd październikowej fali włamań: UpdraftPlus, PHP, LiteLLM, Railway — plus gotowe prompty do audytu własnego środowiska przez agenta AI. Dla utrzymujących strony WordPress i aplikacje z kluczami API.

Robocza publikacja redakcyjna na podstawie publicznego transkryptu YouTube. Źródło: YouTube.

Oryginalny tytuł filmu

Black October: what got hacked and how to stay safe

O czym jest ten film

  1. Autor zbiera serię październikowych incydentów bezpieczeństwa pod wspólną nazwą „Czarny październik”: włamania, wycieki danych osobowych, problemy banków i pełne wyłączenia internetu w niektórych krajach.
  2. 18 października zhakowano UpdraftPlus, popularną wtyczkę kopii zapasowych dla WordPressa. Skradziono klucze UpdraftCentral i instalowano nimi wtyczki z backdoorem — sama aktualizacja dodatku nie usuwa skutków włamania.
  3. Dwie luki w PHP, załatane 21 października, pozwalały przejąć serwer bez logowania. Bezpieczne wersje to 8.5.12, 8.4.27, 8.3.36 i 8.2.35 lub nowsze; PHP 8.1 i starsze nie dostaną oficjalnych poprawek.
  4. Wrzesień i październik to też ataki na łańcuch dostaw: znane dodatki programistyczne podmieniano na wersje kradnące hasła, a do tysięcy repozytoriów na GitHubie trafiły fałszywe „narzędzia bezpieczeństwa”.
  5. Firma certyfikacyjna eMudhra generowała klucze tak słabe, że jednym z nich była po prostu liczba cztery. Przeglądarki zdążyły je zablokować, narzędzia Pythona — nie; ratuje aktualizacja pip i certifi.
  6. Poprawki bezpieczeństwa wypuściły również Next.js, Node.js, Claude Code, Docker Desktop i Flatpak; autor przypomina o włączeniu dwuskładnikowego logowania.
  7. Zatruta wersja LiteLLM, narzędzia łączącego aplikacje z modelami AI, była dostępna przez dwie godziny 21 października i kradła hasła oraz klucze od razu po uruchomieniu.
  8. Railway po ataku był niedostępny przez cały dzień i prosi każdego użytkownika o wymianę haseł i kluczy; stare wersje Plex Media Server są w chwili nagrania aktywnie łamane.
  9. Autor podkreśla, że to nie lawina: PHP, Node, GitHub i Python to osobne zdarzenia o różnych przyczynach, które przypadkiem zbiegły się w jednym tygodniu.
  10. Całość domyka darmowy skill Protect Your Ass (PYA) — zespół agentów audytujących kod w Claude Code — oraz cztery zasady bezpiecznej pracy z agentami AI.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Aktualizacja wtyczki nie usuwa skutków włamania

Na czym polega: W ataku na UpdraftPlus złodzieje weszli w posiadanie kluczy UpdraftCentral i podszywali się pod właścicieli stron, instalując fałszywe dodatki. Wgranie nowej wersji załatania dziurę, ale nie unieważni kluczy, które mogły już wyciec — dlatego schemat „zaktualizuj i zapomnij” tu nie działa.

Jak stosować: Wgraj wersję 1.26.12 / 2.26.12 lub nowszą, a potem przejrzyj klucze w Ustawienia → Kopie zapasowe UpdraftPlus → Narzędzia zaawansowane, pełną listę wtyczek (wraz z mu-plugins i tymi instalowanymi po 18 października), konta administratorów założone po tej dacie oraz opcję _sync_token w bazie danych. Prompt od autora możesz wkleić agentowi albo po prostu pokazać mu zrzut ekranu.

Na co uważać: Podejrzanej wtyczki nie naprawiaj i nie aktywuj — najpierw usuń klucze, dopiero potem sam dodatek. Agent ma najpierw raportować i nie ruszać niczego bez twojej zgody; hasła i klucze nigdy nie mogą być wyświetlane w całości.

2.PHP: sprawdź dwie wersje, nie jedną

Na czym polega: Dwie październikowe luki w PHP pozwalały przejąć serwer bez podawania hasła, a atakujący zaczęli je wykorzystywać jeszcze przed wypuszczeniem poprawki. Bezpieczne linie to 8.5.12, 8.4.27, 8.3.36 i 8.2.35 lub nowsze; dla PHP 8.1 i starszych łatek już nie będzie.

Jak stosować: Na hostingu zarządzanym (Hetzner, cPanel i podobne) potwierdź u dostawcy, że łata jest wgrana — większość zdążyła. Na własnym serwerze sprawdź php -v oraz wersję, na której faktycznie działa strona (pule PHP-FPM albo phpinfo), a po aktualizacji zrestartuj wszystkie workery PHP-FPM. Jeśli strona stoi za Cloudflare, upewnij się, że proxy (pomarańczowa chmurka) jest włączone.

Na co uważać: Wersja w terminalu i wersja obsługująca stronę bywają różne — sprawdzaj obie. PHP 8.1 i starsze to ślepa uliczka: potrzebują planu migracji, a nie łatanie.

3.Każda nowa zależność z npm to potencjalny trojan

Na czym polega: W atakach na łańcuch dostaw podmieniano znane dodatki programistyczne na wersje kradnące hasła, a w tysiącach repozytoriów GitHuba osadzono fałszywe „audyty bezpieczeństwa”. Infekcja przychodzi razem z czymś, co instalujesz dobrowolnie.

Jak stosować: Przeszukaj pliki blokad i logi instalacji (package-lock.json, pnpm-lock.yaml, yarn.lock) za wrzesień–październik 2026 pod kątem wskaźnika podanego przez autora (tensorlake). W każdym repozytorium wylistuj pliki w GitHub Workflows i oflaguj te, których nie dodawałeś — zwłaszcza security-audit.yml i wszystko, co wysyła dane na nieznane adresy. Sprawdź też, czy skrypty instalacyjne npm są domyślnie wyłączone.

Na co uważać: Jeśli coś się dopasuje, agent ma wskazać, które tokeny wymienić (GitHub, npm, chmura) i w jakiej kolejności — ale wyłącznie nazwy, nigdy wartości. Rotuj od najbardziej wrażliwych.

4.Słabe certyfikaty eMudhry naprawisz jedną komendą — w każdym środowisku osobno

Na czym polega: Klucze firmy certyfikacyjnej eMudhra były tak słabe, że jednym z nich była liczba cztery. Przeglądarki je zablokowały, ale część narzędzi Pythona dalej ufała tym certyfikatom — teoretycznie można było podsunąć im fałszywe HTTPS. Znanych ataków nie było, ale aktualizacja jest obowiązkowa.

Jak stosować: Znajdź wszystkie instalacje Pythona i środowiska wirtualne. W każdym sprawdź pip i certifi, pamiętając że sama wymiana certyfikatów nie naprawia pipa — wgraj jedno i drugie: python -m pip install --upgrade pip certifi w każdym środowisku oraz uv self update, jeśli używasz uv. Na koniec przebuduj obrazy Dockera i pipeline’y CI oparte na tych środowiskach.

Na co uważać: Haseł w tym scenariuszu zmieniać nie trzeba. Pułapką jest mnożenie się środowisk — jedno przeoczone virtualenv zostaje z dziurawym łańcuchem zaufania.

5.Next.js i Node.js: aktualizacja plus ponowne wdrożenie

Na czym polega: Obie technologie łatały w październiku luki bezpieczeństwa. Dwa błędy w Next.js pozwalały obcej osobie przejąć aplikację; w Node.js nie zaobserwowano jeszcze ataków, ale ryzyko usuwa dopiero aktualizacja i wdrożenie.

Jak stosować: Jeśli masz aplikację lub stronę na Next.js albo Node — również hostowaną na Vercel — zaktualizuj framework i wdróż ponownie, dbając o wszystkie środowiska, nie tylko produkcyjne.

Na co uważać: Aktualizacja lokalna bez wdrożenia nic nie daje — dziura zostaje na serwerze.

6.Zaktualizuj dom swoich agentów i włącz 2FA

Na czym polega: Claude Code, Docker Desktop i Flatpak na Linuksie również załatały swoje luki. Autor opisuje to jako trzydziestosekundowy rytuał, zwykle załatwiany przez auto-aktualizację.

Jak stosować: Upewnij się, że auto-aktualizacje działają, w razie potrzeby zaktualizuj narzędzia ręcznie i skonfiguruj dwuskładnikowe logowanie na wszystkich platformach, na których pracujesz.

Na co uważać: Auto-aktualizacja „zwykle” wystarcza — nie zawsze. Co jakiś czas warto sprawdzić wersje ręcznie.

7.LiteLLM z 21 października? Potraktuj wszystkie sekrety jako skompromitowane

Na czym polega: Zatruta wersja LiteLLM wisiała w obiegu przez dwie godziny 21 października i kradła hasła oraz klucze natychmiast po uruchomieniu.

Jak stosować: Problem dotyczy wyłącznie instalacji z pip lub Dockera z okolic tej daty. Jeśli to twój przypadek, wymień wszystko, do czego ten proces miał dostęp, i przejrzyj, co narzędzie mogło odczytać.

Na co uważać: Krótki czas ekspozycji usypia czujność — dwie godziny w zupełności wystarczyły, żeby dane wyciekły.

8.Railway i Plex: wymień wszystko oraz schowaj serwer z otwartego internetu

Na czym polega: Railway po włamaniu był zamknięty na cały dzień, a ktoś mógł odczytać zapisane przez klientów hasła i klucze — platforma prosi wszystkich o wymianę. Stare wersje Plex Media Server są z kolei łamane na bieżąco.

Jak stosować: Na Railway zmień wszystkie klucze API, sekrety w zmiennych środowiskowych i hasła do baz — wszystko, co tam „mieszkało”. Plex zaktualizuj i przestań wystawiać wprost do sieci, kierując zdalny dostęp przez tunel.

Na co uważać: Rotacja tylko w panelu Railway nie wystarczy, jeśli te same klucze używasz gdzie indziej. Serwery medialne to z kolei najbardziej zapomniane maszyny w domu — a to właśnie ich stare wersje są celem.

9.Cztery nawady, w tym „najpierw raport, potem naprawa”

Na czym polega: Autor spina całość czterema regułami: włączone auto-aktualizacje, instalowanie wyłącznie tego, o co faktycznie prosiłeś, wymiana kluczy tylko po realnej ekspozycji oraz praca z agentem w trybie raport → decyzja → naprawa.

Jak stosować: Ustal z agentem twardą zasadę: niczego nie usuwa ani nie zmienia bez twojego potwierdzenia, a raport ma zawierać nazwy plików i wtyczek — bez wartości sekretów.

Na co uważać: Ślepe pozwolenie agentowi na „sprzątanie” może rozsypać działającą konfigurację; z drugiej strony wymiana kluczy bez powodu w ferworze bezpieczeństwa często kończy się zepsutymi integracjami.

10.PYA: darmowy audyt bezpieczeństwa prowadzony przez zespół agentów

Na czym polega: Autor udostępnia otwarty skill Protect Your Ass (github.com/AgriciDaniel/PYA, licencja MIT) — „antywirus” do Claude Code, działający też w Codexie i innych agentach. Po wpisaniu PYA zespół wyspecjalizowanych agentów przegląda kod: podatności (iniekcje, XSS, SSRF, path traversal, słabą kryptografię), uwierzytelnianie (m.in. IDOR, błędy JWT i OAuth), zależności, wycieki sekretów, infrastrukturę jako kod, logikę, a nawet agentów AI i MCP. Na końcu dostajesz ocenę 0–100 z listą poprawek w kolejności priorytetów.

Jak stosować: Zainstaluj skill poleceniem z repozytorium albo poproś agenta o instalację z linku, a potem audytuj projekt po projekcie — nie wszystko naraz. Możesz nim przeglądać także cudze repozytoria.

Na co uważać: Wynikom nie warto wierzyć ślepo: poważne znaleziska są weryfikowane podwójnie, ale po wdrożeniu poprawek uruchom pełny audyt ponownie, żeby potwierdzić skuteczność.

Redakcyjne tłumaczenie

Wstęp: prognoza łatek na Czarny październik

Witajcie w „Prognozie łatek”. Internet aż kipi od wydarzeń. Zaczęło się od PHP, potem przyszła kolej na Pythona i właściwie na wszystko inne. W niektórych krajach sieć bywa wyłączana w całości, banki odczuwają skutki, wyciekają dane osobowe, a włamań nie widać końca. Nazwaliśmy to Czarnym październikiem — a moim zadaniem jest pomóc wam wszystko załatać, żeby bezpieczeństwo stało na najwyższym poziomie. W obliczu tego, co dzieje się teraz na świecie, ochrona musi być naprawdę solidna.

Plan jest prosty i trójdzielny. Najpierw rzucimy okiem na prognozę, czyli listę rzeczy wymagających łatania na dzień dzisiejszy — mówimy o 23 października. Do każdego punktu dołączam prompt, który wasz agent może uruchomić, by przeszedć wasz setup. Potem zaprezentuję skill zabezpieczający wasze platformy, strony i biznesy przed wyciekami. Sam już wszystko przejrzałem — i wy również powinniście. Zwłaszcza jeśli trzymacie na tych platformach dane klientów i bazy danych: wtedy stawka jest realna.

Schemat jest banalny: patrzycie na prognozę, kopiujecie prompt i wklejacie go do agenta — Claude Code, Cowork czy dowolnego innego. Agent widzi wasz komputer, sprawdza i składa pełny raport. Chodzi o jedno: mieć pewność, że jesteśmy bezpieczni.

UpdraftPlus: skradzione klucze do stron WordPressa

Pierwszy punkt dotyczy wszystkich użytkowników WordPressa — i jest poważny. UpdraftPlus, popularna wtyczka do kopii zapasowych, została zhakowana 18 października. Atakujący weszli w posiadanie kluczy kontrolujących strony klientów i przy ich użyciu podkładali fałszywe dodatki. I najważniejsze: sama aktualizacja tego nie naprawia. Jeśli gdziekolwiek używacie UpdraftPlus — w wersji darmowej albo płatnej — jesteście w strefie uderzenia.

Prompt do wklejenia agentowi:

Sprawdź moją stronę WordPress po włamaniu do UpdraftPlus z 18 października. Atakujący wykradli klucze UpdraftCentral i instalowali przez nie wtyczki z backdoorem; aktualizacja wtyczki nie unieważnia skradzionych kluczy. Dla każdej strony:

  1. Sprawdź wersję UpdraftPlus — bezpieczna to 1.26.12 / 2.26.12 albo nowsza.
  2. Wylistuj klucze w Ustawienia → Kopie zapasowe UpdraftPlus → Narzędzia zaawansowane.
  3. Wylistuj wszystkie wtyczki, łącznie z mu-plugins, zwłaszcza te instalowane niedawno. Oflaguj wszystko, czego nie dodawałem — na przykład dodatki udające narzędzia diagnostyczne w stylu „site health check” czy „site health cache”.
  4. Wylistuj administratorów i oflaguj konta założone po 18 października 2026.
  5. Sprawdź w bazie danych opcję _sync_token.
  6. Jeśli znajdziesz podejrzaną wtyczkę, nie naprawiaj jej ani nie aktywuj: najpierw usuń klucze, dopiero potem samą wtyczkę.
  7. Jeśli nie masz dostępu do strony, przeprowadź mnie przez kolejne kliknięcia.

Zasady: najpierw raport i żadnych zmian bez mojej zgody. Nigdy nie pokazuj haseł ani kluczy w całości.

(Informacja dodatkowa: mu-plugins, czyli „must-use plugins”, to wtyczki WordPressa ładowane automatycznie, z pominięciem standardowej listy w panelu — właśnie dlatego łatwo je przeoczyć.)

PHP: dziura w silniku, na którym stoi większość stron

Kolej na serwery — i to burza trwająca dokładnie w tej chwili. Dwie luki w PHP, języku, na którym opiera się WordPress, pozwalały obcej osobie przejąć serwer bez logowania. Poprawki wypuszczono 21 października, ale atakujący zdążyli już testować dziury. Większość firm hostingowych załatała wszystko za was — dla pewności upewnijcie się jednak, że stoicie na najnowszej wersji. A jeśli łataliście cokolwiek ręcznie, przejrzyjcie jeszcze raz wtyczki i inne potencjalne wejścia dla intruza.

Prompt:

Sprawdź, czy moje strony są bezpieczne po lukach w PHP załatanych 21 października 2026. Bezpieczne wersje to PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35 lub nowsze w tej samej linii. PHP 8.1 i starsze nie dostaną oficjalnej poprawki — jeśli takie występują, wyraźnie to zaznacz.

Ustal, gdzie hostowane są moje strony (hosting zarządzany typu Hetzner, cPanel i podobne) i pomóż potwierdzić, że dostawca załatał lukę — większość już to zrobiła.

Na moim serwerze sprawdź php -v oraz wersję, na której faktycznie działa strona (pule PHP-FPM albo phpinfo).

Jeśli potrzebna aktualizacja, wypisz dokładne kroki, łącznie z restartem wszystkich workerów PHP-FPM.

Jeśli strona stoi za Cloudflare, potwierdź, że proxy (pomarańczowa chmurka) jest włączone.

Zasady: najpierw raport, żadnych zmian bez mojej zgody.

Ten prompt równie dobrze można po prostu sfotografować i pokazać agentowi. Jeśli faktycznie jesteś pod ostrzałem — bądź czujny.

Zatrute pakiety: ataki na łańcuch dostaw w projektach kodu

Teraz coś, co powinno zaboleć każdego programistę. Część dodatków do kodu podmieniono na wersje kradnące hasła. Osobny atak umieścił fałszywe „pomoce bezpieczeństwa” w tysiącach projektów na GitHubie. Tak — GitHub też jest na celowniku. Wniosek na przyszłość: przy każdej instalacji repozytoriów sprawdzaj, czy nie niosą ukrytego złośliwego kodu, i zachowuj zdrowy sceptycyzm wobec skilli, narzędzi i aplikacji instalowanych u siebie — także tych przeznaczonych dla agentów.

Prompt:

Sprawdź moje projekty na GitHubie pod kątem ataków na łańcuch dostaw z września i października 2026. Przeszukaj logi i pliki blokad zależności: package-lock.json, pnpm-lock.yaml, yarn.lock — pod kątem wskaźnika tensorlake.

W każdym repozytorium wylistuj pliki w GitHub Workflows i oflaguj te, których nie dodawałem — zwłaszcza security-audit.yml i wszystko, co wysyła dane na nieznany adres.

Sprawdź, czy skrypty instalacyjne npm są domyślnie wyłączone na tej maszynie.

Jeśli coś się dopasuje, wskaż, które tokeny mam zmienić — GitHub, npm, chmura — i w jakiej kolejności. Tylko nazwy, nigdy wartości.

Zasady: najpierw raport, żadnych zmian bez mojej zgody.

(Informacja dodatkowa: atak na łańcuch dostaw polega na przejęciu zaufanego ogniwa — pakietu, wtyczki czy zależności — tak, żeby złośliwy kod dotarł do ofiary razem z czymś, co instalowała dobrowolnie.)

Python i eMudhra: urząd certyfikacyjny z zamka z bibułki

Python. Wielki ekosystem, ogromna społeczność, lata doświadczenia — a jednak i on dał plamę. Zdaje się, że świat naprawdę przyspiesza. eMudhra to firma, która poświadcza stronom internetowym, że są tym, za kogo się podają. Jej klucze okazały się tak słabe, że jednym z nich była po prostu liczba cztery. Przeglądarki zablokowały je już dawno; pozostałe narzędzia Pythona — nie. Na szczęście nie odnotowano ani jednego ataku. Ale aktualizacja jest konieczna.

Prompt:

Znajdź wszystkie instalacje Pythona i środowiska wirtualne na tym komputerze oraz w moich projektach. Dla każdej sprawdź pip i certifi. Pamiętaj, że sama aktualizacja certyfikatów nie naprawia pipa.

Pokaż tabelę z podziałem na „bezpieczne” i „wymagające aktualizacji”.

Zaproponuj naprawę: python -m pip install --upgrade pip certifi w każdym środowisku oraz uv self update.

Wskaż, które obrazy Dockera i pipeline’y CI trzeba potem przebudować.

W tym scenariuszu hasła pozostają bez zmian.

Zasady: najpierw raport, żadnych zmian bez mojej zgody. Działamy razem.

Next.js i Node.js również po poprawkach

Ten obszar nie ucierpiał najmocniej, ale zaktualizować trzeba. Obie technologie otrzymały w październiku łatki bezpieczeństwa. Dwie luki w Next.js pozwalały obcej osobie przejąć waszą aplikację. W Node.js nie widać jeszcze śladów atakujących — aktualizacja i ponowne wdrożenie załatwiają temat. Jeśli zbudowaliście aplikację lub stronę na Next.js albo Node, także na Vercel, przechodźcie na najnowszą wersję. Poniżej prompt do sprawdzenia.

Zaktualizuj dom, w którym mieszkają wasi agenci

Claude Code, Docker Desktop i Flatpak na Linuksie załatały własne luki bezpieczeństwa. Auto-aktualizacja zwykle wystarcza — to dosłownie trzydzieści sekund sprawdzenia. Na moim Linuksie wszystko jest już zaktualizowane. I proszę, włączcie wszędzie 2FA.

LiteLLM: narzędzie AI ze złodziejem w środku

LiteLLM łączy aplikacje z modelami AI. 21 października przez dwie godzienie dostępna była zatruta wersja, która zaraz po uruchomieniu kradła hasła i klucze. Dotyczy was wyłącznie wtedy, gdy wy albo wasz agent instalowaliście LiteLLM w okolicach 21 października przez pip lub Dockera — wtedy sprawdźcie, czy wasze dane nie wyciekły. Poniżej prompt do takiej weryfikacji.

Dwie lokalne burze: Railway i Plex

Railway przeszedł atak i był zamknięty na cały dzień. Szczerze? Część moich projektów stała właśnie tam — wymieniłem już wszystkie klucze. Jeśli cokolwiek trzymacie na Railway, zmieńcie wszystkie klucze API: cała platforma była pod ostrzałem. Istnieje ryzyko, że ktoś odczytał zapisane przez klientów hasła i sekrety, dlatego Railway prosi każdego użytkownika o ich wymianę. Oczyszczajcie wszystko: zmienne ENV, sekrety, cokolwiek trzymaliście w środku.

Druga historia to Plex Media Server. Media domowe, ataki trwają: stare wersje są łamane w tej chwili, gdy to nagrywam. Zaktualizujcie serwer i trzymajcie go z dala od otwartego internetu. Prompt do Railway sprowadza się do trzech poleceń: przejrzyj całą konfigurację platformy, zaktualizuj ją i wymień wszystkie klucze, sekrety oraz dostępne w środku bazy danych. Analogiczny prompt czeka na użytkowników Plexa.

Napięty miesiąc, ale nie lawina

To był gorący miesiąc — jednak nie reakcja łańcuchowa. Najpierw PHP, potem Node, potem GitHub, teraz Python: osobne zdarzenia o osobnych przyczynach, które złożyły się przypadkiem w jednym tygodniu. W skrócie, gazetowo: Python przeżywa duży alarm bezpieczeństwa — urząd certyfikacyjny popełnił błąd, szybka aktualizacja usuwa problem, a ataków dotąd nie było. Linux zmaga się z dwiema lukami krytycznymi, ale dotknięty moduł jest domyślnie wyłączony na większości maszyn. Na każdy z tych scenariuszy wystarczy jeden wspólny prompt — i jak zwykle można go pokazać agentowi na zrzucie ekranu. A jeśli kopiowanie pojedynczych poleceń was męczy, na końcu czeka zbiorczy przegląd całego systemu: zróbcie zrzut ekranu tego fragmentu i poproście agenta o pełne sprawdzenie bezpieczeństwa.

Cztery nawady, po których niebo się przejaśni

  1. Trzymajcie auto-aktualizacje włączone — przynajmniej na razie.
  2. Instalujcie tylko to, o co naprawdę prosiliście.
  3. Wymieniajcie klucze tylko wtedy, gdy były narażone — tak jak w przypadku Railway.
  4. Z agentem najpierw raport, potem naprawa. Niczego nie usuwajcie w ciemno.

Protect Your Ass: antywirus dla Claude Code

Właśnie z tych powodów powstał Protect Your Ass — repozytorium PYA pod adresem github.com/AgriciDaniel/PYA. To skill-antywirus dla Claude Code; zadziała też w Codexie i innych agentach. Darmowe, otwarte audyty bezpieczeństwa wewnątrz Claude Code: znajdź to, co ci zaszkodzi, zanim zrobi to napastnik.

Wpisz „PYA” w dowolnym projekcie i dziewięciu wyspecjalizowanych agentów przejrzy jednocześnie twój kod. Prowadzicie wiele projektów? Nie rzucajcie się na wszystkie naraz — przechodźcie kolejno, projekt po projekcie, żeby mieć pewność, że nic nie cieknie i bezpieczeństwo jest dopięte na ostatni guzik. Poważne znaleziska są po raz drugi weryfikowane przez osobnego agenta, a na koniec dostajecie ocenę od 0 do 100 wraz z listą poprawek we właściwej kolejności. I nie bierzcie wyniku na wiarę: potwierdźcie go, a po wdrożeniu zmian uruchomcie pełny audyt raz jeszcze.

Narzędzie sprawdza to, co staranna ręczna rewizja bezpieczeństwa: podatności w kodzie, logowanie i dostęp, wycieknięte sekrety, ataki na łańcuch dostaw oraz agentów AI i MCP. Można nim audytować także cudze repozytoria na GitHubie.

(Informacja dodatkowa: MCP, czyli Model Context Protocol, to standard łączenia agentów AI z zewnętrznymi narzędziami i źródłami danych.)

Poznajcie zespół, który ogarnia całość:

  • Skaner podatności — iniekcje, XSS, SSRF, path traversal (wyjście poza dozwolony katalog w ścieżkach plików), niebezpieczna deserializacja, słaba kryptografia i słaba losowość.
  • Recenzent uwierzytelniania — pominięte sprawdzenia uprawnień, IDOR (dostęp do cudzych zasobów przez podmianę identyfikatora), eskalacja uprawnień, błędy sesji, JWT i OAuth.
  • Analityk zagrożeń.
  • Audytor zależności.
  • Skaner sekretów.
  • Skaner infrastruktury jako kodu (IaC).
  • Recenzent logiki.
  • Audytor agentów.
  • Audytor kodu AI.
  • Weryfikator znalezisk.

Jeśli coś umknęło naszej uwadze, a macie w temacie cyberbezpieczeństwa wiedzę i doświadczenie — dołączajcie. Repozytorium może stać się wasze: rozwijajcie je, ulepszajcie i dzielcie się ze światem. Chodzi dokładnie o jedno — żeby wszyscy mieli zabezpieczone plecy.

Sam audyt jest prosty, a instalacja jeszcze prostsza. Skill poznaje twój kod, zespół odnajduje słabe punkty, odsiewa szum i podaje ocenę oraz listę tego, nad czym trzeba popracować. Instalacja sprowadza się do jednej komendy z repozytorium — albo, jak zwykle, można wrzucić link agentowi, poprosić o instalację, a potem o pełny przegląd stron i projektów. Licencja MIT — narzędzie jest wasze. Projekt nosił wcześniej nazwę Claude Cybersecurity; dziś to Protect Your Ass.

Zamiast pożegnania

Mam nadzieję, że pomogłem. Czarny październik to szaleństwo, ale nie ma co panikować — jeśli wszystko porządnie załatacie i będziecie chronieni, będzie dobrze. Jeśli wyjdzie coś nowego, stosujcie sprawdzone praktyki: trzymajcie dane lokalnie lub w bezpiecznym miejscu, dbajcie o klucze — zwłaszcza do mediów społecznościowych — i o całą resztę. Trzymajcie się. Cześć!