W 90 dni program bezpieczeństwa WordPressa dostał 2004 zgłoszenia podatności i wypłacił za nie ponad 90 tys. dolarów. To prawie połowa wszystkiego, co wypłacił od 2017 roku. Do tej pory płacił za to jeden podmiot, Automattic. W poniedziałek 5 października 2026 Mary Hubbard, dyrektor wykonawcza WordPressa, napisała do szefów ponad 30 firm z prośbą, żeby się dołożyły.
Opisuję to na podstawie artykułu The Repository z 8 października 2026, który cytuje maila Hubbard (The Repository, 8 października 2026), oraz ogłoszeń na wordpress.org. Samego maila nie widziałem. Liczby i cytaty sprawdziłem u źródeł 9 października 2026.
O co Mary Hubbard prosi firmy hostingowe i wtyczkowe
Mail poszedł do prezesów firm hostingowych, wtyczkowych i zajmujących się bezpieczeństwem wieczorem czasu UTC. The Repository pisze o “Monday evening UTC” w tekście z czwartku 8 października. Główna teza: AI potaniło szukanie dziur.
“AI sprowadziła do minimum koszt znajdowania, zgłaszania i wykorzystywania podatności”
Mary Hubbard, cytowana przez The Repository, 8 października 2026, tłumaczenie własne
Według niej program dostał w 90 dni prawie 2000 zgłoszeń, więcej niż kiedykolwiek, “a tempo wciąż rośnie” (tłumaczenie własne). The Repository sprawdziło stronę programu na HackerOne: 2004 zgłoszenia i ponad 90 tys. dolarów nagród w 90 dni, przy nieco ponad 200 tys. dolarów wypłaconych od startu w kwietniu 2017.
“Prawie połowa wszystkich wypłat w historii programu przypadła na jeden kwartał, a krzywa idzie tylko w jedną stronę.”
Mary Hubbard, cytowana przez The Repository, 8 października 2026, tłumaczenie własne
Hubbard pisze też, że Automattic finansował program w 100%: każdą nagrodę, triaż, weryfikację, poprawki i skoordynowane wydania bezpieczeństwa dla wszystkich wspieranych gałęzi aż do WordPress 4.7. Prosi o jedną z trzech rzeczy: wpłatę do wspólnej puli nagród, sponsorowanie ludzi do triażu i wydań albo inną formę, ustaloną wspólnie. Zaznacza, że część wzrostu to prawdziwe badania, które dzięki nowym narzędziom idą szybciej i realnie poprawiają bezpieczeństwo. Problemem jest według niej ekonomia, nie sam program: “zepsuta jest ekonomia, nie program” (tłumaczenie własne).
Które firmy poproszono o finansowanie bezpieczeństwa WordPressa
Na czele listy adresatów byli GoDaddy, Newfold Digital i Hostinger. The Repository wymienia dalej:
| Grupa | Firmy |
|---|---|
| Hostingi i rejestratorzy | SiteGround, IONOS, DigitalOcean, DreamHost, World Host Group, Kinsta, OVHcloud, group.one, Namecheap, Tucows, Pantheon, Porkbun |
| Wtyczki i produkty | Elementor, Awesome Motive, Incsub (WPMU DEV), Rocketgenius (Gravity Forms), Rank Math, Brainstorm Force, Extendify |
| Agencje enterprise | Human Made, rtCamp |
| Bezpieczeństwo | Wordfence, Patchstack, BlogVault |
Źródło: The Repository, 8 października 2026.
Maila nie dostał WP Engine, który od 2024 roku jest w sporze sądowym z Automattic, chociaż przedstawicieli WP Engine wymieniono w podziękowaniach do wydań bezpieczeństwa 7.0.2 i 7.1.1. Na liście nie było też Nexcess.
Jak odpowiedziały firmy hostingowe i twórcy wtyczek
Ci, którzy odpowiedzieli The Repository, są na tak, ale chcą wiedzieć, na co dokładnie się piszą.
- Hostinger (Marco Chiesi): rozważa oddelegowanie własnych ludzi. Od lipca współpracuje z zespołem bezpieczeństwa i wdraża reguły WAF przed publikacją poprawek.
- Kinsta (Jon Penland): chce programu “clearly defined”, czyli jasno określonego, do którego firmy mogłyby się dołożyć.
- Awesome Motive (Syed Balkhi): sponsoruje już kilku współpracowników zespołów bezpieczeństwa i wtyczek, ale zauważa, że prośba jest “quite open-ended”.
- Human Made (Tom Willmot): sponsoruje Johna Blackbourna, który na pełny etat reprezentuje zespół bezpieczeństwa. Agencja próbowała wcześniej zebrać firmy wokół funduszu bezpieczeństwa, “niestety bez większego odzewu” (tłumaczenie własne).
- Patchstack (Oliver Sild): firma wypłaciła z własnej kieszeni 600 tys. dolarów nagród od 2022 roku, ale nigdy nie została dopuszczona do zespołów bezpieczeństwa i wtyczek WordPressa. Jego zdaniem “ten proces trzeba zreformować” (tłumaczenie własne).
GoDaddy, Newfold Digital i Wordfence nie odpowiedziały do czasu publikacji tekstu.
WordPress 7.1.4: 22 podatności i co z tego wynika dla twojej strony
Aktualizacja, . WordPress 7.1.4 wyszedł 28 października. Według strony wersji poprawia 22 podatności. Najpoważniejsza to wyścig w procesie aktualizacji rdzenia, który według zgłaszającego (Umut Bayram) mógł prowadzić do zdalnego wykonania kodu. Większość pozostałych to stored XSS wymagające konta co najmniej współpracownika. Dwa zgłoszenia przypisano firmie Anthropic. Poprawki trafiły też do starszych gałęzi, od 7.0.8 aż po 4.7.39. Strony z automatycznymi aktualizacjami w tle dostają łatkę same.
To siódme wydanie bezpieczeństwa rdzenia od lipca. W podsumowaniu dwóch miesięcy Core Security Initiative Rudy Faile podaje, że w tym roku zespół dostał ponad 3000 zgłoszeń, więcej niż przez poprzednie dwanaście lat razem, a 73% ze 109 kroków wydania bezpieczeństwa jest już zautomatyzowanych. Przy takim tempie odkładanie aktualizacji na weekend przestaje być bezpieczne. W aktualizacjach WordPressa wydania bezpieczeństwa najpierw sprawdzam na stagingu, a potem wdrażam na produkcję.
Co poprawia WordPress 7.1.3 i kto zgłosił błędy
Dzień po mailu, 6 października 2026, wyszedł WordPress 7.1.3 z 7 poprawkami bezpieczeństwa i 4 innymi poprawkami błędów. W ogłoszeniu przy każdej poprawce podano, kto ją zgłosił:
| Podatność | Kto może jej użyć | Zgłaszający |
|---|---|---|
| Stored XSS na stronie Komentarze w panelu, przez oczekujące komentarze | Ktokolwiek, kto zostawi komentarz, jeśli moderator (Redaktor lub wyżej) kliknie link w nim | Trail of Bits we współpracy z OpenAI |
Odmowa usługi w WP_Http::make_absolute_url() | Konto Współpracownika lub wyżej | Anthropic |
| SQL injection drugiego rzędu w eksporcie WXR | Administrator robiący eksport, przy złej wartości _thumbnail_id już w bazie | Anthropic |
| Autor mógł przypinać wpisy (sticky) | Konto Autora lub wyżej | Anthropic |
| Ujawnienie komentarzy do wpisów prywatnych i nieopublikowanych | Każdy, bez logowania | Ananda Dhakal, Patchstack |
| XSS w osadzeniach Imgur | Konto Współpracownika lub wyżej i ofiara, która obejrzy wpis | Zhengyu Liu, Jingcheng Yang, Gavin Zhong |
Podrabialne parametry hooka {status}_{type} | Wtyczka przekazująca surowy status albo typ wpisu do wp_insert_post() | Alex Concha, zespół bezpieczeństwa WordPressa |
Źródła: zgłaszający według WordPress.org, 6 października 2026, warunki wykorzystania według Patchstack, 6 października 2026.
Tylko jedna z siedmiu dziur działa bez żadnego konta i bez udziału ofiary: wyciek komentarzy z prywatnych wpisów. Patchstack wyjaśnia mechanizm: w kanale komentarzy do pojedynczego wpisu WordPress najpierw pobierał komentarze, a dopiero potem sprawdzał, czy odwiedzający może zobaczyć wpis. Sprawdzenie ukrywało wpis, ale nie komentarze, a kanały nie zwracają 404, więc komentarze trafiały do kanału. Trzy z pozostałych sześciu wymagają konta Współpracownika albo Autora.
Cztery z siedmiu zgłoszeń pochodzą od firm budujących modele AI albo od ich partnerów. To dobrze ilustruje tezę Hubbard: dziury znajduje dziś także AI, a za każdą z nich ktoś musi zapłacić triażem, poprawką i wydaniem dla każdej wspieranej gałęzi. W ogłoszeniu czytamy, że poprawki są przenoszone do wszystkich gałęzi objętych łatkami bezpieczeństwa, obecnie aż do 4.7, i będą wydawane w miarę gotowości.
Poprawki bezpieczeństwa w WordPress 7.1.1 i 7.1.2
Według Patchstack dwa tygodnie przed 7.1.3 wyszło wydanie 7.1.2, które naprawiło jedną podatność (CVE-2026-87902). Pozwalała ona odwiedzającemu bez logowania wywołać dołączenie lokalnego pliku, a przy odpowiedniej konfiguracji PHP prowadziła do zdalnego wykonania kodu (Patchstack, 6 października 2026).
Wcześniej, we wrześniu, Patchstack opisał też podatność zdalnego wykonania kodu załataną w 7.1.1. Jeśli Twoja strona stoi na 7.1.0, brakuje jej poprawek z trzech kolejnych wydań.
Czym jest Core Security Initiative w WordPressie
28 sierpnia 2026 zespół bezpieczeństwa ogłosił na make.wordpress.org Core Security Initiative (Make WordPress Security, 28 sierpnia 2026). Ogłoszenie wiąże “substantial increase” w liczbie zgłoszeń z szybkim rozwojem modeli frontier AI. Opisuje to jako dobry problem, który jednak wymaga skalowania triażu, weryfikacji i naprawiania.
Inicjatywa dotyczy rdzenia WordPressa. Nie obejmuje wtyczek ani motywów. Zgłoszenia przyjmuje program na HackerOne, a podatności WordPress.com i aplikacji mobilnych idą osobno, przez program Automattic.
Jak Patchstack i Wordfence filtrują zgłoszenia podatności we wtyczkach generowane przez AI
Liczby z HackerOne dotyczą tylko rdzenia. Luki we wtyczkach i motywach trafiają do innych programów i tam widać tę samą krzywą. W marcu 2026 program Wordfence Bug Bounty dostał 1718 zgłoszeń podatności, o 59,4% więcej niż w lutym, od 321 aktywnych badaczy, i wypłacił w tym miesiącu 62 174 USD nagród (Wordfence, raport za marzec 2026). Raport nie podaje, ile z tych zgłoszeń powstało z pomocą AI.
Patchstack nazywa przyczynę wprost. 29 maja 2026 Dave Jong, szef badań bezpieczeństwa w tej firmie, napisał, że odkąd upowszechniły się badania wspierane przez AI, zwłaszcza w 2026 roku, program dostaje więcej zgłoszeń o niskim wpływie, które ledwie spełniają kryteria, więcej duplikatów (jedna podatność dostała ponad 20 zdublowanych zgłoszeń od różnych badaczy) i raporty oparte na błędnych założeniach wygenerowanych przez AI (Patchstack, 29 maja 2026). Od 1 czerwca 2026 Patchstack:
- wyłączył z zakresu rolę Współpracownika (Contributor), więc luka musi być osiągalna dla gościa, Subskrybenta, Klienta albo podobnej niskiej roli,
- przypisał warunki do każdej klasy podatności, na przykład XSS musi mieć wpływ na całą stronę albo być odbity (reflected),
- ograniczył miesięczną pulę nagród do 5 najlepszych badaczy,
- banuje na tydzień każdego, kto przyśle błędne założenia wygenerowane przez AI albo raport nieprzetestowany na faktycznej wtyczce lub motywie.
Zasady opublikowane na stronie programu (stan na 13 października 2026) wymagają też tekstowego proof of concept krok po kroku, z surowymi żądaniami HTTP i dokładnymi payloadami, oraz komponentu z co najmniej 1000 aktywnych instalacji (zasady bug bounty Patchstack).
Dla autora wtyczki ten filtr znaczy więcej niż budżet rdzenia. Zgłoszenie, które przejdzie triaż platformy, i tak ląduje u autora, który musi je odtworzyć i wydać poprawkę, zwykle bez żadnych pieniędzy z nagród dla siebie.
Kto obsługuje podatności wtyczek i numery CVE na WordPress.org
Katalog wtyczek ma własną ścieżkę. Plugin Handbook prosi zgłaszających, żeby najpierw skontaktowali się z autorem, a dopiero gdy to zawiedzie, napisali na [email protected], bez publicznego ogłaszania problemu. Zespół wtyczek działa wtedy na samym wpisie w katalogu: większość wtyczek jest zamykana dla nowych pobrań do czasu usunięcia problemu. Ta sama strona mówi, że zespół nie pomaga w zgłaszaniu CVE z powodu braku zasobów (Plugin Handbook, Reporting plugin security issues, ostatnia zmiana 2 stycznia 2026).
Numery CVE dla wtyczek WordPressa nadają więc głównie firmy bezpieczeństwa zarejestrowane jako CVE Numbering Authorities. Lista partnerów programu CVE przypisuje Wordfence zakres podatności we wtyczkach, motywach i rdzeniu odkrytych przez jego zespół lub do niego zgłoszonych, WPScan rdzeń, wtyczki i motywy WordPressa, a Patchstack podatności znalezione przez jego zespół i uczestników jego bug bounty (CVE Program, lista partnerów).
Te firmy płacą za triaż wtyczek z własnych przychodów i sprzedają na tym ochronę. Wordfence pisze, że użytkownicy Premium, Care i Response dostają reguły firewalla w czasie rzeczywistym, a użytkownicy darmowej wersji po 30 dniach. To druga odpowiedź na pytanie, kto płaci: we wtyczkach koszt triażu już leży po stronie dostawców bezpieczeństwa, a dwóch z nich, Wordfence i Patchstack, jest na liście Hubbard.
Czego unijny Cyber Resilience Act wymaga od producentów wtyczek WordPress
Od 11 września 2026 część tego kosztu jest w UE także obowiązkiem prawnym. Akt o cyberodporności, rozporządzenie (UE) 2024/2847, stosuje się w całości od 11 grudnia 2027, ale art. 71 ust. 2 przesunął jego art. 14 o zgłaszaniu na 11 września 2026 (rozporządzenie (UE) 2024/2847, EUR-Lex). Producent, który dowie się o aktywnie wykorzystywanej podatności w swoim produkcie, musi powiadomić wyznaczony CSIRT i ENISA przez jedną platformę zgłoszeń:
| Krok | Termin według art. 14 ust. 2 |
|---|---|
| Wczesne ostrzeżenie | 24 godziny od powzięcia wiedzy |
| Zgłoszenie podatności | 72 godziny od powzięcia wiedzy |
| Raport końcowy | 14 dni od udostępnienia poprawki lub środka zaradczego |
Art. 3 pkt 13 definiuje producenta jako podmiot, który rozwija produkt i wprowadza go pod własną nazwą lub znakiem towarowym, odpłatnie, w celu monetyzacji albo nieodpłatnie. Firma sprzedająca wtyczkę premium pod swoją marką mieści się wprost w tym brzmieniu. Art. 13 ust. 6 dodaje, że producent, który znajdzie podatność we wbudowanym komponencie, także open source, musi zgłosić ją temu, kto ten komponent utrzymuje, i udostępnić poprawkę. Naruszenie art. 13 i 14 grozi karą do 15 mln EUR albo 2,5% całkowitego rocznego światowego obrotu, zależnie od tego, która kwota jest wyższa (art. 64 ust. 2). Mikro i małe przedsiębiorstwa są zwolnione z kar tylko za przekroczenie 24-godzinnego terminu wczesnego ostrzeżenia (art. 64 ust. 10).
Opiekunowie oprogramowania open source (open-source software stewards), czyli osoby prawne, które systematycznie wspierają wolne oprogramowanie przeznaczone do działalności komercyjnej, mają lżejszy reżim: udokumentowaną politykę cyberbezpieczeństwa (art. 24) i brak jakichkolwiek kar administracyjnych (art. 64 ust. 10 lit. b). Rozporządzenie nie mówi, kto płaci za triaż takiego opiekuna, a to jest to samo pytanie, które mail Hubbard stawia firmom z jej listy.
Co właściciel strony na WordPressie powinien zrobić po 7.1.3
Mail Hubbard nie zmienia niczego na Twojej stronie z dnia na dzień. Liczby z HackerOne i lista z 7.1.3 przekładają się jednak na kilka konkretnych rzeczy:
- Zainstaluj 7.1.3, jeśli jeszcze tego nie zrobiłeś. Ogłoszenie zaleca aktualizację natychmiast. Sprawdź w Kokpit, Aktualizacje, czy strona faktycznie ma 7.1.3, nawet jeśli masz włączone automatyczne aktualizacje.
- Starsza gałąź dostaje łatki później. Według Patchstack w dniu wydania poprawki trafiły do gałęzi od 6.6 wzwyż, a gałęzie od 4.7 do 6.5 jeszcze na nie czekały. Strona na 7.1 była chroniona od pierwszego dnia.
- Wyczyść cache po aktualizacji. Patchstack ostrzega, że 7.1.3 nie usuwa zapisanych w bazie osadzeń oEmbed, więc złośliwe osadzenie Imgur dodane wcześniej nadal się wyświetla, dopóki nie wyczyścisz cache.
- Przejrzyj role użytkowników. Patchstack zaleca to wprost, bo trzy z siedmiu dziur wymagają konta Współpracownika albo Autora. Konta byłych autorów i agencji, które dawno skończyły pracę, warto usunąć albo obniżyć im uprawnienia.
- Rdzeń to nie wszystko. Core Security Initiative nie obejmuje wtyczek. Jeśli od dawna nie przeglądałeś swoich wtyczek, zacznij od audytu nieaktualnych wtyczek i znanych CVE.
- Wydań bezpieczeństwa może być więcej. Hubbard pisze, że tempo zgłoszeń nadal rośnie. Jeśli aktualizacje robisz raz na kwartał, możesz przegapić kilka wydań z rzędu. Przy stałej opiece nad stroną WordPress aktualizacje testuje się na kopii i wgrywa w ciągu dni, nie miesięcy.
Jeśli chcesz sprawdzić, w jakim stanie jest Twoja strona teraz, zacznij od audytu bezpieczeństwa WordPress.
Do kiedy firmy mają zadeklarować finansowanie
Hubbard zaoferowała zainteresowanym firmom szczegółowe dane programu i napisała, że chce mieć “pierwszą grupę współtwórców, którzy staną z nami w tym kwartale” (tłumaczenie własne), czyli do końca grudnia 2026. Na razie żadna firma nie ogłosiła publicznie konkretnej kwoty. Dopiszę aktualizację, gdy któraś to zrobi.
Terminy aktualizacji po WordPress 7.1.3 i koszty łatania w umowie utrzymania. Aktualizacja 10.10.2026
Do 10 października 2026 nie znalazłem publicznej deklaracji żadnej z firm z listy, więc stan z sekcji o terminach się nie zmienia. Ocenę ryzyka da się natomiast doprecyzować. Patchstack opisuje 7.1.3 tak:
“Zaktualizuj, gdy tylko możesz, ale to nie jest alarm, dla którego trzeba rzucić wszystko.”
Patchstack, WordPress 7.1.3 security release, 6 października 2026, tłumaczenie własne
Jedna z siedmiu poprawek działa bez konta i bez udziału ofiary, trzy zgłosił Anthropic. Dla właściciela strony wynika z tego rytm: łatka rdzenia w ciągu kilku dni, po teście na kopii, nie w następnym kwartale.
Pieniądze, o które prosi Hubbard, pokrywają nagrody i triaż w rdzeniu. Praca przy Twojej stronie (test, wdrożenie, kontrola wtyczek) to osobny koszt, który musi być wpisany w umowę. Zapytaj wykonawcę opieki nad stroną o trzy rzeczy: w ile dni od wydania bezpieczeństwa wgrywa aktualizację rdzenia, czy testuje ją na stagingu i czy wydanie poza zwykłym cyklem mieści się w abonamencie.
Ostatnia aktualizacja: 13 października 2026.
