Nazwa wtyczki	Wtyczka WordPress Responsive Blocks
Rodzaj podatności	Otwarte przekierowanie
Numer CVE	CVE-2026-6675
Pilność	Niski
Data publikacji CVE	2026-04-21
Adres URL źródła	CVE-2026-6675

Poradnik bezpieczeństwa: Nieautoryzowany otwarty relay e-mailowy / Otwarta redirekcja w wtyczce Responsive Blocks (CVE-2026-6675) — Co właściciele stron WordPress muszą teraz zrobić

Autor: Zespół ds. bezpieczeństwa WP‑Firewall
Data: 2026-04-21
Tagi: WordPress, bezpieczeństwo, WAF, podatność, wtyczka, responsive-blocks, CVE-2026-6675

---

Streszczenie: Niska podatność, ale możliwa do wykorzystania (CVE-2026-6675) wpływa na wtyczkę Responsive Blocks WordPress (wersje ≤ 2.2.0). Nieautoryzowany parametr REST API o nazwie email_do może być nadużyty do stworzenia otwartego relayu e-mailowego lub umożliwienia otwartego zachowania redirekcji. Zaktualizuj do wersji 2.2.1 natychmiast. Jeśli nie możesz zaktualizować od razu, zastosuj tymczasowe środki zaradcze opisane poniżej.

---

Spis treści

• Co się stało
• Wersje dotknięte i harmonogram
• Podsumowanie techniczne luki w zabezpieczeniach
• Rzeczywisty wpływ i scenariusze ataków
• Wykrywanie: jak sprawdzić, czy byłeś celem lub ofiarą nadużycia
• Natychmiastowe poprawki (zalecana kolejność działań)
• Tymczasowe środki zaradcze i przykłady wirtualnych poprawek
• Wskazówki dotyczące wzmocnienia dla autorów wtyczek i operatorów stron
• Jak WP‑Firewall pomaga i informacje o planie darmowym
• Ostateczne uwagi i dalsza lektura

---

Co się stało

21 kwietnia 2026 roku opublikowano podatność wpływającą na wtyczkę Responsive Blocks WordPress i przypisano jej CVE-2026-6675. Przyczyną jest niewłaściwa walidacja i autoryzacja dotycząca parametru REST API (email_do) ujawnionego przez wtyczkę. Nieautoryzowany aktor może wykorzystać ten parametr do przesyłania e-maili lub uruchamiania niezweryfikowanej ścieżki redirekcji — skutecznie umożliwiając otwarty relay e-mailowy i otwarte zachowania redirekcji.

Autor wtyczki wydał poprawkę w wersji 2.2.1, która naprawia problem. Administratorzy korzystający z wersji 2.2.0 lub starszych powinni zaktualizować jak najszybciej.

Dlaczego powinieneś się tym przejmować: nawet niskie podatności mogą być wykorzystywane na dużą skalę. Otwarte relaye e-mailowe umożliwiają masowe kampanie spamowe lub phishingowe z Twojej domeny, co może prowadzić do czarnej listy, problemów z dostarczalnością lub szkód w reputacji. Otwarta redirekcja może ułatwić ataki phishingowe i inżynierię społeczną, które kierują Twoich użytkowników na złośliwe strony.

Wersje dotknięte i harmonogram

• Dotknięte: wtyczka Responsive Blocks — wersje ≤ 2.2.0
• Poprawione: 2.2.1 (aktualizacja dostarczona przez dewelopera wtyczki)
• CVE: CVE-2026-6675
• Wymagane uprawnienia: Brak (Nieautoryzowane)
• Ocena ryzyka (zgłoszona): Niska (Patchstack zgłosił CVSS 5.3; klasyfikacja: Otwarta redirekcja / Niebezpieczny projekt)

Notatka: “Niska” podatność w CVSS nie oznacza “braku wymaganej akcji”. Nieautoryzowane wektory w publicznych witrynach mogą być wykorzystywane masowo, więc szybko zastosuj środki zaradcze.

Podsumowanie techniczne luki w zabezpieczeniach

Na wysokim poziomie, wtyczka udostępnia trasę API REST, która akceptuje email_do parametr i wykonuje jedną z następujących akcji (w zależności od wewnętrznych mechanizmów wtyczki):

