Jak przez jedną podatną wtyczkę WordPress ujawniono dziesiątki poświadczeń SMTP?

Czy jedna podatność we wtyczce do WordPressa może doprowadzić do blokady konta Mailgun? Ciekawą historię opisał Austin Ginder, który zaczął otrzymywać wiadomości dotyczące podejrzanej aktywności na koncie Mailgun (usługa do wysyłki tzw. e-maili transakcyjnych).

TLDR:

• Podatność CVE-2026-4020 w Gravity SMTP umożliwiała nieautoryzowany odczyt konfiguracji SMTP przez endpoint REST API.
• Austin Ginder odkrył kampanię skanowania pod kątem tej właśnie podatności. Jak okazało się później, 86 jego witryn ujawniło poświadczenia do Mailgun.
• Mailgun wykrył przypadki użycia skradzionych poświadczeń i czasowo zablokował powiązane domeny, jednak zaledwie kilka z ujawnionych kluczy zostało tak wykorzystanych.
• Rzeczywistą skalę ataku Austin poznał dopiero po analizie logów wszystkich stron.

Pracownik Mailgun skontaktował się z Austinem w sprawie ostatniej aktywności na koncie, informując o zablokowaniu dwóch domen wysyłkowych. Powodem takiego działania była podejrzana aktywność. Mailgun odnotował próby połączeń z adresu IP 94[.]26[.]106[.]248, z którego połączenia zaobserwowano na innych przejętych kontach, które prowadziły kampanie phishingowe.

Specjaliści z Mailgun w tej samej wiadomości wskazali prawdopodobną przyczynę – mowa o podatności we wtyczce Gravity SMTP dla WordPress (CVE-2026-4020). W wyniku jej wykorzystania przejmowano poświadczenia innych kont, stąd przypuszczano że i w tym przypadku właśnie ona jest powodem.

Podatność ta polegała na braku uwierzytelnienia dla jednego z endpointów REST API wystawianych przez wtyczkę. Pojedyncze żądanie GET do gravitysmtp/v1/tests/mock-data zwracało pełen raport systemowy, który zawierał również aktywne konfiguracje SMTP. Do uzyskania tych danych nie była konieczna żadna autoryzacja ani nawet uwierzytelnienie. Wystarczyło znać adres URL.

Austin wykorzystywał Gravity SMTP do wysyłania e-maili ze stron swoich klientów. Wtyczka łączyła się z Mailgun, który odpowiadał za wysyłkę. Każda witryna miała własną subdomenę do wysyłek i własny, unikalny klucz API oraz hasło SMTP. Dzięki temu w przypadku wycieku z jednej strony, nie będzie możliwe wysyłanie wiadomości przez subdomeny pozostałych.

Aby wtyczka mogła wysyłać maile, poświadczenia SMTP musiały być zapisane w jej konfiguracji. Wspomniana podatność umożliwiała ich odczytanie przez dowolnego atakującego. Pierwszym krokiem Austina było przeszukanie logów serwera pod kątem problematycznego adresu IP. I faktycznie – znalazł on wspomniany adres w jednym z archiwalnych dzienników:

customer-1-fake.com 94.26.106.248 [16/May/2026:12:41:03 +0000] GET “/wp-json/gravitysmtp/v1/tests/mock-data?page=gravitysmtp-settings” HTTP/2.0 200 … 24599 bytes

Listing 1 – fragment logów, źródło: anchor.host

To był moment, w którym klucze opuściły witrynę. Kolejna strona została trafiona w ten sam sposób 6 dni później – i to jej subdomenę wysyłkową Mailgun zablokował jako drugą.

Austin na tym etapie wiedział o dwóch stronach, bo tylko dwa zestawy poświadczeń faktycznie wykorzystano do połączenia z Mailgun. Pytanie brzmiało więc: ile jeszcze kluczy wyciekło? Odpowiedź miała przyjść po sprawdzeniu wszystkich jego witryn, które w tamtym czasie korzystały z nieaktualnej wersji Gravity SMTP. Wystarczyło przeszukać archiwalne logi dostępu (pod kątem tego samego endpointu), by odkryć że łącznie ujawniono poświadczenia dla 86 stron.

Austin obsługiwał łącznie 185 witryn, więc prawie połowa z nich została dotknięta atakiem. Okazało się, że nie był to najprawdopodobniej atak celowany w jego strony, a raczej kampania skanowania w poszukiwaniu stron z podatną wersją Gravity SMTP. Analiza logów pokazała, że skanowanie odbywało się z 806 unikalnych adresów IP, a cała kampania była rozłożona na co najmniej 36 dni.

Dobrą wiadomością był fakt, że w przypadku witryn Austina problematyczny endpoint zwracał jedynie poświadczenia SMTP. “Jedynie”, bo nie pozwalał uzyskać dostępu do samych stron i nie wyciekały przez niego inne istotne dane. Wystarczyło więc zrotować klucze Mailgun i zaktualizować wtyczkę, aby rozwiązać problem.

Jeśli używasz Gravity SMTP, upewnij się, że korzystasz z najnowszej wersji (podatność załatano w v2.1.5). Możesz także przeszukać logi dostępu pod kątem requestów do gravitysmtp/v1/tests/mock-data. Odpowiedź HTTP 200 może oznaczać, że dana witryna ujawniła poświadczenia i należy je zresetować. Błąd 401 lub 404 oznacza, że nie doszło do wycieku (a przynajmniej nie przez wspomnianą podatność).

W przypadku WordPressa polecamy dbać o regularne aktualizacje, bo szybkie wdrożenie poprawionej wersji znacznie zmniejszyłoby szanse na wykorzystanie podatności przez atakujących. Warto rozważyć włączenie automatycznych aktualizacji pluginów.

IoC

Lista skanujących adresów IP zaobserowanych przez Austina:

• 45[.]148[.]10[.]120
• 194[.]26[.]192[.]219
• 195[.]178[.]110[.]31
• 37[.]166[.]41[.]10
• 193[.]32[.]162[.]60
• 213[.]209[.]159[.]229
• 37[.]167[.]141[.]57
• 93[.]123[.]109[.]214
• 139[.]59[.]220[.]152
• 94[.]26[.]106[.]248
• 45[.]148[.]10[.]62
• 23[.]180[.]120[.]134
• 78[.]242[.]187[.]26
• 185[.]177[.]72[.]60
• 37[.]166[.]253[.]135

Źródło: anchor.host

~Tymoteusz Jóźwiak