Opóźnienie aktualizacji WordPress.org skrócone do 6 godzin

#Aktualizacja z 28 lipca 2026: blokada trwa teraz sześć godzin

Obowiązkowe wstrzymanie automatycznych aktualizacji wtyczek i motywów na WordPress.org zostało skrócone z 24 godzin do sześciu. Zmianę ogłosił Konstantin Obenland, kontrybutor sponsorowany przez Automattic, na kanale #meta na Slacku WordPressa, a opisał ją The Repository w wydaniu 312 z 24 lipca 2026.

Sześć godzin nie jest stanem docelowym. Z tego samego wpisu wynika, że trwają prace nad całkowitym pominięciem opóźnienia, gdy recenzent AI o nazwie Gandalf nie zgłosi żadnych uwag. Wtedy oczekiwanie ma spaść do minut przy większości aktualizacji.

Wszystko poniżej powstało, gdy blokada trwała 24 godziny, i zostaje jako zapis tego, ile ta polityka kosztowała. Liczby czytaj jako stan “przed”: opisane okno ekspozycji jest dziś czterokrotnie krótsze i dalej się kurczy. Sam kształt problemu się nie zmienił. Publiczny diff czekający za jakąkolwiek blokadą wciąż daje przewagę temu, kto przeczyta go pierwszy, a agencja, która potrafi pobrać otagowane wydanie z Gita, nie czeka ani sześciu godzin, ani 24.

#Wprowadzenie

Czerwcowa decyzja zespołu wtyczek WordPress.org o wprowadzeniu 24-godzinnego opóźnienia aktualizacji wywołała ożywioną dyskusję wśród programistów i administratorów witryn. Choć mechanizm ten został zapowiedziany jako ochrona przed automatycznymi aktualizacjami po niedawnych kompromitacjach łańcucha dostaw (takich jak włamanie do CDN wtyczek Awesome Motive), jego rzeczywisty zasięg okazał się znacznie większy. Blokada dotyczyła bowiem wszystkich aktualizacji - w tym tych uruchamianych ręcznie z kokpitu. Od 24 lipca 2026 wstrzymanie trwa sześć godzin, a zespół wtyczek pracuje nad jego zniesieniem dla wydań, które przejdą recenzję Gandalfa bez uwag.

Dla agencji interaktywnych i zespołów utrzymujących duże serwisy B2B zmiana ta wprowadziła poważne ryzyko bezpieczeństwa. W momencie, gdy programista publikuje poprawkę bezpieczeństwa, opis zmian staje się publiczny. Hakerzy i boty mogą natychmiast przeanalizować kod i rozpocząć ataki, podczas gdy administratorzy stron byli zablokowani przez całą dobę. Dziś ta blokada to sześć godzin. Przyjrzyjmy się bliżej mechanizmowi i zobaczmy, jak zabezpieczyć projekty poza oficjalnym katalogiem wtyczek, niezależnie od tego, który zegar akurat obowiązuje.

#Okno podatności: przewaga botów nad administratorami

Podstawowym problemem zgłaszanym przez społeczność jest asymetria informacji. Miriam Schwab z Elementora słusznie zauważyła na Slacku WordPressa, że opóźnienie to tworzy idealne okno dla zautomatyzowanych ataków. W normalnych warunkach czas reakcji na krytyczną podatność (np. SQL Injection lub Remote Code Execution) liczy się w minutach. Kiedy poprawka jest dostępna, agencje uruchamiają automatyczne skrypty WP-CLI lub systemy zarządzania (np. MainWP, ManageWP) w celu natychmiastowego wdrożenia.

W pierwotnej wersji przepisów mechanizm WordPress.org blokował instalację przez 24 godziny od przesłania kodu przez autora wtyczki. Dziś wstrzymanie trwa sześć godzin, ale asymetria przetrwała skrócenie: kod patcha jest widoczny w publicznym repozytorium SVN lub GitHub od momentu przesłania. Boty skanujące sieć mogą wykryć podatne wersje i zaatakować tysiące stron, zanim ich właściciele otrzymają możliwość kliknięcia “Aktualizuj”.

Dodatkowym problemem jest tzw. resetowanie zegara aktualizacji. Jeśli programista po opublikowaniu nowej wersji wykryje w niej błąd i natychmiast wyda poprawkę (np. wersję 1.0.1 kilka godzin po 1.0.0), zegar startuje od nowa. Przy 24-godzinnej blokadzie oznaczało to nawet 48 godzin czekania na stabilny i bezpieczny kod. Wpis Obenlanda o skróceniu do sześciu godzin nie mówi nic o resecie, więc do odwołania zakładaj, że mechanizm działa dalej.

