| Nazwa wtyczki | myCred |
|---|---|
| Rodzaj podatności | Luka w kontroli dostępu |
| Numer CVE | CVE-2026-40794 |
| Pilność | Średni |
| Data publikacji CVE | 2026-04-26 |
| Adres URL źródła | CVE-2026-40794 |
Naruszenie kontroli dostępu w myCred (<= 3.0.3) — Co właściciele i deweloperzy stron WordPress muszą teraz zrobić
Autor: Zespół ds. bezpieczeństwa WP-Firewall
Data: 2026-04-26
Tagi: WordPress, myCred, WAF, podatność, bezpieczeństwo
Streszczenie: Podatność na naruszenie kontroli dostępu w wtyczce myCred dla WordPressa (dotycząca wersji <= 3.0.3, naprawionej w 3.0.4, CVE-2026-40794) pozwala uwierzytelnionemu użytkownikowi o niskich uprawnieniach (tak niskich jak Subskrybent) na wywołanie funkcji, do których nie powinien mieć dostępu. CVSS: 6.5 (Średni). Ten post wyjaśnia ryzyko, wzorce eksploatacji, wykrywanie, łagodzenie oraz jak WP-Firewall chroni Twoją stronę — natychmiastowo i długoterminowo.
Spis treści
- Krótkie wprowadzenie
- Czym dokładnie jest naruszenie kontroli dostępu?
- O problemie myCred (CVE-2026-40794) — w skrócie
- Dlaczego to ma znaczenie: scenariusze ataków i wpływ
- Natychmiastowe kroki dla każdego właściciela strony WordPress (pilna lista kontrolna)
- Jeśli nie możesz zaktualizować natychmiast — praktyczne łagodzenia
- Jak WP-Firewall Cię chroni (podejście techniczne i możliwości łagodzenia)
- Wykrywanie: logi, IOCs i na co zwracać uwagę
- Dla deweloperów: jak poprawnie naprawić, wzmocnić i przetestować punkty końcowe
- Podręcznik reagowania na incydenty (krok po kroku)
- Długoterminowe wzmocnienie i konserwacja
- Zacznij chronić swoją stronę z WP-Firewall Free
- Ostateczne przemyślenia i dalsza lektura
Krótkie wprowadzenie
myCred to popularna wtyczka WordPress używana do zarządzania punktami, saldami i funkcjami grywalizacji na stronach WordPress. Wtyczki, które obsługują punkty użytkowników, salda lub transakcje między użytkownikami zasługują na szczególną uwagę, ponieważ ich funkcjonalność bezpośrednio odnosi się do stanu aplikacji i uprawnień użytkowników.
24 kwietnia 2026 roku ujawniono publicznie podatność na naruszenie kontroli dostępu w myCred (dotyczącą wersji <= 3.0.3) oraz wydano łatkę (3.0.4). Podatność została przypisana do CVE-2026-40794. Klasyfikowana jest jako naruszenie kontroli dostępu, ponieważ ścieżka kodu obsługującego żądania nie miała odpowiednich sprawdzeń autoryzacji ani nonce, co pozwalało uwierzytelnionym kontom o niskich uprawnieniach (poziom Subskrybenta) na wywoływanie działań o wyższych uprawnieniach.
To ostrzeżenie zostało napisane z perspektywy dostawcy zapory WordPress i zespołu operacji bezpieczeństwa. Celem jest pomoc właścicielom stron, administratorom i deweloperom w natychmiastowym zmniejszeniu ryzyka oraz wdrożeniu bardziej odpornych kontroli w przyszłości.
Czym dokładnie jest naruszenie kontroli dostępu?
Naruszenie kontroli dostępu występuje, gdy aplikacja nie egzekwuje właściwie, kto może robić co. W wtyczkach WordPressa zazwyczaj obejmuje to:
- Brak lub niepoprawne sprawdzenia uprawnień (np. wykonywanie działań administracyjnych bez weryfikacji current_user_can()).
- Brakujące lub nieprawidłowe kontrole nonce dla akcji wywoływanych przez admin-ajax.php, punkty końcowe REST lub przesyłanie formularzy.
- Nadmierna ekspozycja uprzywilejowanej funkcjonalności przez punkty końcowe AJAX lub REST dostępne dla kont o niskich uprawnieniach.
- Błędy logiczne, które pozwalają użytkownikom na eskalację uprawnień lub wykonywanie działań, których nie powinni.
Uszkodzona kontrola dostępu jest często wykorzystywana na dużą skalę, ponieważ zazwyczaj wymaga jedynie uwierzytelnionego konta — nawet darmowego/kont o niskich uprawnieniach — a wiele stron pozwala na rejestrację użytkowników lub ma już obecnych subskrybentów.
O problemie myCred (CVE-2026-40794) — w skrócie
- Dotknięta wtyczka: myCred
- Wersje podatne na ataki: <= 3.0.3
- Poprawione w: 3.0.4
- Klasa podatności: Uszkodzona kontrola dostępu (OWASP A1 / A01)
- CVE: CVE-2026-40794
- Data raportu Patchstack: 24 kwietnia 2026 (ujawnienie publiczne)
- Priorytet Patchstack: Średni
- Podstawowy wynik CVSS: 6.5
- Wymagane uprawnienia do wykorzystania: Subskrybent (tj. niskie uprawnienia)
Główny problem: niektóre punkty końcowe wtyczki były dostępne dla uwierzytelnionych użytkowników o niskich uprawnieniach (rola subskrybenta) bez odpowiedniej autoryzacji/nonces, co umożliwiało działania, które powinny być ograniczone.
Dlaczego to ma znaczenie: scenariusze ataków i wpływ
Mimo że wynik CVSS to “średni”, praktyczny wpływ może być poważny w zależności od tego, jak wtyczka była używana na Twojej stronie.
Potencjalne scenariusze wpływu:
- Nieautoryzowana manipulacja punktami: Atakujący mogą dodawać lub usuwać punkty z kont, co w grach z elementami rywalizacji może przekładać się na oszustwa finansowe lub reputacyjne (np. zniżki, zakupy, odblokowywanie treści).
- Nadużycie logiki strony: Punkty mogą być używane jako waluta do zakładów/stawiania, głosowania w konkursach lub do odblokowywania uprzywilejowanej treści. Manipulacja podważa zaufanie i może zaszkodzić logice biznesowej.
- Pośrednia eskalacja: Atakujący mogą manipulować funkcją wtyczki, aby wywołać inne zachowania (na przykład tworzenie transakcji lub wywoływanie e-maili, które mogą być używane w inżynierii społecznej).
- Oszustwa związane z zapasami lub kredytami: Jeśli punkty odpowiadają towarom o wartości przechowywanej, atakujący mogą wyciągać wartość.
- Masowe wykorzystanie: Ponieważ luka wymaga jedynie konta o niskich uprawnieniach, atakujący mogą rejestrować konta i prowadzić zautomatyzowane kampanie, celując w wiele stron.
Ta klasa luk jest cenna dla atakujących, ponieważ można ją wykorzystać na dużą skalę i często można ją wykonać bez omijania systemów uwierzytelniania.
Natychmiastowe kroki dla każdego właściciela strony WordPress (pilna lista kontrolna)
- Zaktualizuj myCred do 3.0.4 (lub najnowszej dostępnej) natychmiast.
- To jest ostateczna poprawka. Jeśli prowadzisz wiele stron, priorytetowo traktuj publiczne/strony o dużym ruchu.
- Jeśli nie możesz zaktualizować od razu, zastosuj tymczasowe środki zaradcze (sekcja poniżej).
- Rotuj klucze i sekrety, jeśli podejrzewasz naruszenie (np. klucze API, tokeny integracyjne).
- Audytuj konta użytkowników pod kątem nieoczekiwanych subskrybentów i podejrzanych rejestracji.
- Wyłącz lub usuń nieufne konta.
- Wykonaj kopię zapasową swojej strony (pliki + DB) przed przeprowadzeniem analizy lub prac naprawczych.
- Przeprowadź pełne skanowanie złośliwego oprogramowania i sprawdzenie integralności kodu, przesyłanych plików i plików rdzeniowych.
- Monitoruj logi (logi dostępu, logi błędów PHP, logi wtyczek) pod kątem podejrzanej aktywności (zobacz IOCs poniżej).
- Zmień lub wzmocnij hasła administratorów i włącz MFA dla kont administratorów.
- Rozważ włączenie zarządzanego WAF/łatki wirtualnej (zobacz nasze rekomendacje poniżej).
- Jeśli znajdziesz oznaki naruszenia, skontaktuj się ze specjalistą ds. reakcji na incydenty lub dostawcą hostingu.
Jeśli nie możesz zaktualizować natychmiast — praktyczne łagodzenia
Wielu właścicieli stron nie może natychmiast zaktualizować wtyczek z powodu ograniczeń związanych z kompatybilnością lub kontrolą zmian. Jeśli należysz do tej kategorii, zrób to teraz:
- Zastosuj regułę WAF (łatkę wirtualną), która blokuje żądania przypominające exploity, celujące w punkty końcowe myCred wywoływane przez subskrybentów. To może dać czas bez wprowadzania zmian w kodzie.
- Ogranicz dostęp do admin-ajax.php i odpowiednich punktów końcowych REST:
- Zezwól tylko na uwierzytelnione żądania z zaufanych ról lub znanych źródeł.
- Odrzuć żądania, które nie mają ważnych nonce'ów WordPressa lub pochodzą z adresów IP wykazujących podejrzane wzorce.
- Ogranicz liczbę działań na koncie, które manipulują saldami lub przesyłają te punkty końcowe.
- Tymczasowo wyłącz funkcje, które pozwalają na dostosowanie punktów za pomocą działań na froncie, jeśli biznes na to pozwala.
- Zablokuj rejestrację użytkowników, jeśli nie jest wymagana — to zapobiega masowemu tworzeniu kont.
- Umieść na czarnej liście lub wyzwij podejrzane adresy IP i agenty użytkownika.
- Wymuś ponowne logowanie użytkowników przed wykonaniem wrażliwych operacji.
- Audytuj i ogranicz wszelkie integracje zewnętrzne, które mogą wchodzić w interakcję z myCred.
Notatka: To są tymczasowe środki zaradcze — nie są one substytutem stosowania oficjalnej łatki wtyczki.
Jak WP-Firewall Cię chroni (podejście techniczne i możliwości łagodzenia)
Jako dostawca zapory WordPress i zespół operacji bezpieczeństwa, podchodzimy do takich luk w zabezpieczeniach warstwowo:
-
Szybkie wirtualne łatanie (sygnatury WAF)
- Analizujemy publiczne szczegóły luk w zabezpieczeniach i tworzymy ukierunkowane zasady WAF, które blokują wzorce eksploatacji, nie zakłócając przy tym legalnego ruchu.
- Przykładowe techniki: blokuj podejrzane POST-y do admin-ajax.php, gdzie akcja lub parametry odpowiadają punktom końcowym myCred wywoływanym bez ważnych wzorców nonce, oraz gdzie zdolność użytkownika jest niewystarczająca.
- Wirtualne łaty chronią Twoją stronę natychmiast, podczas gdy testujesz i stosujesz oficjalną poprawkę wtyczki.
-
Walidacja żądań i wykrywanie anomalii
- Nasza zarządzana zapora inspektuje ładunki żądań, nagłówki i wzorce. Oznacza lub blokuje nienormalne wartości lub sekwencje parametrów związanych z eksploatacją.
- Ograniczenie liczby żądań i automatyczne środki zaradcze dla botów zmniejszają powierzchnię ataku ze strony atakujących masową rejestrację.
-
Zarządzane skanowanie złośliwego oprogramowania i czyszczenie
- Okresowe skanowanie w poszukiwaniu anomalii, podejrzanych plików i wstrzyknięć kodu oraz automatyczne usuwanie lub zalecenia dotyczące podejrzanych kompromisów.
-
Ochrona punktów końcowych oparta na rolach
- Możemy ograniczyć dostęp do admin-ajax i punktów końcowych REST według zdolności lub adresu IP. Tam, gdzie to możliwe, egzekwujemy kontrole weryfikacji nonce na poziomie WAF (na przykład, wykrywanie brakujących/nieprawidłowych nonce).
-
Rejestrowanie i powiadamianie
- Szczegółowe logi zablokowanych prób i podejrzanej aktywności dają Ci kontekst potrzebny do reakcji na incydenty i analizy kryminalistycznej.
-
Szybkie wsparcie w odzyskiwaniu
- Jeśli instrumentacja wykryje kompromitację, usługi zarządzane mogą pomóc w izolacji strony i przywracaniu z czystej kopii zapasowej, zachowując logi do analizy.
Jak to wygląda operacyjnie:
- W ciągu kilku godzin od publicznego ujawnienia wdrażamy wirtualną łatę dla klientów: ukierunkowane sygnatury, które blokują znane wektory eksploatacji, minimalizując jednocześnie fałszywe alarmy.
- Dostarczamy listę kontrolną środków zaradczych dla właścicieli stron oraz szczegółowe wskazówki dla programistów, jak zastosować długoterminowe poprawki.
Jeśli prowadzisz działającą stronę WordPress i nie możesz od razu zaktualizować każdego wtyczki (lub masz niestandardowe integracje), to jest najbezpieczniejsze podejście: chroń aplikację, podczas gdy planujesz, testujesz i wdrażasz oficjalną aktualizację.
Wykrywanie: logi, IOCs i na co zwracać uwagę
Nawet po załataniu powinieneś zweryfikować, czy wcześniej miała miejsce eksploatacja. Oto, czego szukać:
- Podejrzane żądania admin-ajax.php
- Wysokie ilości żądań POST do admin-ajax.php z parametrami akcji odnoszącymi się do punktów myCred, szczególnie jeśli pochodzą z tego samego adresu IP lub z nowo utworzonych kont.
- Żądania brakujące standardowe pola nonce WP (np. ‘_wpnonce’), gdy oczekuje się, że punkt końcowy ich wymaga.
- Nietypowe zmiany salda
- Nagłe wzrosty/spadki punktów dla kont w krótkim okresie czasu.
- Wiele kont z identycznymi korektami punktów (masowe nadużycie).
- Nowe lub niespodziewane konta użytkowników
- Wzrost liczby zapisów subskrybentów w okolicach dat ujawnienia.
- Niespodziewane e-maile lub powiadomienia
- Jeśli myCred wyzwala automatyczne e-maile po transferach punktów, sprawdź, czy wystąpił wzrost liczby e-maili transakcyjnych.
- Abnormalne wzorce w logach dostępu serwera
- Powtarzające się żądania do tych samych punktów końcowych z małego zestawu adresów IP lub z dostawców hostingu w chmurze używanych przez botnety.
- Wskaźniki wewnątrz bazy danych WordPress
- Nietypowe wpisy w tabelach związanych z punktami, logami lub transakcjami.
Przykładowe zapytania wyszukiwania (logi):
- Apache/Nginx access_log:
grep "admin-ajax.php" access_log | grep -i "action=mycred" - Baza danych:
Szukaj nietypowych wstawek/aktualizacji w tabelach logów mycred lub kluczach usermeta związanych z punktami.
Jeśli wykryjesz podejrzaną aktywność, zachowaj logi i kopie zapasowe do analizy kryminalistycznej przed podjęciem nieodwracalnych działań.
Dla deweloperów: jak poprawnie naprawić, wzmocnić i przetestować punkty końcowe
Jeśli utrzymujesz wtyczkę lub stronę z niestandardowym kodem uzyskującym dostęp do interfejsów API myCred, stosuj te bezpieczne wzorce.
- Sprawdzenia uprawnień
if ( ! current_user_can( 'manage_options' ) ) {Dla działań, które powinny być dostępne dla podzbioru ról, definiuj i sprawdzaj możliwości, a nie role.
- Weryfikacja nonce
if ( ! isset( $_REQUEST['_wpnonce'] ) || ! wp_verify_nonce( $_REQUEST['_wpnonce'], 'mycred-action' ) ) { - Punkty końcowe REST: permission_callback
register_rest_route( 'mycred/v1', '/adjust/', array(; - Sprawdź i zdezynfekuj dane wejściowe
$amount = isset( $_POST['amount'] ) ? intval( $_POST['amount'] ) : 0; - Używaj najmniejszych uprawnień do działań
Przyznawaj tylko niezbędne uprawnienia. Jeśli działanie jest czysto kosmetyczne, unikaj włączania uprawnienia, które pozwala na skutki uboczne na poziomie administratora.
- Audytuj punkty końcowe pod kątem nadużyć logiki biznesowej
Rozważ, czy punkt końcowy powinien być w ogóle wywoływany przez front-end. Jeśli nie, ogranicz do kontekstów administratora lub uwierzytelnionych wywołań serwer-serwer.
- Pokrycie testowe
Dodaj testy integracyjne, które symulują użytkowników o niskich uprawnieniach próbujących wywołać uprzywilejowane punkty końcowe. Upewnij się, że testy nie powiodą się, jeśli brakuje sprawdzeń uprawnień.
- Rejestrowanie i ograniczanie liczby żądań
Dodaj logi dla krytycznych działań i ogranicz liczbę powtarzających się prób z tego samego konta/IP.
Przykład reguły w stylu ModSecurity do wirtualnej łatki (ilustracyjny)
Poniżej znajduje się ogólny, nieeksploatacyjny kod i niepełny przykład wzorca sygnatury WAF, który zarządzany firewall mógłby użyć do blokowania podejrzanych żądań kierowanych do punktów końcowych myCred. To jest ilustracyjne; rzeczywiste reguły produkcyjne powinny być dostosowane do twojego środowiska, aby uniknąć fałszywych pozytywów.
Proszę nie wklejać ładunków eksploatacyjnych na swoją stronę.
SecRule REQUEST_URI "@contains admin-ajax.php"Uwagi:
- Zarządzany WAF klasy produkcyjnej używa wielu sygnałów: wzorców nonce, sprawdzeń nagłówków, wykrywania anomalii behawioralnych i ograniczania liczby żądań.
- Powyższe jest przykładem dla doświadczonych administratorów; niewłaściwe reguły ModSecurity mogą zepsuć funkcjonalność strony.
Podręcznik reagowania na incydenty (krok po kroku)
- Zachowaj dowody
- Natychmiast wykonaj kopie logów dostępu, logów PHP i zrzutów bazy danych. Nie nadpisuj.
- Odizoluj witrynę
- Jeśli to możliwe, umieść stronę w trybie konserwacji lub tymczasowo ogranicz dostęp według IP.
- Przeprowadź pełne skanowanie złośliwego oprogramowania
- Sprawdź przesyłane pliki, motywy, wtyczki i mu-wtyczki pod kątem wstrzykniętego kodu.
- Porównaj sumy kontrolne plików.
- Użyj czystych kopii rdzenia WordPressa i wtyczek, aby znaleźć zmodyfikowane pliki.
- Cofnij skompromitowane dane uwierzytelniające
- Zmień hasła administratora, zresetuj klucze API i rotuj wszelkie tokeny integracyjne.
- Oczyść lub przywróć
- Tam, gdzie to możliwe, oczyść skompromitowane pliki lub przywróć z znanej, dobrej kopii zapasowej.
- Zastosuj łatkę
- Zaktualizuj myCred do wersji 3.0.4 lub wyższej oraz zaktualizuj inne wtyczki, motywy i rdzeń WP.
- Utwardzać i monitorować
- Włącz ochrony WAF, ogranicz punkty końcowe, wzmocnij logowanie i monitoruj dalsze anomalie.
- Powiadom interesariuszy.
- Jeśli salda użytkowników lub dane osobowe zostały naruszone, postępuj zgodnie z obowiązującymi wymaganiami powiadamiania o naruszeniu.
- Przeprowadź analizę przyczyn źródłowych.
- Udokumentuj, jak doszło do incydentu i jakie kontrole zapobiegną jego powtórzeniu.
Długoterminowe wzmocnienie i konserwacja
Wrażliwości związane z naruszeniem kontroli dostępu są często przewidywalne i zapobiegawcze. Przyjmij te praktyki:
- Bądź na bieżąco z ujawnieniami luk i subskrybuj wiarygodne źródła informacji o bezpieczeństwie.
- Utrzymuj rytm łatania: cotygodniowe lub co dwa tygodnie kontrole wtyczek oraz zaplanowane okna konserwacyjne na aktualizacje.
- Wprowadź zasady minimalnych uprawnień: ogranicz domyślne role, używaj szczegółowych możliwości.
- Użyj środowisk deweloperskich/testowych do testowania aktualizacji wtyczek przed produkcją.
- Włącz uwierzytelnianie wieloskładnikowe (MFA) dla uprzywilejowanych kont.
- Wzmocnij dostęp administratorów:
- Ogranicz dostęp do wp-login.php i /wp-admin według IP, jeśli to możliwe.
- Użyj silnego ograniczenia szybkości.
- Wprowadź CI/CD z bramkami bezpieczeństwa i automatycznymi testami do sprawdzania uprawnień.
- Monitoruj logi i ustawiaj alerty na nietypowe wzrosty aktywności.
Zacznij chronić swoją stronę — wypróbuj darmowy plan WP-Firewall
Jeśli szukasz natychmiastowej, zarządzanej ochrony podczas stosowania łatki wtyczki, rozważ wypróbowanie naszego darmowego poziomu. Plan WP-Firewall Basic (Darmowy) zapewnia podstawową ochronę, aby utrzymać atakujących na dystans i dać ci przestrzeń do bezpiecznego stosowania łatek. Funkcje obejmują:
- Zarządzany firewall z ukierunkowanymi zasadami WAF dla znanych luk w wtyczkach WordPress
- Nielimitowana przepustowość i inspekcja żądań w czasie rzeczywistym
- Skanowanie złośliwego oprogramowania i automatyczne łagodzenie ryzyk z OWASP Top 10
- Możliwości wirtualnego łatania, dzięki którym jesteś chroniony podczas stosowania oficjalnych poprawek
Zarejestruj się tutaj, aby skorzystać z bezpłatnego planu: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Dla tych, którzy chcą dodatkowej automatyzacji i szybszej naprawy, nasze płatne plany dodają funkcje takie jak automatyczne usuwanie złośliwego oprogramowania, kontrola czarnych/białych list IP, miesięczne raporty bezpieczeństwa i automatyczne wirtualne łatanie. Ale jeśli teraz brakuje ci czasu, darmowy plan jest doskonałym natychmiastowym krokiem.
Praktyczna lista kontrolna — co zrobić teraz (podsumowanie)
- Zaktualizuj myCred do 3.0.4 lub nowszej wersji.
- Jeśli nie możesz zaktualizować, włącz wirtualne łatanie WP-Firewall/zasady WAF, które blokują wzorce exploitów.
- Audytuj konta subskrybentów i rejestracje.
- Wykonaj kopię zapasową strony i zachowaj logi do audytu.
- Uruchom skanowanie złośliwego oprogramowania i integralności.
- Rotuj sekrety, jeśli podejrzewasz kompromitację; zmień hasła administratora i włącz MFA.
- Zastosuj ograniczenia szybkości i ogranicz dostęp do admin-ajax i punktów końcowych REST.
- Przejrzyj kod dewelopera pod kątem nonce'ów i kontroli uprawnień oraz dodaj testy kontroli dostępu.
Ostateczne przemyślenia
Problemy z kontrolą dostępu nie są egzotyczne — są bardzo powszechnym źródłem rzeczywistej kompromitacji. Ich niebezpieczeństwo wzrasta, gdy wtyczka kontroluje krytyczne dla biznesu funkcje, takie jak punkty, kredyty i stan transakcji. To właśnie dlatego ta luka w myCred przyciągnęła uwagę: konta o niskich uprawnieniach mogące wywoływać zachowania o wyższych uprawnieniach to klasyczny wzór, który należy chronić za pomocą obrony w głębokości.
Łataj szybko: zawsze priorytetowo traktuj instalację oficjalnej aktualizacji wtyczki. Jeśli musisz opóźnić, zastosuj wirtualne łatanie z zaufanego zarządzanego firewalla i postępuj zgodnie z powyższą listą kontrolną łagodzenia. Na koniec potraktuj to jako okazję do zaostrzenia modelowania kontroli dostępu i poprawy ogólnej gotowości na incydenty.
Jeśli potrzebujesz pomocy w wdrażaniu opisanych tutaj środków łagodzących lub chciałbyś, abyśmy natychmiast wdrożyli ukierunkowaną łatkę wirtualną dla twojej strony WordPress, nasz zespół jest gotowy do pomocy. Oferujemy zarówno automatyczne, jak i przeglądane przez ludzi zabezpieczenia zaprojektowane dla rzeczywistości WordPress — wirtualne łatanie, dostosowywanie WAF, skanowanie złośliwego oprogramowania i pilne naprawy.
Bądź bezpieczny, aktualizuj wtyczki i zawsze traktuj kontrolę dostępu jako kluczową kwestię bezpieczeństwa.
— Zespół bezpieczeństwa WP-Firewall
Odniesienia i zasoby
- CVE-2026-40794 (myCred Uszkodzona Kontrola Dostępu)
- Dokumentacja dewelopera WordPress: nonces, permission_callback REST API, sprawdzanie uprawnień
- OWASP: wytyczne dotyczące złamanej kontroli dostępu
(Koniec powiadomienia)