• Wysyła e-maile bezpośrednio na podstawie email_do wartości bez odpowiedniej walidacji i autoryzacji (otwarte zachowanie przekazywania e-maili), lub
• Używa email_do lub parametrów towarzyszących do wygenerowania adresu URL przekierowania, który nie jest walidowany w stosunku do listy dozwolonych (otwarte przekierowanie).

Dlaczego to ma znaczenie technicznie:

• Punkty końcowe API REST w WordPressie są dostępne dla każdego, chyba że wdrożą odpowiednie kontrole uprawnień. Jeśli trasa nie wymaga uwierzytelnienia i przekazuje parametry dostarczone przez użytkownika do funkcji wysyłania e-maili lub przekierowań, napastnicy mogą to wykorzystać.
• Brak walidacji oznacza, że napastnik może określić dowolne cele (adresy e-mail lub hosty przekierowań). W przypadku przekazywania e-maili, strona staje się wektorem podobnym do SMTP dla spamu; w przypadku otwartego przekierowania, napastnicy mogą zwabić użytkowników na stronę (legitymujący się URL) i następnie przekierować ich do domen phishingowych/malware.

Przykład wykorzystania (koncepcyjny)

• Napastnik wysyła żądanie POST do punktu końcowego REST wtyczki z email_do parametrem ustawionym na adres docelowy lub z adresem URL przekierowania, który wskazuje na złośliwy host.
• Ponieważ punkt końcowy nie zweryfikował email_do (np. za pomocą is_email() i kontroli domen/listy dozwolonych) i nie wymagał uwierzytelnienia, żądanie się powiodło.
• Wynik: e-mail jest wysyłany z Twojej domeny do osób trzecich, lub odwiedzający są przekierowywani do domen kontrolowanych przez napastnika.

Ważny: Dokładna ścieżka trasy REST i struktura ładunku różnią się w zależności od wewnętrznej implementacji wtyczki. Niemniej jednak, wektor jest ten sam: nieautoryzowany input przekazywany bezpośrednio do logiki e-mail/redirect.

Rzeczywisty wpływ i scenariusze ataków

Chociaż klasyfikowane jako “niskie”, praktyczne skutki mogą być dość szkodliwe:

1. Spam i masowe phishing
   Napastnicy wykorzystują Twoją stronę do wysyłania dużych ilości e-maili do osób trzecich (spam, phishing). Ponieważ e-maile pochodzą z Twojego serwera/domeny, wydają się bardziej zaufane, co zwiększa wskaźniki kliknięć i potencjalne szkody.
2. Reputacja domeny i czarna lista
   Dostawcy usług internetowych i dostawcy ochrony przed spamem mogą zablokować Twój adres IP lub domenę po wykryciu wychodzącego spamu. Przywracanie zajmuje dużo czasu i może zakłócić legalne operacje e-mailowe (e-maile transakcyjne, biuletyny, powiadomienia dla użytkowników).
3. Phishing oparty na przekierowaniach
   Otwarte przekierowania pozwalają atakującym tworzyć adresy URL używając Twojej legalnej domeny, aby ukryć złośliwe ładunki. Użytkownicy widzą Twoją domenę w adresach (zwiększając zaufanie) i są przekierowywani na strony zbierające dane uwierzytelniające.
4. Wzmocnienie inżynierii społecznej
   Użycie Twojej domeny zwiększa zaufanie do kampanii phishingowych — atakujący mogą wysyłać e-maile do ofiar, które wydają się pochodzić z zaufanego źródła, lub udostępniać linki w kanałach społecznościowych, które zaczynają się od Twojej domeny.
5. Uszkodzenia SEO i zaufania użytkowników
   Złośliwe przekierowania i spam mogą zaszkodzić rankingom SEO i zaufaniu użytkowników; ich oczyszczenie może być kosztowne.

Wykrywanie: jak sprawdzić, czy byłeś celem lub ofiarą nadużycia

Szybko sprawdź następujące:

• Serwer WWW i logi dostępu:
  • Szukaj nieautoryzowanych żądań POST/GET do punktów końcowych REST API z parametrami nazwanymi email_do, przekierowanie, Do, odbiorca, lub innymi polami podobnymi do e-maila.
  • Zwróć uwagę na częstotliwość i adresy IP pochodzenia. Masowe żądania z wielu adresów IP mogą wskazywać na automatyczne skanowanie/wykorzystanie.
