łatka (patch)

Łatka (patch) to poprawka kodu wydana przez producenta, która usuwa konkretną podatność albo błąd w oprogramowaniu. Słowniki NIST opisują łatkę jako „naprawę” programu, nazywaną też poprawką (fix), dostarczaną jako zamiennik albo uzupełnienie skompilowanego kodu ^[1]. Według innej definicji z tego samego słownika łatka to składnik, który po instalacji zmienia pliki lub ustawienia innego programu bez zmiany jego numeru wersji ^[1]. W praktyce, zwłaszcza w WordPressie, łatki bezpieczeństwa trafiają do użytkowników jako nowe, drobne wersje programu.

Jak działa

Łatka zmienia fragment kodu, w którym tkwi błąd. Producent najpierw dowiaduje się o problemie, na przykład od badacza, potem przygotowuje poprawkę, testuje ją i publikuje, zwykle razem z biuletynem bezpieczeństwa. Od tej chwili ochrona zależy od właściciela systemu, który musi łatkę zainstalować. Do czasu instalacji znana już podatność pozostaje otwarta; w słowniku takie luki nazywa się n-day, w odróżnieniu od zero-day, na które poprawki jeszcze nie ma.

NIST definiuje korporacyjne zarządzanie poprawkami jako proces identyfikowania, priorytetyzacji, pozyskiwania, instalowania i weryfikacji instalacji łatek, aktualizacji i nowych wersji w całej organizacji ^[2]. Ten sam dokument nazywa łatanie elementem konserwacji zapobiegawczej, który pomaga zapobiegać włamaniom, wyciekom danych i przestojom ^[2]. Kolejne etapy tego procesu pokazuje schemat poniżej.

RYS. 1Cykl zarządzania łatkami według NIST SP 800-40

Rodzaje

Łatki różnią się zakresem i sposobem dostarczenia. Tabela zestawia odmiany spotykane na stronach WordPress.

Ostatni wiersz to wirtualne patchowanie: reguła w WAF blokuje żądania wykorzystujące błąd, zanim zostanie zainstalowana właściwa poprawka. Nie usuwa ona przyczyny, tylko zasłania jeden znany sposób ataku.

W WordPressie

WordPress łata trzy warstwy: rdzeń, wtyczki i motywy. Aktualizacja rdzenia WordPressa w wersjach drobnych może odbywać się sama. Automatyczne aktualizacje w tle wprowadzono w WordPressie 3.7, aby poprawić bezpieczeństwo i uprościć aktualizowanie ^[3]. Od wersji 5.6 nowe instalacje otrzymują automatycznie zarówno drobne, jak i duże wydania rdzenia, a starsze instalacje zachowują dotychczasowe zachowanie, czyli tylko wydania drobne i tłumaczenia ^[3]. Stała WP_AUTO_UPDATE_CORE w pliku wp-config.php wybiera zakres aktualizacji, a AUTOMATIC_UPDATER_DISABLED wyłącza je całkowicie ^[3].

Wtyczki i motywy łata się osobno. Od WordPressa 5.5 administrator może włączyć automatyczną aktualizację dla każdej wtyczki i każdego motywu z osobna ^[4]. Domyślnie WordPress uruchamia takie aktualizacje dwa razy dziennie i wysyła właścicielowi e-mail o udanej lub nieudanej próbie ^[4]. Mechanizm opiera się na zadaniach WP-Cron, więc na części serwerów harmonogram może nie działać poprawnie ^[4]. Większość znanych luk dotyczy właśnie dodatków, stąd hasła podatność we wtyczce i podatność w motywie. Szczególnym problemem jest porzucona wtyczka, dla której autor nie wyda już żadnej łatki.

Przykładem łatania rdzenia jest WordPress 7.0.3 z 6 sierpnia 2026 roku. Wydanie usuwało między innymi błędy XSS, eskalację uprawnień w sieciach Multisite i SSRF ^[5]. Poprawki przeniesiono, gdzie było to potrzebne, do wszystkich gałęzi uprawnionych do łatek bezpieczeństwa, wtedy od 4.7 wzwyż ^[5]. Ogłoszenie zapowiadało, że strony z automatycznymi aktualizacjami w tle zaczną się aktualizować wkrótce, i zalecało natychmiastową aktualizację pozostałych ^[5].

Zagrożenia i skutki

Brak łatki oznacza, że strona działa z podatnością opisaną publicznie, na którą może już istnieć exploit. NIST przypomina, że łatanie jako konserwacja zapobiegawcza pomaga zapobiegać włamaniom, wyciekom danych i przestojom ^[2]; każdy dzień zwłoki odsuwa tę ochronę.

Drugim problemem jest koniec wsparcia. Zespół WordPressa podaje, że jedyną aktywnie wspieraną wersją jest najnowsza, a przenoszenie poprawek do starszych gałęzi jest uprzejmością ^[6]. W czerwcu 2025 roku ogłosił, że od lipca 2025 roku wersje 4.1–4.6 nie będą już otrzymywać aktualizacji bezpieczeństwa; według ogłoszenia ponad 99% instalacji używało już nowszych wersji ^[6]. Sekurak, opisując lukę CVE-2026-64638, podał, że gałęzie starsze niż 4.7 również są podatne, ale z braku wsparcia nie otrzymają poprawek ^[7].

Sama łatka też niesie ryzyko: może zmienić zachowanie strony albo kolidować z innym dodatkiem. Dlatego dokumentacja WordPressa zaleca wykonanie kopii strony przed aktualizacją ^[3] i przed włączeniem automatycznych aktualizacji wtyczek ^[4].

Dobre praktyki

• Utrzymywać spis oprogramowania: wersję rdzenia, listę wtyczek i motywów. Bez tego nie da się ustalić, której łatki brakuje.
• Priorytetyzować według wagi i wykorzystania luki, na przykład na podstawie CVSS i wpisu CVE. To element szerszego zarządzania podatnościami.
• Mieć aktualną kopię zapasową i, dla większych zmian, środowisko testowe.
• Pozostawić włączone automatyczne aktualizacje drobnych wydań rdzenia i rozważyć je dla zaufanych wtyczek ^[4].
• Po instalacji sprawdzić, czy wersja faktycznie się zmieniła. NIST uwzględnia weryfikację instalacji jako osobny etap procesu ^[2].
• Usunąć wtyczki i motywy nieużywane oraz porzucone, bo nie dostaną już łatek.

Historia i przykłady

Luka CVE-2026-64638 dobrze pokazuje drogę łatki. Według Sekuraka łańcuch drobnych różnic w parsowaniu HTML, zaczynający się od XSS, mógł dać napastnikowi uprawnienia administratora i wykonanie kodu na serwerze ^[7]. Podatność sklasyfikowano jako CWE-79 i oceniono na 8,9 w CVSS 4.0 ^[7]. Problem naprawiono 6 sierpnia 2026 roku w wersji 7.0.3, a poprawki przeniesiono wstecz aż do gałęzi 4.7 ^[7]. Instancje z automatycznymi aktualizacjami miały otrzymać łatkę samoczynnie ^[7].