Blog 24/7
ARK. B17Parametr monitoringuBezpieczeństwo · lista 87 parametrów

Dostępność wp-cron.php

ważność średniamierzonysposób exposure

Czy wp-cron.php jest dostępny z zewnątrz. Może być nadużyty do przeciążenia serwera.

ARK. 1

WIKI

artykuł z 16.09.2026 · źródeł 7

Dostępność wp-cron.php to parametr monitoringu stron internetowych, który sprawdza, czy plik wp-cron.php w katalogu głównym WordPressa odpowiada na żądania z zewnątrz. Pomiar kończy się jednym z trzech wyników: plik odpowiada, dostęp jest zablokowany albo nie udało się uzyskać odpowiedzi. Nagłówek pliku opisuje go jako pseudodemona crona, który uruchamia zaplanowane zadania WordPressa [3].

Jak działa

WP-Cron przy każdym wczytaniu strony sprawdza listę zaplanowanych zadań i uruchamia te, na które przyszła pora [1]. W przeciwieństwie do systemowego crona nie działa stale: zadanie zaplanowane na 14:00 wykona się dopiero przy pierwszym wczytaniu strony, np. o 17:00 [1].

Uruchomienie odbywa się przez HTTP. Funkcja spawn_cron zakłada blokadę i wysyła do wp-cron.php na tej samej stronie żądanie pętli zwrotnej (ang. loopback) z parametrem doing_wp_cron, z limitem czasu 0,01 s i bez czekania na odpowiedź [4]. Od wersji 6.9 jest to wywoływane na akcji shutdown, bo wcześniejsze wywołanie wydłużało czas do pierwszego bajtu strony [4]. Sam wp-cron.php najpierw wczytuje środowisko WordPressa przez wp-load.php, potem sprawdza, czy są zadania gotowe do uruchomienia i czy blokada należy do tego wywołania, i dopiero wtedy wykonuje zadania [3].

RYS. 1.1Wywołanie WP-Cron przy wizycie

Stała DISABLE_WP_CRON w wp-config.php wyłącza WP-Cron [5]: wizyty przestają wywoływać wp-cron.php [4]. Podręcznik zaleca wtedy harmonogram systemu, np. wpis crontab z poleceniem wget --delete-after http://YOUR_SITE_URL/wp-cron.php, uruchamiany raz na dobę albo co 15 minut [2]. Nagłówek wp-cron.php zaznacza, że ta stała i bezpośrednie wywołanie pliku wzajemnie się wykluczają, a wywołanie bezpośrednie działa bez niej [3]. Stała nie zamyka więc pliku, tylko przenosi wywołanie z wizyt na zewnętrzny harmonogram.

Standardy i specyfikacje

  • Plugin Handbook: Cron opisuje model wywołania przy wczytaniu strony [1], a rozdział o harmonogramie systemu — wyłączenie tego modelu i wywoływanie wp-cron.php przez HTTP [2].
  • wp-config.php opisuje ALTERNATE_WP_CRON, tryb z przekierowaniem przeglądarki, stosowany zwykle wtedy, gdy zaplanowane wpisy nie publikują się na czas, oraz WP_CRON_LOCK_TIMEOUT: proces crona nie uruchomi się częściej niż raz na podaną liczbę sekund [5].
  • CVE-2023-22622: WordPress do wersji 6.1.1 uzależnia wykonanie wp-cron.php, a z nim aktualizacji bezpieczeństwa, od nieprzewidywalnych wizyt, a przewodniki instalacji i bezpieczeństwa o tym nie wspominają. NVD ocenia wpis na 5,3 w CVSS 3.1 [7].

Zagrożenia i skutki

Obciążenie żądaniami. W raporcie z 2023 roku w programie ujawniania podatności Departamentu Obrony USA na HackerOne badacz opisał wp-cron.php jako cel odmowy usługi: po około tysiącu żądań wysłanych skryptem strona zwracała kod 502. Raport zamknięto jako rozwiązany [6]. Kod pliku pokazuje, skąd koszt: każde żądanie wczytuje całe środowisko WordPressa, zanim sprawdzi listę zadań i blokadę [3]. Blokada ogranicza powtórne wykonanie zadań, a nie liczbę żądań [3] [5]. Zalecane w raporcie DISABLE_WP_CRON z cronem systemowym [6] nie odcina pliku od żądań z zewnątrz [3].