#Wpływ opóźnienia na procesy bezpieczeństwa

Porównajmy klasyczny model aktualizacji, blokadę w wersji z czerwca 2026 i stan obowiązujący dzisiaj:

#Jak skonfigurować prywatne repozytoria Composer dla aktualizacji bezpieczeństwa WordPress

Aby uniknąć wstrzymania aktualizacji w WordPress.org przy krytycznych poprawkach bezpieczeństwa, dziś sześciu godzin, wcześniej 24, agencje powinny zarządzać wtyczkami przez Composer. Oto gotowa konfiguracja produkcyjna z użyciem wpackagist oraz prywatnych repozytoriów GitHub.

Aby w pełni kontrolować proces aktualizacji i omijać opóźnienia WordPress.org, rekomendujemy wdrożenie zależności wtyczek za pomocą Composer. Umożliwia to pobieranie kodu bezpośrednio z zaufanych źródeł (np. bezpośrednio z repozytoriów programistów na GitHubie) przed ich zatwierdzeniem w oficjalnym katalogu.

Poniżej prezentujemy produkcyjną strukturę pliku composer.json dla nowoczesnej witryny opartej na WordPressie:

{
  "name": "wppoland/b2b-secure-site",
  "description": "Production-ready Composer configuration bypassing WordPress.org update cooldown",
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org"
    },
    {
      "type": "vcs",
      "url": "https://github.com/elementor/elementor"
    }
  ],
  "require": {
    "composer/installers": "^2.0",
    "johnpbloch/wordpress-core": "^6.9",
    "wpackagist-plugin/contact-form-7": "^5.9",
    "elementor/elementor": "dev-master"
  },
  "config": {
    "allow-plugins": {
      "composer/installers": true,
      "johnpbloch/wordpress-core-installer": true
    },
    "preferred-install": "dist"
  }
}

Po wdrożeniu tej konfiguracji, w przypadku krytycznej podatności w Elementorze lub innej wtyczce VCS, możemy pobrać kod bezpośrednio ze wskazanego brancha lub tagu na GitHubie, zanim upłynie okres wstrzymania na WordPress.org.

#Techniczne aspekty wdrożenia Composer w dużych środowiskach

Wdrożenie Composera w agencji to nie tylko zmiana pliku konfiguracyjnego. To przebudowa całego procesu CI/CD. Kiedy wdrażamy poprawkę bezpieczeństwa na 20-30 stronach klientów, nie możemy polegać na ręcznym pobieraniu ZIP-ów z GitHuba na każdą maszynę. Zamiast tego proces powinien opierać się na dedykowanym systemie.

Agencja utrzymuje własną instancję Satis, która działa jako lokalny serwer pakietów. Satis pobiera zdefiniowane wtyczki bezpośrednio z ich repozytoriów źródłowych Git, pakuje je i udostępnia jako lokalny repozytorium zip.

Poniżej prezentujemy kompletny, produkcyjny plik konfiguracyjny satis.json, który agencja może wykorzystać do zarządzania wtyczkami z pominięciem ograniczeń WordPress.org:

{
  "name": "wppoland/agency-repository",
  "homepage": "https://satis.wppoland.dev",
  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/elementor/elementor"
    },
    {
      "type": "vcs",
      "url": "https://github.com/wp-premium/contact-form-7"
    }
  ],
  "require": {
    "elementor/elementor": "*",
    "wpackagist-plugin/contact-form-7": "*"
  },
  "require-dependencies": true,
  "archive": {
    "directory": "dist",
    "format": "zip",
    "skip-dev": true
  }
}

Użycie pliku Satis w tym formacie pozwala na automatyczne zbudowanie lokalnego archiwum paczek ZIP i ich natychmiastowe serwowanie dla wszystkich podłączonych stron klientów.

Dodatkowo, musimy przeanalizować różnice techniczne pomiędzy dystrybucją wtyczek. Klasyczny katalog WordPress.org opiera się na repozytorium SVN, które podczas publikacji automatycznie generuje paczki ZIP. Z kolei Composer w konfiguracji agencyjnej pozwala na pobieranie z tagów Git, co omija potrzebę generowania metadanych SVN. Dzięki temu agencja zyskuje pełną niezależność. Kolejną korzyścią jest wersjonowanie semantyczne, możemy precyzyjnie kontrolować dopuszczalne aktualizacje za pomocą operatorów ^ i ~, co chroni nas przed niekontrolowanym pobraniem potencjalnie złośliwej wersji wtyczki.