• Logi pocztowe:
  • Sprawdź logi pocztowe (logi exim, postfix, sendmail lub logi od Twojego zarządzanego dostawcy poczty) pod kątem nagłych wzrostów w objętości wychodzącej poczty lub wiadomości z nietypowymi tematami/treściami związanymi z zachowaniem wtyczki.
  • Sprawdź powiadomienia o odbiciach i odpowiedzi automatyczne, które wskazują na masowe wysyłanie.
• Limity hostingowe/SMTP:
  • Powiadomienia o osiągnięciu limitów wysyłania e-maili lub zablokowaniu przez hosta.
  • E-maile oznaczone jako spam lub odrzucone przez dużych dostawców.
• Google Search Console / Narzędzia do wyszukiwania i bezpieczeństwa:
  • Wiadomości o szkodliwych treściach, phishingu lub działaniach ręcznych.
• Sprawdzenie czarnej listy:
  • Sprawdź, czy Twój adres IP lub domena znajduje się na wspólnych czarnych listach RBL (Spamhaus itp.).
• Treść na stronie:
  • Szukaj wstrzykniętego kodu przekierowującego lub nieoczekiwanych stron, które wykonują meta-odświeżanie lub przekierowania JavaScript.

Natychmiastowe poprawki (zalecana kolejność działań)

1. Zaktualizuj wtyczkę (najlepsze i najszybsze)
   Natychmiast zaktualizuj Responsive Blocks do wersji 2.2.1 lub nowszej. To jest oficjalna poprawka i powinna być zastosowana jako pierwsza, chyba że masz blokadę kompatybilności.
2. Jeśli nie możesz zaktualizować natychmiast, izoluj ryzyko
   Tymczasowo wyłącz wtyczkę z panelu administracyjnego WordPress lub za pomocą wp‑cli:
   wp wtyczka dezaktywuj responsive-blocks
   Lub wyłącz wtyczkę, zmieniając nazwę jej katalogu za pomocą SFTP/SSH.
3. Zablokuj problematyczną trasę REST za pomocą swojego zapory/WAF
   Zablokuj wszelkie żądania, które zawierają podejrzane email_do wartości lub wzorce na serwerze WWW lub zaporze upstream, zanim dotrą do WordPressa.
   Przykłady reguł WAF znajdują się poniżej.
4. Monitoruj logi e-mailowe i webowe
   Podczas stosowania środków zaradczych monitoruj logi pod kątem dalszych prób i oczyść wszelkie wychodzące spam, który został wysłany.
5. Powiadom interesariuszy.
   Poinformuj swojego dostawcę hostingu / zespół operacyjny wewnętrzny. Jeśli doszło do nadużycia, może być konieczne skoordynowanie usunięcia z listy lub dostarczenie dowodów dostawcom poczty.
6. Jeśli nadużycie zostało potwierdzone, zresetuj odpowiednie dane uwierzytelniające i zaktualizuj ustawienia e-mail
   Zaktualizuj wszelkie dane uwierzytelniające SMTP używane przez stronę, zmień klucze API i potwierdź, że żadne inne wtyczki/motywy nie zostały zmienione.

Tymczasowe środki zaradcze i przykłady wirtualnych poprawek

Jeśli musisz utrzymać wtyczkę aktywną z powodów biznesowych i nie możesz zaktualizować natychmiast, możesz zastosować tymczasowe środki (wirtualne poprawki), aby zablokować wektor eksploatacji. Dwa podejścia są przydatne:

A. Blokowanie na poziomie serwera (zalecane do natychmiastowego złagodzenia)

Zablokuj żądania za pomocą email_do= lub podejrzane ładunki na serwerze WWW lub krawędzi CDN (Cloudflare itp.):

przykład nginx (odrzucenie żądań zawierających parametr email_to):

# Blokuj ciągi zapytań zawierające email_to=

Przykład Apache (.htaccess):

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{QUERY_STRING} (?:^|&)email_to= [NC]
  RewriteRule .* - [F]
</IfModule>

Notatka: blokowanie ciągów zapytań może wpłynąć na legalną funkcjonalność, jeśli używasz kompatybilnej funkcji; testuj ostrożnie.

