Everest Forms Pro RCE (CVE 2026)

Jak logika formularza doprowadziła do wykonania kodu na serwerze

Pod koniec marca 2026 roku opublikowano krytyczną podatność typu Remote Code Execution w pluginie Everest Forms Pro (do wersji 1.9.12). Luka otrzymała ocenę 9.8 w skali CVSS i została załatana w wersji 1.9.13.

Na poziomie opisu CVE jest to kolejny przypadek RCE w ekosystemie WordPressa. W praktyce jednak mamy do czynienia z podatnością, która powstaje w warstwie logiki biznesowej aplikacji, a nie w klasycznych mechanizmach wejścia.

W ramach przeprowadzonych przez nas testów bezpieczeństwa przeanalizowaliśmy tę podatność, odtworzyliśmy jej mechanizm oraz zbudowaliśmy działający exploit potwierdzający możliwość wykonania kodu po stronie serwera.

Kontekst: funkcjonalność, która miała upraszczać biznes

Everest Forms Pro oferuje funkcję Complex Calculation, która pozwala na dynamiczne przeliczanie wartości w formularzu na podstawie danych wprowadzonych przez użytkownika.

Z punktu widzenia użytkownika biznesowego jest to typowa funkcjonalność:

• automatyczne kalkulacje

• dynamiczne formularze

• logika zależna od danych wejściowych

Z punktu widzenia bezpieczeństwa jest to jednak obszar, w którym dane użytkownika zaczynają wpływać na sposób działania aplikacji.

Gdzie pojawia się podatność

W analizowanym przypadku dane wejściowe użytkownika nie są traktowane wyłącznie jako wartości wykorzystywane w obliczeniach.

Zamiast tego:

• są osadzane w strukturze wyrażenia budowanego po stronie serwera

• wpływają na finalną postać tego wyrażenia

• są interpretowane w kontekście wykonania

To prowadzi do sytuacji, w której granica między danymi a kodem przestaje istnieć.

W praktyce oznacza to możliwość:

• modyfikacji logiki wykonywanej przez aplikację

• wstrzyknięcia kontrolowanego fragmentu do kontekstu wykonania

• osiągnięcia wykonania kodu po stronie serwera

Analiza podatności i budowa exploita

Publiczny opis CVE wskazywał na problem w mechanizmie Complex Calculation, jednak nie zawierał gotowego scenariusza wykorzystania.

Proces analizy obejmował kilka etapów.

Najpierw identyfikacja punktów wejścia, w których dane użytkownika trafiają do mechanizmu obliczeń.

Następnie obserwacja zachowania aplikacji dla nietypowych danych:

• błędy składniowe

• nieoczekiwane odpowiedzi

• różnice w przetwarzaniu danych

Na tym etapie nie było jeszcze bezpośredniego wykonania kodu, jednak pojawiły się przesłanki wskazujące na interpretację danych w kontekście wykonania.

Kolejne iteracje testów pozwoliły na:

• określenie sposobu składania wyrażeń po stronie serwera

• identyfikację kontekstu wykonania

• przygotowanie danych wejściowych umożliwiających kontrolę nad tym procesem

W efekcie opracowaliśmy działający exploit, który potwierdza możliwość wykonania kodu na serwerze bez uwierzytelnienia.

Techniczne znaczenie podatności

Potwierdzony scenariusz oznacza, że zewnętrzny użytkownik może:

• wpłynąć na sposób wykonania logiki aplikacji

• doprowadzić do wykonania kodu w środowisku serwera

• uzyskać dostęp do zasobów aplikacyjnych

W zależności od konfiguracji środowiska może to prowadzić do:

• odczytu danych aplikacji

• dostępu do plików systemowych

• przejęcia kontekstu aplikacji

• utrzymania trwałego dostępu

Znaczenie biznesowe

Z perspektywy organizacji kluczowe jest to, że podatność:

• występuje w publicznie dostępnej funkcji

• nie wymaga uwierzytelnienia

• jest trudna do wykrycia w standardowych testach funkcjonalnych

W praktyce oznacza to realne ryzyko:

• wycieku danych

• naruszenia ciągłości działania

• kompromitacji systemu

Istotne jest również to, że podatność nie znajduje się w warstwie infrastruktury, lecz w logice biznesowej, która rzadko jest testowana pod kątem bezpieczeństwa.

Dlaczego takie podatności są pomijane

Ten przypadek dobrze pokazuje problem systemowy.

Funkcje takie jak dynamiczne kalkulacje są postrzegane jako element UX lub automatyzacji biznesowej, a nie jako potencjalny wektor ataku.

W efekcie:

• nie są objęte testami bezpieczeństwa

• są implementowane bez pełnej separacji danych i logiki

• trafiają do produkcji bez analizy kontekstu wykonania

To właśnie w takich miejscach powstają najbardziej krytyczne podatności.

Rekomendacje

Działania krótkoterminowe:

• aktualizacja Everest Forms Pro do wersji 1.9.13 lub nowszej

• weryfikacja wykorzystania funkcji Complex Calculation

Działania systemowe:

• identyfikacja miejsc, w których dane użytkownika wpływają na logikę aplikacji

• eliminacja dynamicznego wykonywania wyrażeń opartych na danych wejściowych

• wprowadzenie testów bezpieczeństwa obejmujących logikę biznesową

Kluczowe jest traktowanie takich mechanizmów nie jako funkcjonalności pomocniczej, lecz jako potencjalnego wektora wykonania kodu.

Wnioski

Analizowana podatność nie jest wyjątkiem, lecz przykładem szerszego problemu.

Granica między danymi a kodem jest jednym z najważniejszych elementów bezpieczeństwa aplikacji. Jej naruszenie prowadzi bezpośrednio do najbardziej krytycznych scenariuszy, takich jak Remote Code Execution.

W ramach naszych testów potwierdziliśmy, że w tym przypadku taka granica została przekroczona, a mechanizm formularza może zostać wykorzystany jako punkt wejścia do wykonania kodu na serwerze.

To pokazuje, że skuteczne podejście do bezpieczeństwa wymaga nie tylko reagowania na CVE, ale przede wszystkim rozumienia, jak aplikacje przetwarzają dane i gdzie mogą powstać nieoczywiste wektory ataku.

O nas

Specjalizujemy się w testach bezpieczeństwa aplikacji, ze szczególnym uwzględnieniem logiki biznesowej i niestandardowych scenariuszy ataku.

Takie przypadki jak opisany powyżej nie są odosobnione. W praktyce regularnie identyfikujemy podatności wynikające nie z błędów infrastrukturalnych, lecz z nieoczywistych zależności w logice aplikacji.

Jeżeli interesuje Cię, jak takie podatności są znajdowane w praktyce oraz jak wygląda proces ich analizy, omawiamy to szerzej podczas naszych webinarów.

Najbliższy webinar dotyczący testów bezpieczeństwa aplikacji odbędzie się 10 kwietnia 2026.

Jeżeli chcesz otrzymać nagranie lub dowiedzieć się więcej, napisz do nas.