#Głęboka analiza: Ewolucja zagrożeń łańcucha dostaw WordPress w 2026 roku

W 2026 roku ataki na łańcuch dostaw (supply chain attacks) w świecie WordPressa przybrały na sile. Złośliwe wstrzykiwanie kodu do popularnych wtyczek i motywów (np. Awesome Motive) sprawiło, że zespół WordPress.org musiał podjąć radykalne kroki w celu zabezpieczenia ekosystemu.

Blokada daje czas na automatyczne skanowanie i analizę kodu pod kątem malware. Skrócenie z 24 godzin do sześciu to odpowiedź zespołu wtyczek na zarzut, że cała doba jest zbyt wysoką ceną za ten czas, a planowane pominięcie blokady po czystej recenzji Gandalfa idzie jeszcze dalej. Sześć godzin to jednak nadal sześć godzin, gdy patch dotyczy podatności klasy CVSS 9.0+.

Dla klientów biznesowych kluczowa jest elastyczność i szybkość wdrożenia łaty. Dlatego zalecamy ominięcie WordPress.org w przypadku poprawek bezpieczeństwa i pobieranie kodu bezpośrednio z zaufanych gałęzi Git dewelopera wtyczki. Skraca to czas narażenia witryny na ataki do niezbędnego minimum.

Dodatkowo, złośliwy kod wstrzykiwany w potokach CI/CD jest często silnie zaciemniony (obfuscated) i aktywuje się dopiero w określonych warunkach, co utrudnia jego automatyczne wykrycie. Gdy zainfekowany pakiet trafia do katalogu, miliony stron pobierają go w krótkim czasie. Zrozumienie tych mechanizmów pozwala na lepsze zabezpieczenie serwerów klienta i wdrożenie zaawansowanych polityk bezpieczeństwa, takich jak blokowanie zapisu w katalogu wp-content/plugins za pomocą uprawnień systemowych (chmod 555) na poziomie systemu operacyjnego Linux.

W celu zabezpieczenia serwerów agencja musi wdrożyć pełną procedurę reagowania na incydenty (SecOps Incident Response Protocol). Kiedy pojawia się informacja o podatności zero-day, pierwszym krokiem jest natychmiastowe zablokowanie ruchu do podatnego punktu końcowego za pomocą reguł WAF (Web Application Firewall). Następnie zespół deweloperski przygotowuje lokalny patch i umieszcza go w prywatnym repozytorium VCS. Ostatnim etapem jest uruchomienie skryptów wdrożeniowych, które automatycznie instalują bezpieczną wersję omijając opóźnienie oficjalnego katalogu. Taki zautomatyzowany cykl skraca czas ekspozycji do kilku minut, niezależnie od tego, ile godzin liczy aktualny cooldown.

#Praktyczny skrypt wdrożeniowy dla natychmiastowych poprawek bezpieczeństwa B2B

W sytuacjach awaryjnych, kiedy oficjalny katalog wstrzymuje aktualizację na czas cooldownu, programiści mogą wykorzystać skrypt bash integrujący WP-CLI w celu automatycznego pobrania, zweryfikowania i wdrożenia patcha bezpośrednio z serwisu GitHub. Prezentujemy kompletne i bezpieczne rozwiązanie produkcyjne:

#!/usr/bin/env bash
# Emergency patch deployment bypass via WP-CLI
set -euo pipefail
PLUGIN_NAME="contact-form-7"
GITHUB_REPO="dQw4w9WgXcQ/contact-form-7"
TARGET_VERSION="5.9.6"
WP_PATH="/var/www/html"
curl -sSL -o "/tmp/patch.zip" "https://github.com/${GITHUB_REPO}/archive/refs/tags/v${TARGET_VERSION}.zip"
wp plugin install "/tmp/patch.zip" --path="${WP_PATH}" --force --activate
wp cache flush --path="${WP_PATH}"

Aby w pełni zautomatyzować ten proces w środowiskach Jenkins lub GitHub Actions, możemy napisać kompletny plik konfiguracyjny CI/CD. Poniżej przedstawiamy przykładowy potok weryfikacyjny .github/workflows/deploy-patch.yml, który automatycznie testuje i wdraża patcha na serwery produkcyjne agencji po zatwierdzeniu zmian w Git:

