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 had collapsed the cost of finding, reporting, and exploiting vulnerabilities”
Mary Hubbard, cytowana przez The Repository, 8 października 2026
Według niej program dostał w 90 dni prawie 2000 zgłoszeń, więcej niż kiedykolwiek, “and the pace is still climbing”. 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.
“Nearly half the program’s lifetime payouts happened in a single quarter, and the curve only goes one direction.”
Mary Hubbard, cytowana przez The Repository, 8 października 2026
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: “The economics are what’s broken, not the program”.
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, “unfortunately without much traction”.
- 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 “this process needs to be reformed”.
GoDaddy, Newfold Digital i Wordfence nie odpowiedziały do czasu publikacji tekstu.
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.
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ć “first group of contributors standing with us this quarter”, czyli do końca grudnia 2026. Na razie żadna firma nie ogłosiła publicznie konkretnej kwoty. Dopiszę aktualizację, gdy któraś to zrobi.
Ostatnia aktualizacja: 9 października 2026.