B. Wirtualna łatka na poziomie WordPressa (wtyczka MU)

Umieść poniższy fragment PHP jako wtyczkę do użycia (wrzuć do wp-content/mu-plugins/virtual-patch-block-email_do.php). To wymusza wczesne odrzucenie żądań, które zawierają email_do parametr w żądaniach REST.

<?php

Uwagi:

• To jest tymczasowe złagodzenie. Zastąp lub usuń wtyczkę mu po zaktualizowaniu do wersji wtyczki z łatką.
• Dokładnie przetestuj to w środowisku testowym przed zastosowaniem na serwerze produkcyjnym, szczególnie jeśli używasz punktów końcowych REST do legalnych przepływów pracy.

C. Przykłady reguł WAF (koncepcyjne)

Blokuj żądania POST do dowolnej trasy, które zawierają email_do= wzory e-mailowe lub parametry przekierowania:
Przykłady wyrażeń regularnych dla silników reguł WAF (dostosuj do składni swojego WAF):

• Blokuj, jeśli ciało POST lub zapytanie zawiera:
  (email_to=.+@.+\..+)
• Zablokuj, jeśli przekierowanie parametr zawiera zewnętrzny host:
  redirect=(?:https?://)(?!twojadomena\.com)

Zastąp yourdomain.com z twoją kanoniczną domeną(-ami). Używaj ostrożności: zbyt ogólne zasady mogą zepsuć legalne integracje zewnętrzne.

Wskazówki dotyczące wzmocnienia dla autorów wtyczek i operatorów stron

Jeśli rozwijasz lub utrzymujesz wtyczki WordPress, lub zarządzasz stronami WordPress, stosuj te najlepsze praktyki, aby uniknąć podobnych problemów:

1. Zastosuj ścisłą walidację danych wejściowych
   • Waliduj adresy e-mail za pomocą is_email() przed ich użyciem w wp_mail lub innej logice wysyłania.
   • Waliduj adresy URL za pomocą esc_url_raw() i sprawdzaj hosty w stosunku do listy dozwolonych dla przekierowań.
2. Wymuś odpowiednią autoryzację
   • Punkty końcowe REST powinny sprawdzać możliwości użytkownika za pomocą bieżący_użytkownik_może() lub używać wywołań zwrotnych uprawnień podczas rejestrowania tras za pomocą register_rest_route(). Nie pozwalaj na nieautoryzowane żądania do wykonywania działań, które mogą wysyłać e-maile lub wykonywać przekierowania.
3. Unikaj tworzenia funkcji podobnych do przekazywania poczty
   • Nigdy nie akceptuj dowolnych Do adresów od nieautoryzowanych użytkowników. Jeśli wymagany jest formularz kontaktowy dla użytkowników, ogranicz odbiorcę do stałej skrzynki pocztowej lub do zestawu wcześniej zatwierdzonych adresów.
4. Używać wp_safe_redirect dla przekierowań
   • Podczas przekierowywania, preferuj wp_safe_redirect() i utrzymuj listę dozwolonych domen lub przekierowuj tylko do wewnętrznych ścieżek.
5. Zastosuj bezpieczne domyślne ustawienia
   • Domyślne zachowanie wtyczek powinno być konserwatywne: zamykaj, gdy dane wejściowe są nieprawidłowe; wymagaj minimalnych uprawnień do potencjalnie destrukcyjnych działań.
6. Rejestrowanie i ograniczanie liczby żądań
   • Rejestruj podejrzaną aktywność i dodaj ograniczenia/throttling na punktach końcowych, które wysyłają e-maile lub wywołują przekierowania.
7. Zapewnij ujawnienie luk w zabezpieczeniach i szybki sposób aktualizacji
   • Szybkie poprawki, porady dotyczące bezpieczeństwa i kontakt do odpowiedzialnego ujawnienia ułatwiają właścicielom stron szybkie łagodzenie problemów.

Jak WP‑Firewall pomaga

Jako dostawca zapory ogniowej WordPress i usług zabezpieczeń, naszym celem jest pomoc właścicielom stron w szybkim reagowaniu na luki w zabezpieczeniach wtyczek, takie jak ta. WP‑Firewall zapewnia kilka warstw ochrony, które są przydatne od razu:

• Zarządzane zasady WAF aktualizowane przez nasz zespół ds. bezpieczeństwa w celu blokowania nowych wektorów eksploatacji
• Wirtualne łatanie, które chroni punkty końcowe bez modyfikacji kodu wtyczki
• Skanowanie złośliwego oprogramowania w celu wykrycia nadużyć wychodzących lub wstrzykniętych przekierowań
• Monitorowanie i powiadamianie o podejrzanej aktywności REST API
• Wskazówki i wsparcie w koordynacji działań naprawczych

Zacznij od naszego bezpłatnego planu podstawowego, aby uzyskać niezbędną ochronę i natychmiast zmniejszyć narażenie.

Chroń swoją stronę już dziś — zacznij od darmowego planu WP‑Firewall

Rozumiemy presję, z jaką borykają się właściciele stron, gdy publikowane są luki w zabezpieczeniach. Jeśli chcesz natychmiastowej, zarządzanej ochrony podczas testowania i stosowania aktualizacji wtyczek, nasz plan podstawowy (bezpłatny) zapewnia niezbędne zabezpieczenia bez kosztów. Bezpłatny plan obejmuje zarządzaną zaporę ogniową, nielimitowaną przepustowość, zaporę aplikacji internetowych (WAF) dostosowaną do WordPressa, skaner złośliwego oprogramowania oraz łagodzenie ryzyk OWASP Top 10 — dokładnie te warstwy, które pomagają zatrzymać nienaautoryzowane nadużycia REST API w zarodku.

Zbadaj darmowy plan i zarejestruj się tutaj: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Jeśli potrzebujesz więcej funkcji, oferujemy również poziomy Standard i Pro z automatycznym usuwaniem złośliwego oprogramowania, czarną/białą listą adresów IP, automatycznym wirtualnym łatanie luk, miesięcznymi raportami bezpieczeństwa oraz dodatkami premium, takimi jak dedykowany menedżer konta i zarządzane usługi zabezpieczeń. Te opcje są zaprojektowane, aby wspierać zespoły, które chcą głębszej widoczności i proaktywnej ochrony.

(Dlaczego to działa: połączenie WAF + wirtualne łatanie blokuje eksploatację na wczesnym etapie, podczas gdy skaner złośliwego oprogramowania pomaga potwierdzić, czy nadużycie już miało miejsce.)

Zalecane długoterminowe kroki po usunięciu luk

1. Utrzymuj wtyczki, motywy i rdzeń WordPressa zaktualizowane
   Regularne aktualizacje są najlepszą obroną przed znanymi lukami w zabezpieczeniach.
2. Wdrażaj polityki poczty na poziomie hosta
   Skonfiguruj uwierzytelnione SMTP i ograniczaj stawki poczty wychodzącej. Użyj kontroli na poziomie dostawcy, aby zapobiec automatycznym nadużyciom.
3. Przejrzyj swój inwentarz wtyczek
   Usuń nieużywane wtyczki. Mniej wtyczek oznacza mniej potencjalnych luk w zabezpieczeniach.
4. Wdróż środowisko testowe do testowania.
   Testuj aktualizacje wtyczek i wirtualne poprawki w środowisku testowym przed wdrożeniem.
5. Ustanów plan reakcji na incydenty
   Zdefiniuj role, kontakty (hosting, dostawca zabezpieczeń) i kroki do podjęcia, gdy zostanie znaleziona luka w zabezpieczeniach.
6. Przejrzyj i zaostrz ekspozycję REST API.
   Audytuj trasy zarejestrowane na swojej stronie (wtyczki i motywy) i zweryfikuj wywołania uprawnień.

Szczegółowa lista kontrolna dla administratorów strony.

Pilne (0–24 godziny):

• Zaktualizuj Responsive Blocks do 2.2.1.
• Jeśli aktualizacja nie jest możliwa natychmiast, wyłącz wtyczkę.
• Wprowadź regułę WAF blokującą żądania zawierające. email_do wzorców.
• Monitoruj logi pocztowe w poszukiwaniu nagłych wzrostów lub anomalii.

Krótkoterminowe (24–72 godziny):

• Umieść wtyczkę MU-wirtualną poprawkę, jeśli musisz utrzymać działanie funkcjonalności.
• Przejrzyj logi serwera WWW w poszukiwaniu wskaźników eksploatacji.
• Powiadom swojego dostawcę poczty/hosta, jeśli wystąpiła podejrzana aktywność pocztowa.

Średnioterminowe (1–2 tygodnie):

• Przejrzyj inne zainstalowane wtyczki pod kątem podobnych punktów końcowych REST API, które nie mają kontroli uprawnień.
• Wzmocnij przepływ poczty i poprawnie skonfiguruj SPF/DKIM/DMARC, aby zminimalizować wpływ fałszywych e-maili i utrzymać dostarczalność.

Długoterminowe (ciągłe):

• Wprowadź ciągłe monitorowanie i zarządzane reguły WAF.
• Prowadź inwentaryzację i przyjmij politykę weryfikacji wtyczek przed zainstalowaniem wtyczek firm trzecich.

Przykładowe wskaźniki logów do poszukiwania

• Powtarzające się żądania do punktów końcowych REST zawierających email_do= lub podejrzane adresy e-mail.
• Wybuch żądań POST do rzadko używanych punktów końcowych krótko po ujawnieniu publicznym.
• Sesje SMTP wychodzące z dużą ilością i identycznymi wzorcami ładunków.
• Odbicia dla dużych wolumenów wiadomości w krótkim oknie czasowym.

Co zrobić, jeśli odkryjesz nadużycie

1. Zatrzymaj wektor: wyłącz wtyczkę lub zastosuj tymczasową łatkę wirtualną/regułę WAF.
2. Zachowaj logi: skopiuj i zapisz logi serwera, logi poczty oraz wszelkie podejrzane ładunki.
3. Poinformuj dostawców hostingu i poczty: mogą pomóc zablokować dalsze nadużycia i rozpocząć procesy usuwania z listy.
4. Oczyść wszelkie wstrzyknięte treści i usuń złośliwe strony/przekierowania.
5. Zmień dane uwierzytelniające: SMTP, konta administratorów oraz wszelkie klucze API używane na stronie.
6. Rozważ profesjonalny przegląd bezpieczeństwa, jeśli zauważysz oznaki głębszego kompromisu.

Zakończenie od WP‑Firewall

Ta luka w zabezpieczeniach przypomina, że nawet funkcjonalności, które wydają się rutynowe — wysyłanie e-maili lub obsługa przekierowań — mogą być nadużywane, jeśli nie są wdrażane w sposób bezpieczny. Dobra wiadomość: łatka jest dostępna, a szybkie kroki łagodzące istnieją. Priorytetowo zaktualizuj wtyczkę. Jeśli zarządzasz wieloma stronami, zastosuj wirtualną łatkę/reguły WAF w całym swoim majątku, aż aktualizacje zostaną wdrożone.

Jeśli potrzebujesz pomocy w stosowaniu środków łagodzących, ustawianiu reguł WAF lub dodawaniu zarządzanej wirtualnej łatki, aby być chronionym podczas koordynacji aktualizacji, zespół WP‑Firewall jest gotowy do pomocy. Pamiętaj, że połączenie silnych reguł WAF z bezpiecznymi praktykami rozwoju wtyczek znacznie zmniejsza narażenie na nieautoryzowane nadużycia.

Dalsze czytanie i odniesienia

• Notatki o łatkach i dziennik zmian autora wtyczki (sprawdź swoją stronę wtyczki)
• Dokumentacja twojego hosta lub dostawcy poczty dotycząca logów poczty wychodzącej i limitów szybkości
• Dokumentacja dewelopera WordPressa: najlepsze praktyki REST API, wywołania uprawnień i funkcje walidacji danych
• Publiczna informacja o lukach w zabezpieczeniach (CVE-2026-6675) dotycząca osi czasu i odniesień do łatek

---

Jeśli chcesz otrzymać krótką, priorytetową listę kontrolną do naprawy wysłaną na e-mail (jedna strona, prosty angielski), odpowiedz na ten post lub zapisz się na bezpłatny plan ochrony WP‑Firewall pod adresem:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Bądź bezpieczny i pamiętaj — terminowe aktualizacje oraz warstwowe zabezpieczenia chronią zarówno Twoją stronę, jak i jej użytkowników.
— Zespół Bezpieczeństwa WP‑Firewall