Opóźnione zadania. Na stronie z małym ruchem zadania wykonują się z opóźnieniem [1], co CVE-2023-22622 wiąże z opóźnieniem aktualizacji bezpieczeństwa [7]. Zablokowanie wp-cron.php na serwerze bez innego harmonogramu daje ten sam skutek, bo pętla zwrotna i polecenie wget wywołują ten sam adres [2] [4].

Publiczny plik to norma. Mechanizm wymaga, żeby wp-cron.php odpowiadał na żądania HTTP: wywołuje go sam WordPress [4] albo zewnętrzny harmonogram [2]. Odpowiedź 200 jest domyślnym stanem instalacji, a nie błędem konfiguracji.

RYS. 1.2Obsługa żądania wp-cron.php

Przykłady

KonfiguracjaKto wywołuje wp-cron.phpOdpowiedź na GET /wp-cron.php
Domyślna [1] [4]WordPress przy wizycie, pętlą zwrotną200, pusta treść [3]
DISABLE_WP_CRON i crontab z wget [2]harmonogram systemu przez HTTP200, plik nadal publiczny [3]
ALTERNATE_WP_CRON [5]odwiedzający po przekierowaniu, plik dołączany w tym samym żądaniu [4]200
Plik zablokowany, brak harmonogramupętla zwrotna nie dociera do pliku [4]403, zadania czekają
Seria żądań wysłanych skryptem [6]skrypt obciążający502 przy przeciążeniu serwera
TAB. 1.1Przypisy7
  1. [1] Cron — Plugin Handbook · WordPress Developer Resources
  2. [2] Hooking WP-Cron Into the System Task Scheduler — Plugin Handbook · WordPress Developer Resources
  3. [3] wp-cron.php (wordpress-develop, trunk) · WordPress Core
  4. [4] wp-includes/cron.php (wordpress-develop, trunk) · WordPress Core
  5. [5] wp-config.php — Advanced Administration Handbook · WordPress.org
  6. [6] Report #1888723 — WordPress application vulnerable to DoS attack via wp-cron.php · HackerOne / U.S. Dept Of Defense
  7. [7] CVE-2023-22622 · NIST (National Vulnerability Database)
ARK. 2

STATS

wyniki z systemu · tylko liczby zbiorcze
TAB. 2.1Odczyty per strona—

Ten parametr nie zapisuje odczytu per strona — przebieg zostawia tylko ustalenia, więc liczby sprawdzonych stron i wyników „ok” system nie ma. Pojawią się po wdrożeniu zapisu przebiegów per strona per parametr.

TAB. 2.3Ustalenia—

Ten parametr nie otworzył jeszcze żadnego ustalenia w bazie LAB247. Pusto nie znaczy „czysto” — znaczy, że nic nie przekroczyło reguły.

TAB. 2.4Przebiegi z tym sposobem sprawdzeniaod 09.09.2026
Przebiegów
33sposób exposure
W 30 dni
0przebiegów
Ostatni
19.09.2026start przebiegu
Stron w przebiegach
—33 przebiegów bez liczby stron
ARK. 3

CARD

karta z kodu CREATO_PING, odczyt 22.09.2026

Jak ten parametr trafia do ClickUpa: wynik sondy to linia w subtasku 2. Pomiar, a usterka, którą otwiera — linia w subtasku 1. Podsumowanie (z identyfikatorem CWE i kategorią OWASP), skąd liczy się wskaźnik zagrożenia i status strony. Projekcja z bazy skanera odświeża oba subtaski co godzinę. Do 22.09 każde ustalenie dostawało własny subtask i status ze starego słownika (PODATNA, WARNING…) — te słowa zostały jeszcze w części opisów pomiaru niżej jako język wewnętrzny sond.

