Aktualizacja wtyczki w oficjalnym repozytorium WordPressa nie musi już od razu trafić do użytkowników. Każde nowe wydanie jest analizowane pod kątem bezpieczeństwa, a jeśli wynik wskazuje wysokie ryzyko, WordPress.org automatycznie zatrzymuje jego dystrybucję.

Co właściwie się zmieniło?

Do tej pory WordPress.org rozwijał automatyczne skanowanie aktualizacji, ale wynik nadal wymagał reakcji zespołu. Teraz pojawiła się brakująca część: wydanie z wysokim wynikiem ryzyka jest blokowane automatycznie, zanim zacznie być rozsyłane przez API aktualizacji WordPressa.

To ważne rozróżnienie. Repozytorium nie tylko mówi autorowi: „w kodzie może być problem”. W określonych przypadkach mówi także: „ta wersja na razie nie pojedzie dalej”. Autorzy dostają e-mail z wykrytymi problemami i mogą przygotować poprawione wydanie albo zgłosić fałszywy alarm.

WebsiteGarage / Usługi

Sprawdź nasze usługi.

Sześć godzin na sprawdzenie, zanim aktualizacja trafi na strony

Od 5 czerwca 2026 nowe wydania wtyczek i motywów przechodzą w WordPress.org okres oczekiwania przed dystrybucją. Obecnie trwa on sześć godzin. W tym czasie zmiany w kodzie są analizowane przez kilka modeli AI oraz Jetpack Scan, a wyniki są porównywane i łączone w ocenę ryzyka.

Jeżeli wynik pozostaje poniżej progu blokady, wydanie przechodzi dalej normalną drogą. Jeżeli próg zostanie przekroczony, dystrybucja zostaje wstrzymana. WordPress podkreśla przy tym, że wysoki wynik nie oznacza automatycznie złośliwego działania autora. Taki sam alarm może wywołać zwykły, ale poważny błąd bezpieczeństwa.

To już zatrzymało prawdziwy backdoor

WordPress podał konkretny przykład z 28 lipca. Do wydania wtyczki używanej na około 20 tysiącach stron trafił backdoor, czyli celowo pozostawiony sposób nieautoryzowanego dostępu. Automatyczny skan oznaczył wydanie jako wysokiego ryzyka, a ponieważ wersja nadal była w okresie oczekiwania, nie została rozprowadzona przez WordPress.org.

Według Plugins Team sama wtyczka została zamknięta do pobierania 26 minut po zgłoszeniu aktualizacji przez Wordfence. Ten przypadek był jednym z powodów, dla których zespół zdecydował, że wysoki wynik skanu powinien sam zatrzymywać dystrybucję, zamiast czekać na człowieka.

AI nie dostało przycisku „ban”. Jest częścią kilkuwarstwowej kontroli

Łatwo byłoby opisać tę zmianę jako „AI decyduje, które wtyczki są bezpieczne”, ale to byłoby za proste. WordPress używa kilku modeli razem z klasycznym skanerem bezpieczeństwa, wyniki są wzajemnie sprawdzane, a mechanizm nadal dopuszcza fałszywe alarmy i ręczne odwołanie autora.

Najciekawsze jest coś innego: AI przestaje być tylko narzędziem pomagającym reviewerowi czy badaczowi. Zaczyna być elementem infrastruktury dystrybucji oprogramowania. Kod jest oceniany zanim aktualizacja pojawi się w panelach administratorów stron.

Czy to znaczy, że aktualizacje z WordPress.org są teraz „sprawdzone i bezpieczne”?

Automatyczna kontrola zmniejsza szansę, że ewidentnie niebezpieczne wydanie przejdzie niezauważone, ale nie jest certyfikatem bezpieczeństwa. Skan może czegoś nie wykryć, a problem może ujawnić się dopiero w określonej konfiguracji albo po połączeniu z inną wtyczką.

Dla właściciela strony praktyczny wniosek jest pozytywny, ale nudny w najlepszym znaczeniu tego słowa: oficjalne repozytorium dostało dodatkową barierę między kodem autora a przyciskiem „Aktualizuj” w twoim WordPressie. Kopia zapasowa i rozsądne testowanie aktualizacji nadal nie przestały być potrzebne.

Komentarz WebsiteGarage

To jest jeden z tych przypadków, w których AI ma sens właśnie dlatego, że nie próbuje udawać wszechwiedzącego administratora. Dostaje bardzo konkretną robotę: przejrzeć ogromną liczbę zmian, porównać wyniki kilku narzędzi i zatrzymać rzeczy, które wyglądają naprawdę źle, zanim polecą dalej.

I to jest dużo ciekawsze niż kolejny przycisk „napisz mi wpis blogowy”. Jeśli automatyzacja ma poprawiać bezpieczeństwo WordPressa, to takie miejsca są idealne: powtarzalne, masowe i czasochłonne kontrole, przy których człowiek nadal może wejść wtedy, gdy sytuacja nie jest oczywista.