| Nazwa wtyczki | Dolny pasek |
|---|---|
| Rodzaj podatności | Podrabianie żądań między witrynami (CSRF) |
| Numer CVE | CVE-2026-6401 |
| Pilność | Niski |
| Data publikacji CVE | 2026-05-20 |
| Adres URL źródła | CVE-2026-6401 |
Fałszywe żądanie między witrynami (CSRF) w wtyczce Dolny pasek WordPress (CVE-2026-6401) — co to oznacza i jak to złagodzić
Autor: Zespół ds. bezpieczeństwa WP‑Firewall
Tagi: WordPress, Bezpieczeństwo, WAF, CSRF, Luka, Reakcja na incydenty
Kanoniczny URL: https://my.wp-firewall.com/blog/csrf-bottom-bar-cve-2026-6401
Krótko mówiąc
Niedawno ujawniona luka (CVE-2026-6401) dotyczy wtyczki WordPress “Dolny pasek” w wersjach do 0.1.7 włącznie. Problem to luka typu Cross-Site Request Forgery (CSRF), która pozwala atakującemu oszukać uwierzytelnionego użytkownika — zazwyczaj kogoś z dostępem do ustawień wtyczki — do przesłania spreparowanego żądania, które aktualizuje ustawienia wtyczki bez intencji użytkownika.
Uderzenie: Niska do umiarkowanej na powierzchni (zmiany w konfiguracji), ale może być połączona z innymi problemami, aby zwiększyć ryzyko. Wykorzystanie wymaga interakcji użytkownika: uwierzytelnowany administrator (lub użytkownik z wystarczającymi uprawnieniami) musi odwiedzić spreparowaną stronę lub kliknąć link.
Działania natychmiastowe: Zaktualizuj wtyczkę, gdy dostępna jest poprawka wydawcy, lub zastosuj wirtualne poprawki / zasady WAF i wzmocnij teraz swój obszar administracyjny. Jeśli korzystasz z zarządzanego WAF, wprowadź zasady blokujące podejrzane POST-y do punktów końcowych wtyczki i zweryfikuj kontrole uprawnień wewnątrz obsługi wtyczki.
Poniżej wyjaśniamy szczegóły techniczne, realistyczne scenariusze ataków, wskazówki dotyczące wykrywania i polowania, dokładne środki łagodzące, które możesz zastosować (w tym zasady WAF i wzmocnienie WordPressa), oraz listę kontrolną reakcji na incydenty.
Tło i podsumowanie techniczne
- Luka: Fałszywe żądanie między witrynami (CSRF)
- Oprogramowanie dotknięte: wtyczka WordPress “Dolny pasek”
- Dotyczy wersji: <= 0.1.7
- Identyfikator: CVE-2026-6401
- Ujawnienie: publiczny raport (19 maja 2026)
- Przyczyna źródłowa (typowa): punkt końcowy aktualizacji ustawień nie weryfikuje nonce WordPressa / check_admin_referer i/lub nie waliduje uprawnień bieżącego użytkownika przed zaakceptowaniem zmian.
Co oznacza CSRF dla punktu końcowego ustawień WordPressa:
- Złośliwa strona może stworzyć formularz lub skrypt, który powoduje, że przeglądarka zalogowanego administratora przesyła żądanie POST do witryny WordPress.
- Jeśli obsługa ustawień wtyczki nie ma weryfikacji nonce i kontroli uprawnień, to POST jest przetwarzane tak, jakby administrator celowo zmienił ustawienia.
- Atakujący mogą w ten sposób zmieniać wartości konfiguracyjne (na przykład, adresy URL przekierowań, odniesienia do zewnętrznych zasobów lub włączanie funkcji), które mogą być użyte do dalszego kompromitowania witryny (phishing, wstrzykiwanie zewnętrznych ładunków lub włączanie niebezpiecznego zachowania).
Notatka: CSRF sam w sobie nie daje atakującemu nowych poświadczeń uwierzytelniających — nadużywa aktywnej sesji ofiary. Poziom szkód zależy od tego, jakie ustawienia wtyczka ujawnia i co te ustawienia kontrolują.
Realistyczne scenariusze ataków
- Zmień adres URL przekierowania na stronę phishingową
Atakujący aktualizuje przycisk lub cel linku dolnego paska na zewnętrzną domenę phishingową. Odwiedzający stronę, klikając dolny pasek, są kierowani na stronę atakującego. - Włącz opcję, która ujawnia dane
Jeśli wtyczka ma opcję, która zmienia widoczność lub zbiera dodatkowe informacje, atakujący może ją przełączyć, ujawniając wrażliwe dane lub umożliwiając atak drugiego etapu. - Łańcuch z przechowywanym XSS lub zdalnym dołączeniem
Zmiana ustawień może wskazywać na zewnętrzny arkusz stylów lub skrypt. Jeśli strona później załadowuje ten złośliwy zasób, może to prowadzić do przechowywanego skryptowania międzywitrynowego lub dalszego wykonywania JavaScript w przeglądarkach odwiedzających. - Inżynieria społeczna przeciwko uprzywilejowanym użytkownikom
Atakujący wabi administratora na spreparowaną stronę internetową (e-mail, czat lub inżynieria społeczna), przeglądarka administratora wykonuje sfałszowane żądanie, a ustawienia strony są zmieniane.
Ponieważ wykorzystanie wymaga interakcji uwierzytelnionego użytkownika, ta luka jest mniej użyteczna dla szerokich, ślepych masowych kompromisów niż błąd zdalnego wykonania kodu — ale nadal jest niebezpieczna i wykorzystywana w ukierunkowanych kompromisach i łańcuchach pivot.
Jak my w WP‑Firewall oceniamy ryzyko
Jako zapora aplikacji internetowej WordPress i dostawca bezpieczeństwa, oceniamy ten problem jako niski do umiarkowanego, gdy jest izolowany. Powód:
- CSRF wymaga interakcji użytkownika (administrator musi być zalogowany i kliknąć/odwiedzić).
- Bezpośrednie skutki to zazwyczaj zmiany konfiguracji (nie natychmiastowe wykonanie kodu).
- Jednak zmiany konfiguracji mogą być wykorzystane do większych ataków (phishing, ładowanie XSS lub wyłączanie funkcji zabezpieczeń).
Dla każdej strony z wieloma administratorami lub tam, gdzie administratorzy są często celem (klienci agencji, blogi z wieloma autorami, zaplecza e-commerce), nawet “niskie” luki są ważne do szybkiego złagodzenia.
Wykrywanie i polowanie: wskaźniki, na które należy zwrócić uwagę
-
Audytuj logi administratora i logi serwera WWW w poszukiwaniu nieoczekiwanych żądań POST do punktów końcowych administratora:
- Szukaj POST-ów do adresów URL, które należą do punktów końcowych ustawień wtyczki (na przykład, żądania do
admin-post.php,options.php,admin.php?page=bottom-bar, lub innych punktów końcowych akcji specyficznych dla wtyczki) w czasie, gdy administrator zgłosił zmianę. - Sprawdź nietypowe nagłówki referer (zewnętrzne referery), które pokrywają się ze zmianami konfiguracji.
- Szukaj POST-ów do adresów URL, które należą do punktów końcowych ustawień wtyczki (na przykład, żądania do
-
Logi aktywności WordPressa:
- Jeśli prowadzisz rejestrator aktywności, przeszukaj zmiany w opcjach konfiguracji wtyczki, szczególnie klucze, które kontrolują adresy URL, flagi włącz/wyłącz lub pola treści.
-
Wskaźniki plików/systemu:
- Wartości konfiguracyjne niespodziewanie zmieniły się w bazie danych (
opcje_wptabelę). - Nowe zewnętrzne adresy URL załadowane na froncie (sprawdź źródło strony pod kątem podejrzanych hostów).
- Wartości konfiguracyjne niespodziewanie zmieniły się w bazie danych (
-
Anomalie sesji użytkowników:
- Sesje administratorów aktywne z nietypowych adresów IP lub agentów użytkowników w czasach odpowiadających modyfikacjom ustawień.
Przykład WP‑CLI do sprawdzenia kluczy opcji związanych z wtyczką (dostosuj option_name do znanych kluczy wtyczki):
wp db query "SELECT option_name, option_value FROM wp_options WHERE option_name LIKE '%bottom_bar%';"Szukaj ostatnich zmian (jeśli Twoja baza danych ma dzienniki binarne lub znaczniki czasu za pomocą wtyczki do logowania). Jeśli prowadzisz dziennik zmian na stronie, sprawdź go.
Natychmiastowe kroki łagodzące (co zrobić teraz)
Jeśli prowadzisz lub zarządzasz stroną WordPress, która używa wtyczki Bottom Bar (<= 0.1.7), oto priorytetowa lista kontrolna:
-
Poprawka
Najlepszym rozwiązaniem jest zaktualizowanie wtyczki, gdy tylko dostawca wyda poprawkę, która wdraża kontrole nonce i uprawnień. Monitoruj stronę wtyczki w poszukiwaniu zaktualizowanej wersji. -
Jeśli poprawka nie jest dostępna, tymczasowo wyłącz wtyczkę
Dezaktywuj wtyczkę Bottom Bar, aż będzie dostępna bezpieczna aktualizacja. To najbezpieczniejsze krótkoterminowe rozwiązanie. -
Jeśli wyłączenie nie jest możliwe, ogranicz dostęp do obszaru ustawień wtyczki
Ogranicz dostęp dowp-admindo znanych adresów IP za pomocą kontroli dostępu na serwerze (białe listy IP).
Użyj podstawowej autoryzacji HTTP dla całego obszaru administracyjnego (tylko podczas stosowania innych środków zaradczych). -
Wirtualna poprawka z regułami WAF
Użyj swojego WAF do tworzenia reguł, które blokują podejrzane żądania POST do punktów końcowych związanych z wtyczką, jak opisano w następnej sekcji. -
Wymuszaj ponowną autoryzację przy wrażliwych zmianach
Wymagaj od administratorów ponownej autoryzacji przy działaniach aktualizacji wtyczki (WordPress ma mechanizmy takie jakreautoryzuj()dla działań wysokiego ryzyka). -
Rotuj dane logowania administratora i tokeny, jeśli wykryjesz podejrzaną aktywność
Jeśli zauważysz nieautoryzowane zmiany, wymuś resetowanie haseł dla użytkowników administratora i rotuj wszelkie klucze API. -
Audyt i skanowanie
Przeprowadź pełne skanowanie złośliwego oprogramowania i audyt bezpieczeństwa (skanowanie plików wtyczek/tematów, zaplanowane zadania,opcje_wptreść).
Zachowaj kopie zapasowe przed krokami naprawczymi.
Sugerowane zasady WAF (wirtualne poprawki) — praktyczne przykłady
Poniżej znajdują się przykładowe podejścia, które możesz wykorzystać w swojej zaporze aplikacji internetowej (ModSecurity, NGINX + Lua lub zarządzany panel WAF). To są ogólne wzorce — dostosuj nazwy plików, parametry i nazwy akcji, aby pasowały do rzeczywistych punktów końcowych wtyczki.
Ważny: Zasady WAF powinny być testowane w trybie blokowania w środowisku testowym przed włączeniem w produkcji, aby uniknąć fałszywych pozytywów.
1) Zablokuj POST-y do punktu końcowego administracji wtyczki z zewnętrznych refererów
SecRule REQUEST_METHOD "POST" "chain,phase:2,deny,status:403,id:100001,log,msg:'Zablokuj podejrzany POST do ustawień Bottom Bar bez ważnego wewnętrznego referera'"
Wyjaśnienie:
- Zablokuj POST-y do wspólnych punktów końcowych administracji, jeśli HTTP Referer nie zaczyna się od hosta Twojej witryny. To blokuje próby CSRF pochodzące z zewnętrznych stron.
- Uwaga: Niektóre legalne narzędzia mogą wysyłać POST-y z pustymi refererami; połącz z innymi kontrolami.
2) Zablokuj żądania z parametrem akcji wtyczki używanym w aktualizacjach ustawień
SecRule ARGS_GET:action "bottom_bar_update_settings" "chain,phase:2,deny,status:403,id:100002,msg:'Zablokuj akcję ustawień bottom_bar z zewnętrznego referera'"
3) Wymagaj obecności nagłówka lub parametru WordPress Nonce (heurystycznie)
SecRule REQUEST_METHOD "POST" "chain,phase:2,deny,status:403,id:100003,msg:'Zablokuj POST brakujący X-WP-Nonce lub wewnętrzny referer dla punktów końcowych administracji'"
4) Przykład NGINX używający walidacji referera (koncepcyjnie)
location ~* /wp-admin/(admin-post\.php|admin\.php) {
Zastrzeżenia:
- Nagłówek Referer może być tłumiony przez niektóre przeglądarki lub ustawienia prywatności; ta zasada może blokować legalny ruch (używaj tymczasowo).
- Zawsze testuj.
Wskazówki dla dewelopera / autora wtyczki — jak naprawić w kodzie
Jeśli jesteś autorem wtyczki lub możesz przesłać PR, wdroż te standardowe zabezpieczenia WordPress w każdym obsługiwaczu formularzy, który aktualizuje ustawienia:
-
Użyj nonce
Dodaj pole nonce do swojego formularza ustawień:<?php wp_nonce_field( 'bottom_bar_settings_update', 'bottom_bar_nonce' ); ?>Zweryfikuj w obsługiwaczu POST:
if ( ! isset( $_POST['bottom_bar_nonce'] ) || ! wp_verify_nonce( $_POST['bottom_bar_nonce'], 'bottom_bar_settings_update' ) ) { -
Sprawdź uprawnienia
Zawsze upewnij się, że użytkownik ma odpowiednie uprawnienia przed zmianą ustawień:if ( ! current_user_can( 'manage_options' ) ) { -
Użyj API ustawień
Rejestruj i waliduj opcje za pomocą API Ustawień:register_setting()zsanitize_callback. -
Oczyść i zwaliduj dane wejściowe
Używaćdezynfekuj_pole_tekstowe(),esc_url_raw(),intval(), oraz niestandardowe walidatory. -
Używać
check_admin_referer()dla wygody, jeśli to możliwe:check_admin_referer( 'aktualizacja_ustawień_dolnego_paska', 'dolny_pasek_nonce' ); -
Unikaj przetwarzania żądań GET dla działań zmieniających stan
Używaj POST wyłącznie do aktualizacji, a także stosuj nonce i kontrole uprawnień.
Wdrożenie tych poprawek wyeliminuje narażenie na CSRF na końcówce ustawień.
Techniki wzmacniania w celu zmniejszenia ryzyka CSRF i pokrewnych
- Wymuś ciasteczka SameSite: ustaw
SESJA_CIASTECZKAlub ustaw ciastka zSameSite=LaxLubSameSite=Ścisłygdzie to możliwe. To zmniejsza żądania między witrynami przenoszące ciastka sesyjne. - Włącz uwierzytelnianie dwuskładnikowe (2FA) dla kont administratorów, aby utrudnić kompromitację konta.
- Ogranicz konta administratorów: stosuj zasadę najmniejszych uprawnień. Używaj szczegółowych ról dla redaktorów treści w porównaniu do administratorów witryn.
- Użyj ponownego uwierzytelnienia dla wrażliwych działań administracyjnych — poproś użytkownika o ponowne wprowadzenie hasła przed zmianą krytycznych ustawień.
- Zmniejsz liczbę administratorów, którzy mogą uzyskać dostęp do ustawień wtyczek. Jeśli to możliwe, przydziel zarządzanie wtyczkami do jednego zaufanego konta.
- Używaj polityk bezpieczeństwa treści (CSP) i opcji X-Frame, aby zmniejszyć ryzyko clickjackingu i wektorów wstrzykiwania skryptów.
- Utrzymuj wtyczki i motywy w minimalnej formie i z wiarygodnych źródeł.
Lista kontrolna reakcji na incydenty — gdy zauważysz podejrzaną aktywność
-
Zawierać
Natychmiast dezaktywuj podatną na ataki wtyczkę.
Zablokuj dostęp administratora za pomocą listy dozwolonych adresów IP lub tymczasowego trybu konserwacji. -
Zachowaj
Zrób pełny zrzut systemu plików i bazy danych. Nie modyfikuj plików, które mogą być dowodem. -
Zbadać
Przejrzyj logi dostępu i serwera WWW w poszukiwaniu żądań w czasie zmiany.
Zidentyfikuj, które konto administratora zostało użyte; sprawdź metadane użytkownika pod kątem ostatnich czasów logowania.
Użyj skanerów złośliwego oprogramowania i kontroli integralności plików. -
Oczyść lub przywróć
Jeśli masz znaną czystą kopię zapasową przed incydentem, rozważ przywrócenie do tego stanu po zweryfikowaniu, że luka została naprawiona.
Ręcznie usuń złośliwy kod lub przywróć nieautoryzowane ustawienia. -
Przywróć dane uwierzytelniające i sekrety
Zresetuj hasła dla użytkowników administratorów, szczególnie tych, które mogły być używane w czasie incydentu.
Wydaj ponownie klucze API lub tokeny używane przez witrynę. -
Zgłoś i ucz się
Gdy luka w wtyczce zostanie potwierdzona, śledź wydanie dostawcy i zastosuj oficjalną łatkę, gdy będzie dostępna.
Zapisz, co pozwoliło na incydent (brak nonce, nadmierne uprawnienia) i wdroż procesy kontrolne w rozwoju, aby zapobiec regresji.
Testowanie swojej ochrony — zalecane testy
- Symuluj atak CSRF w środowisku testowym:
- Utwórz prostą stronę HTML na innej domenie, która wysyła dane do podejrzanego punktu końcowego ustawień i obserwuj, czy zmiany są akceptowane.
- Jeśli twój WAF to zablokuje i/lub wtyczka to odrzuci (błąd nonce / niewystarczające uprawnienia), test jest udany.
- Sprawdź, czy wszystkie formularze ustawień wtyczki zawierają nonce i kontrolowane przez uprawnienia obsługiwacze:
- Sprawdź znacznik formularza pod kątem
pole_nonce()i obsługiwacza dlawp_verify_nonce()Lubcheck_admin_referer().
- Sprawdź znacznik formularza pod kątem
- Użyj automatycznego skanera wtyczek i przeglądu kodu w celu wykrycia brakujących kontroli nonce i
bieżący_użytkownik_może()weryfikacji w obsługiwaczach administracyjnych.
Dlaczego WAF i zarządzane łatki wirtualne są ważne
WAF może oferować szybką ochronę, zanim wydawca wtyczki wyda łatkę. Praktyczne wkłady WAF obejmują:
- Wirtualne łatanie: blokowanie znanych wzorców exploitów (żądania do konkretnych punktów końcowych, podejrzane referery lub heurystyki brakujących nonce).
- Ograniczenie liczby żądań: zmniejszenie szans na automatyczne próby wykorzystania.
- Powiadamianie: informowanie administratorów o zablokowanych podejrzanych żądaniach w celu dalszego zbadania.
- Wzmacnianie ruchu internetowego: zatrzymywanie powszechnie skanowanych ładunków lub podejrzanych nagłówków.
Notatka: WAF nie jest zamiennikiem dla poprawki kodu. Jest to niezbędna tymczasowa ochrona i dodatkowa warstwa obrony, która może znacznie zmniejszyć ryzyko podczas stosowania trwałej łatki.
Jak WP‑Firewall pomaga (nasze podejście)
W WP‑Firewall traktujemy problemy z CSRF i punktami końcowymi ustawień jako poważne i łatwe do działania. Nasze podejście łączy:
- Szybkie wirtualne łatanie wdrażane na chronionych stronach w celu blokowania znanych wzorców exploitów.
- Kompleksowe skanowanie w poszukiwaniu brakujących nonce i niebezpiecznych kontroli uprawnień w zainstalowanych wtyczkach.
- Inspekcja ruchu w czasie rzeczywistym w celu identyfikacji prób fałszerstwa i powiadamiania właścicieli stron.
- Wskazówki dla zespołów deweloperskich dotyczące naprawy kodu (wdrożenie nonce, kontrole uprawnień, sanitizacja danych wejściowych).
- Wsparcie po incydencie w celu audytu strony, oczyszczenia wskaźników i zalecenia bezpiecznej konfiguracji.
Chroń swoją stronę WordPress za pomocą naszego darmowego planu — rozpocznij w kilka minut.
Tytuł: Zacznij od Ochrony Podstawowej: WP‑Firewall Basic (Darmowy) Plan.
Jeśli chcesz szybkiej, zautomatyzowanej ochrony podczas stosowania poprawek w kodzie, rozważ zapisanie się do podstawowego (darmowego) planu WP‑Firewall. Oferuje on niezbędne zabezpieczenia, które mają znaczenie natychmiast:
- Zarządzany zapora z zasadami dostosowanymi do WordPressa.
- WAF w celu łagodzenia typowych wzorców exploitów (w tym heurystyki CSRF).
- Nielimitowana przepustowość przez warstwę ochrony
- Skaner złośliwego oprogramowania do wykrywania podejrzanych plików i modyfikacji
- Łagodzenie ryzyk OWASP Top 10 w celu zmniejszenia szerokiego spektrum typowych wektorów ataku.
Zapisz się na darmowy plan i chroń swoją stronę pod adresem: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Jeśli potrzebujesz więcej zautomatyzowanej naprawy i zaawansowanych kontroli, nasze plany Standard i Pro dodają automatyczne usuwanie złośliwego oprogramowania, czarną/białą listę IP, automatyczne wirtualne łatanie luk oraz zarządzane usługi bezpieczeństwa.
Często zadawane pytania
- Q: Czy WAF może całkowicie zatrzymać CSRF?
- A: WAF może znacznie zmniejszyć ryzyko (wirtualne łatanie, kontrole refererów, heurystyki dla brakujących nagłówków nonce), ale nie może weryfikować nonce WordPressa po stronie serwera dla każdego żądania. Ostatecznym rozwiązaniem jest wdrożenie wtyczki weryfikacji nonce i kontroli uprawnień. WAF uzupełnia poprawkę kodu i daje ci czas.
- Q: Czy powinienem całkowicie usunąć wtyczkę Bottom Bar?
- A: Jeśli wtyczka nie jest krytyczna dla funkcji biznesowych, dezaktywacja jej do czasu udostępnienia poprawionej wersji jest najbezpieczniejszym rozwiązaniem. Jeśli jest krytyczna, zastosuj łagodzenia WAF i ogranicz dostęp administratora, monitorując jednocześnie poprawkę od dostawcy.
- Q: Czy ta luka umożliwia całkowite przejęcie strony?
- A: Nie sama w sobie. CSRF pozwala na wymuszone działania przez uwierzytelnionych użytkowników. Może być łączona z innymi lukami lub nadużywana do wstawiania złośliwych zasobów. Traktuj to poważnie i działaj szybko.
Ostateczne rekomendacje — praktyczna lista kontrolna
- Natychmiast: Jeśli to możliwe, dezaktywuj dotkniętą wtyczkę do czasu wydania poprawionej wersji.
- Jeśli nie możesz dezaktywować: zastosuj wirtualne łatanie WAF i ogranicz dostęp administratora.
- Monitoruj: sprawdzaj logi i aktywność pod kątem nieoczekiwanych żądań POST i zmodyfikowanych opcji.
- Napraw: upewnij się, że autor wtyczki lub twój zespół deweloperski dodaje weryfikację nonce, sprawdzenia uprawnień (current_user_can) i sanitizację danych wejściowych.
- Wzmocnij: włącz 2FA, ogranicz konta administratorów i używaj ciasteczek SameSite.
- Kopia zapasowa: utrzymuj regularne kopie zapasowe w zewnętrznej lokalizacji i testuj przywracanie.
Jeśli potrzebujesz pomocy w implementacji wirtualnych poprawek, pisaniu precyzyjnych reguł WAF dla swojego stosu hostingowego lub przeprowadzaniu skanowania odpowiedzi na incydenty i usuwaniu skutków, nasz zespół ds. bezpieczeństwa w WP‑Firewall może pomóc. Zacznij od naszego planu Basic (darmowego), aby uzyskać natychmiastową zarządzaną ochronę WAF, podczas gdy planujesz długoterminowe poprawki: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Odniesienia i dalsza lektura
- CVE‑2026‑6401 (publiczna informacja)
- Podręcznik dewelopera rdzenia WordPress: Nonce i kontrole bezpieczeństwa
- Wzorce łagodzenia CSRF w aplikacjach internetowych (sprawdzenia refererów, SameSite, nonce)
Zastrzeżenie: Ten post ma na celu wyjaśnienie podatności, realistycznych ryzyk i łagodzeń z praktycznej perspektywy bezpieczeństwa WordPress. Konkretne szczegóły implementacji powyżej są przykładami i powinny być dostosowane do twojego środowiska. Zawsze testuj reguły WAF w środowisku testowym przed ich zastosowaniem w produkcji.