RYS. 3.1Droga parametru przez system: Dostępność wp-cron.php
TAB. 3.1Pomiarpliki: 6
Obszar i ważnośćBezpieczeństwo · średnia (B17)
Workflow i częstotliwośćcreato_ping_security_v2 · P3 działa na LAB247Skaner 2.0, rytm „p3” / „bezpieczenstwo”: premium co 6 h, reszta co 24 h (tier 1–3), co 9 dni (tier 4) · Dokładny skan. dns_integrity porównuje NS, MX, SPF i DMARC z wzorcem z poprzedniego przebiegu.
Sonda i helpersposób exposure · CREATO_PING/helpers/exposure_check.py
Testy
  1. Tylko przebieg P3; przed sondami strażnik losowej ścieżki (200 z treścią = sondy pominięte).
  2. GET https://domena/wp-cron.php bez podążania za przekierowaniami.
  3. Reguła: sam kod 200 — treść i nagłówki nie są sprawdzane.
Typ wyniku0 albo 1 ustalenie exposure_wpcron (powaga niska w helperze, normalna w polityce) — dziś odrzucane przed zapisem
Jednostkabrak — wynik jakościowy
Próg i regułaTimeout odpowiedzi 15 s, połączenia 5 s. Reguła: kod 200 = exposure_wpcron.
Gdzie leżą pokrętłaCREATO_PING/helpers/exposure_check.py → PROBES (/wp-cron.php, reguła 200)CREATO_PING/helpers/config.py → TIMEOUTS["exposure"], TIMEOUTS["security_connect"]CREATO_PING/helpers/security_runner.py → do_writera (bramka gate z polityki; sito powagi zniknęło 18.09)CREATO_PING/config/incident_policy.toml → [finding] exposure_wpcron
Retencja odczytówSurowy pomiar jako NIEZMIENNY wiersz tabeli `odczyty` w bazie skanera (wejście, wyjście, dowody, sha karty sondy i helpera, commit kodu) — trigger odrzuca każdą zmianę. Okno retencji z kohorty: 90 dni premium, 30 dni reszta; poza oknem zostają odczyty z werdyktem problemu, akcją albo etykietą, bo replay reguł ich potrzebuje (`skaner/retencja.py`). Do LAB247 ten kanał nie idzie (do bazy serwisu jadą dziś tylko sprawdzenia dostępności), więc poza odczytem zostaje werdykt w tabeli `werdykty` i sprawa w tabeli `sprawy`.
Znane rozbieżności
  1. Reguła mierzy domyślny stan WordPressa: wp-cron.php odpowiada 200 na każdej instalacji, bo WordPress sam go wywołuje przez HTTP — po włączeniu zapisu ustalenie padłoby prawie wszędzie.
  2. Katalog mówi o wektorze przeciążenia, ale sonda nie mierzy niczego, co odróżnia stronę podatną od zwykłej.
  3. Nota polityki podpowiada DISABLE_WP_CRON, a ta stała nie zamyka pliku dla żądań z zewnątrz — sonda dalej widzi 200.
  4. Brak trzeciego stanu, brak śledzenia przekierowań i brak sygnału zamknięcia — wspólne dla sond ekspozycji.
kandydaci do pętli: kod a opis parametru albo specyfikacja
Karta przepisana zCREATO_PING/helpers/exposure_check.py · CREATO_PING/helpers/security_runner.py · CREATO_PING/config/incident_policy.toml · CREATO_PING/skaner/klasyfikacja.py · CREATO_PING/skaner/usterki.toml · CREATO_PING/skaner/ocena.py · odczyt 22.09.2026
TAB. 3.2Co oznacza failtypów Findingów: 1

exposure_wpcron: bramka polityki zamknięta (gate=false) — zostaje odczyt i werdykt „bez_subtaska” w bazie skanera, sprawa nie powstaje, więc usterka „wp-cron.php dostępny z zewnątrz” (waga 1) nie wchodzi do wskaźnika strony.