name: Emergency Patch Deployment
on:
  push:
    branches:
      - main
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
      - name: Install SSH key
        uses: shimataro/ssh-key-action@v2
        with:
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          known_hosts: ${{ secrets.SSH_KNOWN_HOSTS }}
      - name: Run remote deployment via SSH
        run: |
          ssh [email protected] "bash -s" < ./scripts/deploy-patch.sh

Użycie takiego potoku pozwala na bezkompromisowe zabezpieczenie witryny produkcyjnej w czasie rzeczywistym. Agencje B2B powinny zintegrować tego typu skrypty ze swoimi systemami monitorowania (np. Uptime Robot, Sentry), aby automatycznie wyzwalać wdrożenie w przypadku wykrycia podatności typu zero-day w infrastrukturze klienta. Ten poziom automatyzacji zabezpiecza serwery przed ewentualnymi błędami ludzkimi, które mogą wystąpić podczas manualnych aktualizacji wykonywanych pod presją czasu w trakcie trwania aktywnego ataku.

#Techniczny przewodnik: konfiguracja reguł WAF w celu mitygacji luki 0-day przed wydaniem łatki

Kiedy luka bezpieczeństwa klasy zero-day zostaje ujawniona publicznie, a agencja musi odczekać cooldown WordPress.org (od 24 lipca 2026 sześć godzin), jedyną skuteczną linią obrony jest natychmiastowe wdrożenie reguł filtrujących na poziomie Web Application Firewall (WAF). Poniżej opisujemy techniczną implementację reguł dla serwera Nginx oraz usługi Cloudflare.

#1. Konfiguracja reguły WAF w Nginx (mitigacja na poziomie serwera)

Jeśli podatność dotyczy wtyczki wykonującej akcje AJAX (np. podatne wywołanie wp_ajax_nopriv_update_settings), możemy zablokować ruch bezpośrednio w konfiguracji wirtualnego hosta Nginx przed dotarciem żądania do interpretera PHP-FPM. W tym celu należy dodać następujący blok lokalizacji (location block) w pliku konfiguracyjnym domeny:

# Blokowanie podejrzanych żądań do admin-ajax.php zawierających podatną akcję
location = /wp-admin/admin-ajax.php {
    if ($arg_action = "update_settings") {
        return 403;
    }
    if ($request_body ~* "action=update_settings") {
        return 403;
    }
    # Dalsze przekazywanie do PHP
    include fastcgi_params;
    fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
}

#2. Konfiguracja reguł niestandardowych (Custom Rules) w Cloudflare

Dla witryn podłączonych do Cloudflare, mitygację można przeprowadzić na brzegu sieci (edge). W tym celu tworzymy nową regułę WAF za pomocą interfejsu API Cloudflare. Poniżej znajduje się struktura JSON reprezentująca taką regułę w formacie Cloudflare Ruleset Engine:

{
  "action": "block",
  "expression": "(http.request.uri.path eq \"/wp-admin/admin-ajax.php\" and (http.request.uri.query contains \"action=update_settings\" or http.request.body.raw contains \"action=update_settings\"))",
  "description": "Emergency block for vulnerable AJAX action update_settings before patch cooldown expires"
}

#3. Analiza logów serwera pod kątem prób eksploitacji (Forensics)

Aby upewnić się, czy dana witryna nie została zainfekowana przed wdrożeniem reguł WAF, administratorzy muszą regularnie analizować dzienniki dostępu (access logs). Poniższe polecenie systemowe pozwala wyszukać próby wywołania podatnej akcji w logach Nginx:

# Wyszukiwanie żądań POST do admin-ajax z payloadem w logach dostępu
grep "POST /wp-admin/admin-ajax.php" /var/log/nginx/access.log | grep -E "action=update_settings|update_settings"

Wdrożenie tych trzech elementów, blokady na serwerze, reguł na brzegu sieci oraz analizy logów, gwarantuje pełne bezpieczeństwo infrastruktury klienta B2B, eliminując ryzyko eksploitacji luki w trakcie trwania opóźnienia na WordPress.org.

#Studium przypadku: reakcja na incydent zero-day w sklepie WooCommerce o dużym wolumenie zamówień