KodFindingSeverityPewnośćSkutekFinding / alarmWaga → ocenaCo zrobić
B17.01Dostępny wp-cron.phpexposure_wpcronŚredniaEwidentnebez wpływunie / niewaga 1 → ocena 2 (zielony)Ustaw DISABLE_WP_CRON i cron systemowy.
TAB. 3.3B17.01 · Dostępny wp-cron.phpwersja 1 · 01.10.2026
Kod i kluczB17.01 · exposure_wpcron · w tabeli typów
Co znaczywp-cron.php można wywołać z zewnątrz; drobne obciążenie serwera.
Kiedy powstajeGET /wp-cron.php: wystarczy status == 200 (check "200", treść nieistotna).Ocena :209-210. gate=false, więc nie trafia do writera.
Severity · pewnośćŚrednia · Ewidentne
Skutek dla stronybez wpływu · tylko statystyka (gate=false) · alarm nie
Waga → ocenawaga 1 → ocena 2 (zielony)
KlasyfikacjaCWE: CWE-400 (Uncontrolled Resource Consumption)OWASP Top 10:2025: A02:2025 Security MisconfigurationOWASP ASVS 5.0.0: 15.2.2OCSF 1.9.0: Vulnerability Finding (class_uid 2002)
Rekord OCSFfinding_info.analytic.uid = "B17.01" · analytic.name = "exposure_wpcron" · finding_info.types = ["B17 Dostępność wp-cron.php"]
Co zrobićUstaw DISABLE_WP_CRON i cron systemowy.
Wersje typu
  1. v1 · 01.10.2026 — kod B17.01 nadany (finding-codes.ts)
ARK. 4

LOOP

pętli: 2
RYS. 4.1Pętla parametru — sześć etapów
TAB. 4.1Trafność, 30 dnialarmy · prawdziwe · fałszywe · bez rozstrzygnięcia

Trafności jeszcze nie liczymy: zamknięcie subtaska nie niesie dziś werdyktu (prawdziwy / fałszywy / nie dało się sprawdzić). Cztery liczby pojawią się, gdy każde zamknięcie dostanie werdykt — to warunek startu pętli 1.

TAB. 4.2Pętle2 · zmian: 3 · wpływających na cały system: 3
Strażnik losowej ścieżki i dłuższy limit czasu dla sond ekspozycjizamknięta historyczna 2026-09-05

Sygnał: Tarcze antybotowe hostingu, strony parkingowe i serwery catch-all odpowiadają 200 na każdą ścieżkę, więc sondy oparte na kodzie 200 dawały „wystawiony” wszędzie. Równocześnie sondy na wolnych hostingach odpowiadały po około 15 s, a limit 5 s ucinał je bez śladu. · dotyczy też: Ekspozycja .env, Kopie wp-config.php, Ekspozycja .htaccess.bak, Dostępność xmlrpc.php, REST API: enumeracja użytkowników, Ekspozycja .git/HEAD, Dostępność readme.html, Ekspozycja kopii zapasowych, Ekspozycja zrzutu bazy, Ekspozycja manifestów dev, Ekspozycja .DS_Store

  1. 1. Zbiórkaręcznieodczyt z nocnego skanu, bez zapisu per strona
  2. 2. Werdyktręcznieprzegląd skanera: 200 na wszystko i ciche timeouty to fałszywe wyniki
  3. 3. Miarabrakliczników trafności wtedy nie było
  4. 4. Kartabrakkarta parametru powstała 2026-09-16
  5. 5. Zmianazrobionestrażnik ścieżki, 15 s, logowanie błędów
  6. 6. Replaybrakbrak zapisanych odczytów do replayu
DataZmianaPowódWpływ na systemCommit · replay
2026-09-05Przed sondami GET losowej, nieistniejącej ścieżki; odpowiedź 200 z treścią = zero sond i jedno ustalenie exposure_scan_unreliable (niska powaga, bez subtaska).helpers/exposure_check.py · config/incident_policy.tomlOdpowiedź 200 na losową ścieżkę dowodzi, że kod 200 na tym serwerze nic nie znaczy; dalsze sondowanie tarczy grozi banem IP monitoringu.cały system Obejmuje wszystkie sondy ekspozycji naraz i wprowadza typ „nie dało się sprawdzić”; tę samą konwencję dostało wykrywanie wtyczek. Ustalenie ma niską powagę, więc filtr przebiegu je odrzuca i w produkcji nie zostawia śladu.b0fc77cbez replayubez zapisu zatwierdzenia
2026-09-05Limit odpowiedzi z 5 s na 15 s i połączenia z 2 s na 5 s, przeniesione do config.py; błąd sieci sondy logowany zamiast cichego pustego wyniku; do 4 sond naraz na stronę.helpers/config.py · helpers/exposure_check.py · helpers/html_fetch.py · helpers/wp_fingerprint.pyWolne hostingi odpowiadały po około 15 s, a pusty wynik po timeoucie był nieodróżnialny od „sprawdzone, czysto”.cały system Limit połączenia 5 s przejęło wspólne pobieranie HTML całego skanu bezpieczeństwa i wykrywanie wersji — strony z wolnym TLS przestały wypadać z całego skanu.b0fc77cbez replayubez zapisu zatwierdzenia
Limit 64 KB czytanej odpowiedzi po awarii pamięcizamknięta historyczna 2026-07-19

Sygnał: Brak pamięci podczas skanu: publiczny debug.log jednej ze stron był bardzo duży, a klient HTTP buforował całą odpowiedź. · dotyczy też: Sitemap.xml, Kopie wp-config.php, Ekspozycja .env, Ekspozycja .htaccess.bak, Dostępność xmlrpc.php, REST API: enumeracja użytkowników, Ekspozycja .git/HEAD, Dostępność readme.html, Ekspozycja kopii zapasowych, Ekspozycja zrzutu bazy, Ekspozycja manifestów dev, Ekspozycja .DS_Store

  1. 1. Zbiórkaręcznieodczyt z nocnego skanu, bez zapisu per strona
  2. 2. Werdyktręcznieawaria procesu przypisana ścieżce debug.log
  3. 3. Miarabrakliczników trafności wtedy nie było
  4. 4. Kartabrakkarta parametru powstała 2026-09-16
  5. 5. Zmianazrobionestrumień z limitem 64 KB
  6. 6. Replaybrakbrak zapisanych odczytów do replayu
DataZmianaPowódWpływ na systemCommit · replay
2026-07-19Odpowiedź sondy czytana strumieniem do 64 KB; do oceny idzie pierwsze 5000 znaków.helpers/exposure_check.py · helpers/html_fetch.py · helpers/sitemap_check.pyDo rozpoznania ekspozycji wystarcza początek pliku; zmiana dotyczy sposobu czytania, nie werdyktu.cały system Brak pamięci w helperze zatrzymywał cały proces skanu bezpieczeństwa partii stron; ten sam limit dostało sprawdzenie sitemap.343b699bez replayubez zapisu zatwierdzenia
Blog 24/7
05.11CISA i FBI wzywają do zabezpieczenia sterowników chłodzenia po atakach w Europietherecord.media05.11Midnight Blizzard atakowała iPhone'y i Androidy przez zainfekowane strony w Europie i USAsecurityweek.com05.11APT29 kradła dane z iPhone'ów i Androidów przez przejęte i podrobione stronytherecord.media05.11Grupa APT29 przejęła skrypt Plerdy i atakowała niezałatane iPhone'y i Androidythehackernews.com05.11Microsoft wykrył 7,3 mld wiadomości phishingowych w III kwartale 2026microsoft.com05.11DigiCert ujawnia wyciek danych klientów i skanów dokumentów tożsamościbleepingcomputer.com05.11CWPdoor podmienia serwer cwpsrv w Control Web Panel i otwiera tylne wejście do Linuksableepingcomputer.com05.11Brytyjskie NCSC ostrzega, że narzędzia AI zwiększyły liczbę wykrywanych luk zero-daythehackernews.com05.11Skaner RootEvidence sprawdza starą lukę w Cisco IOS i dodaje nagłówki Opt-Outisc.sans.edu05.11Włamanie do portalu grantowego Norad, zagrożone dane 20 614 użytkownikówhelpnetsecurity.com