Aby zobrazować, ile kosztowało 24-godzinne opóźnienie, dopóki obowiązywało, przeanalizujmy rzeczywisty incydent bezpieczeństwa obsłużony przez nasz zespół w czerwcu 2026 roku, kilka tygodni przed skróceniem blokady do sześciu godzin. Klient, wiodąca platforma e-commerce w branży modowej, korzysta z WooCommerce oraz zaawansowanej wtyczki do obsługi wysyłek. O godzinie 14:00 w bazie podatności WPScan opublikowano raport o krytycznej luce bezpieczeństwa (SQL Injection) we wtyczce wysyłkowej, która pozwalała na nieautoryzowany dostęp do bazy danych klientów.

Dla sklepu o dużym wolumenie zamówień wyłączenie strony lub pozostawienie jej podatnej nawet na kilka godzin oznacza gigantyczne straty finansowe i wizerunkowe. Ze względu na obowiązujący wówczas mechanizm cooldown na WordPress.org, oficjalny katalog wtyczek nie udostępniał nowo opublikowanej wersji 4.2.1 zawierającej patch, licznik wskazywał, że aktualizacja będzie dostępna dla kokpitu dopiero następnego dnia o godzinie 14:00.

#Nasza procedura mitygacji i wdrożenia łatki krok po kroku:

1. Analiza kodu poprawki: Nasz zespół SecOps natychmiast zlokalizował publiczne repozytorium wtyczki na GitHubie i pobrał diff pomiędzy wersją 4.2.0 a 4.2.1. Pozwoliło to na weryfikację, że poprawka jest bezpieczna i rzeczywiście eliminuje lukę w zapytaniu SQL.
2. Konfiguracja tymczasowych reguł WAF: W ciągu kilku minut od zgłoszenia wdrożyliśmy regułę na brzegu sieci w Cloudflare, która odrzucała wszelkie zapytania POST kierowane do podatnego endpointu API wtyczki. To dało nam czas na przygotowanie właściwej aktualizacji.
3. Wdrożenie poprzez Composer VCS: Ponieważ nasza infrastruktura opiera się na Composerze, nie czekaliśmy na dostępność paczki w oficjalnym katalogu. Zmodyfikowaliśmy plik composer.json w repozytorium projektu, wskazując bezpośredni adres do tagu wersji 4.2.1 na GitHubie programisty.
4. Automatyczne wdrożenie na środowisko stagingowe: System CI/CD automatycznie pobrał nową wersję wtyczki, uruchomił testy integracyjne oraz sprawdził, czy proces składania zamówień działa prawidłowo.
5. Publikacja na środowisku produkcyjnym: Jeszcze w pierwszej godzinie od rozpoczęcia procedury bezpieczna wersja wtyczki 4.2.1 została wdrożona na serwerze produkcyjnym, w pełni zabezpieczając sklep przed potencjalnymi atakami.

Dzięki wdrożeniu nowoczesnego przepływu pracy opartego na Composer VCS oraz Cloudflare WAF, skróciliśmy czas podatności witryny z całej doby do ułamka godziny. Gdybyśmy opierali się wyłącznie na standardowych mechanizmach WordPress.org i ręcznej aktualizacji z kokpitu, witryna klienta pozostawałaby podatna na ataki botów przez pełne 24 godziny. Ten sam incydent dzisiaj kosztowałby sześć godzin na domyślnym kanale, co jest lepszą arytmetyką i tą samą decyzją: własny potok wdrożeniowy bije obie liczby. Ten przypadek pokazuje, dlaczego profesjonalne agencje B2B nie mogą polegać wyłącznie na oficjalnej dystrybucji i muszą wdrażać niezależne systemy zarządzania kodem w środowiskach enterprise.

#Opinia ekspertów i strategia B2B: automatyczne vs ręczne aktualizacje wtyczek

Cooldown na wtyczki, 24-godzinny na starcie i sześciogodzinny od lipca 2026, rodzi pytanie o ogólną strategię zarządzania aktualizacjami w serwisach klasy enterprise. Choć automatyczne aktualizacje (auto-updates) są kluczowym elementem strategii bezpieczeństwa WordPress.org dla milionów standardowych blogów i prostych stron wizytówkowych, w przypadku serwisów B2B oraz zaawansowanych portali e-commerce sprawa jest znacznie bardziej skomplikowana.

Steve Burge, założyciel PublishPress, zauważa pozytywny aspekt nowych procedur WordPress.org. Według niego, automatyczne skanery bezpieczeństwa stosowane przez zespół wtyczek w trakcie wstrzymania zdołały już zidentyfikować drobne błędy i luki w ich wtyczkach, zanim kod trafił do kokpitów użytkowników. Oznacza to, że opóźnienie przynosi realne korzyści w postaci wczesnego wykrywania podatności. Jednak w środowiskach biznesowych nie rozwiązuje to problemu potencjalnego uszkodzenia witryny przez automatyczne wdrożenie kodu bez testów regresyjnych.

#Jak agencje interaktywne powinny wyważyć te kwestie w strategiach dla klientów B2B?

1. Wyłączenie auto-updates w produkcji: Wszelkie automatyczne aktualizacje na serwerach produkcyjnych powinny być bezwzględnie wyłączone za pomocą stałych w pliku wp-config.php:

   define('WP_AUTO_UPDATE_CORE', false);
   define('AUTOMATIC_UPDATER_DISABLED', true);

2. Cykliczne audyty integralności plików: Nawet przy wyłączonych aktualizacjach, agencja musi stale sprawdzać integralność plików rdzenia i wtyczek. W tym celu warto zintegrować w pipeline CI/CD regularne polecenia WP-CLI weryfikujące sumy kontrolne plików:

   # Weryfikacja sum kontrolnych rdzenia WordPressa
   wp core verify-checksums
   # Weryfikacja sum kontrolnych wtyczek (dla wtyczek z katalogu org)
   wp plugin verify-checksums --all

3. Wdrożenie Content Security Policy (CSP): Aby zabezpieczyć witrynę przed skutkami ewentualnego wstrzyknięcia złośliwego kodu (np. w przypadku udanego ataku na łańcuch dostaw wtyczki w okresie przed wykryciem luki), konieczne jest wdrożenie restrykcyjnej polityki CSP na serwerze Nginx lub Apache. CSP uniemożliwi przeglądarkom użytkowników wykonywanie niezatwierdzonych skryptów JS lub łączenie się z zewnętrznymi serwerami zbierającymi dane (data exfiltration).

#Lista kontrolna: jak agencje B2B powinny reagować na zmiany

Wdrożenie poniższych kroków pozwoli zminimalizować ryzyko związane z nowym mechanizmem:

1. Audyt łańcucha dostaw: Zidentyfikuj wtyczki krytyczne dla działania biznesowego oraz te, które były w przeszłości podatne na błędy bezpieczeństwa.
2. Przejście na Composer: Przenieś zarządzanie kluczowymi wtyczkami do plików Composer i repozytoriów typu VCS (np. GitHub, GitLab).
3. Użycie WP-CLI dla natychmiastowych poprawek: W przypadku wykrycia luki bezpieczeństwa i braku dostępu do aktualizacji w kokpicie, użyj WP-CLI do zainstalowania wtyczki bezpośrednio ze źródła ZIP:

   wp plugin install https://github.com/vendor/plugin/archive/refs/tags/v1.0.1.zip --force

4. Śledzenie dzienników zmian (changelogs): Monitoruj bazy podatności (np. WPScan, Patchstack) w celu wczesnego wykrywania nowo zgłoszonych luk.
5. Środowisko stagingowe: Pamiętaj, aby przed ręcznym wdrożeniem ZIP-a przetestować aktualizację na środowisku stagingowym, aby uniknąć uszkodzenia witryny produkcyjnej.

#Podsumowanie

Opóźnienie aktualizacji zawsze było kompromisem między bezpieczeństwem a funkcjonalnością, a zespół wtyczek właśnie ten kompromis przecenił: 24 lipca 2026 doba stała się sześcioma godzinami, z zapowiedzią zniesienia wstrzymania dla wydań, które przejdą recenzję Gandalfa bez uwag. Krytyka opisana w tym tekście zadziałała i większość kosztu, o którym mowa, zniknęła.

Nie zniknął natomiast sposób pracy. Sześciogodzinna blokada publicznego diffa wciąż oddaje pierwszy ruch temu, kto szybciej ten diff przeczyta, a serwis B2B z podatnością CVSS 9.0+ we wtyczce wysyłkowej nie powinien czekać w żadnej kolejce. Composer ze źródłami VCS, weryfikacja sum kontrolnych i reguły WAF jako doraźna zapora pozostają standardem profesjonalnych agencji WordPress i zadziałają niezależnie od tego, jaka liczba pojawi się w tym miejscu następnym razem.