Dwanaście głównych gałęzi rozwojowych Erlang/OTP jest podatnych na zdalny atak typu Denial of Service [^1]. Luka, oznaczona jako CVE-2026-49759, otrzymała ocenę 8.2 w skali CVSS (Common Vulnerability Scoring System — skala 0-10 oceniająca powagę luki) [cve]. Umożliwia nieautoryzowanemu atakującemu zdalne zatrzymanie maszyny wirtualnej BEAM, stanowiącej serce każdej aplikacji napisanej w Erlangu i Elixirze [^2].

Atak nie wymaga uwierzytelnienia i może być przeprowadzony przez sieć. Wystarczy wysłanie jednego, specjalnie spreparowanego pakietu. Zagrożenie dotyczy fundamentu technologicznego, na którym działają systemy wymagające ekstremalnej niezawodności — od central telekomunikacyjnych po systemy bankowe i popularne komunikatory. Polskie firmy z sektora telekomunikacyjnego, fintech oraz zespoły deweloperskie używające Elixira powinny potraktować ten alert priorytetowo.

TL;DR

  • Produkt: Erlang/OTP, wersje od 17.0 do 29.x [^1], oraz powiązane wersje erts [^3].
  • Luka: CVE-2026-49759, Stack-based Buffer Overflow [^4].
  • Wektor: Nieautoryzowany, zdalny atak poprzez wysłanie spreparowanego fragmentu SCTP ERROR do nasłuchującego portu [^5] [^6].
  • Skutek: Awaria maszyny wirtualnej BEAM (Denial of Service) [^2] [^7]. Możliwy jest również ograniczony wyciek fragmentów pamięci [^8].
  • Kogo dotyczy: Wszystkich użytkowników podatnych wersji Erlang/OTP. W polskim kontekście są to m.in. firmy telekomunikacyjne, dostawcy usług backendowych, zespoły programistyczne Elixira, operatorzy systemów kolejek (np. RabbitMQ) i baz danych (np. Riak, CouchDB).
  • Pierwszy ruch: Identyfikacja zasobów używających Erlang/OTP i aktualizacja do wersji 27.3.4.13, 28.5.0.2, 29.0.2 lub nowszych [^1].

Wektor ataku

Problem leży w sposobie przetwarzania pakietów protokołu SCTP (Stream Control Transmission Protocol). Jest to protokół warstwy transportowej, podobnie jak TCP i UDP, często używany w telekomunikacji do zapewnienia niezawodnej transmisji komunikatów.

Luka znajduje się w funkcji sctp_parse_error_chunk w sterowniku inet_drv [^9]. Funkcja ta jest odpowiedzialna za parsowanie fragmentów błędu (ERROR chunks) w komunikacji SCTP. Analiza kodu wskazuje, że podczas tego procesu kody przyczyn błędu są zapisywane do tablicy spec[] o stałym rozmiarze, która jest alokowana na stosie [^10]. Kluczowy błąd polega na tym, że operacja zapisu nie weryfikuje, czy liczba otrzymanych kodów przyczyn nie przekracza rozmiaru bufora [^10].

Zdalny atakujący, który nawiązał wcześniej połączenie SCTP z usługą opartą na Erlangu, może wysłać pojedynczy, spreparowany pakiet SCTP ERROR [^6]. Jeśli pakiet ten zawiera wystarczająco dużą liczbę kodów przyczyn, dochodzi do przepełnienia bufora na stosie [^7]. Konsekwencją jest natychmiastowa awaria (crash) całej maszyny wirtualnej BEAM, co prowadzi do ataku typu DoS (Denial of Service – odmowa usługi).

Analiza wskazuje, że możliwości eskalacji ataku do zdalnego wykonania kodu (RCE) są znikome. Atakujący może zapisywać na stosie jedynie 16-bitowe wartości przeplatane stałym znacznikiem (tagiem) [^11]. Taka struktura zapisu uniemożliwia kontrolowane nadpisanie adresu powrotu funkcji, co jest zazwyczaj konieczne do przejęcia kontroli nad przepływem programu [^12]. Głównym i niemal jedynym skutkiem pozostaje więc awaria usługi.

Dodatkowo, zaobserwowano możliwość niewielkiego wycieku informacji. Spreparowany pakiet może spowodować, że fragmenty pamięci z maszyny wirtualnej Erlang zostaną dołączone do komunikatu o błędzie, który jest następnie widoczny dla procesu Erlang nasłuchującego na danym porcie [^8]. Zakres tego wycieku jest jednak ograniczony. Dane te są i tak dostępne dla użytkownika, w którego kontekście działa proces Erlanga, więc nie dochodzi do ujawnienia informacji nowej stronie [^13].

Co zrobić w 24-48h

Rekomendowane podejście zakłada trzy główne kroki. Działania te nie zastępują pełnej konsultacji bezpieczeństwa, ale stanowią pierwszą linię obrony.

  1. Inwentaryzacja zależności. Największym wyzwaniem dla polskich firm, zwłaszcza tych spoza sektora IT, jest świadomość używania Erlanga. Może on być ukrytą zależnością w gotowych produktach. Należy natychmiast zweryfikować:

    • Systemy kolejek komunikatów: RabbitMQ jest napisany w Erlangu. Należy sprawdzić wersję Erlanga, z którą został skompilowany i uruchomiony.
    • Bazy danych: Niektóre systemy NoSQL, jak CouchDB czy Riak, używają Erlanga. Sprawdź dokumentację i wersje komponentów.
    • Aplikacje Elrowe: Elixir kompiluje się do kodu bajtowego dla maszyny wirtualnej BEAM. Każda aplikacja Elowa działa na Erlangu. Zespoły deweloperskie w Polsce powinny sprawdzić wersje OTP w swoich środowiskach deweloperskich, testowych i produkcyjnych (elixir -v).
    • Systemy telekomunikacyjne i VoIP: Historycznie to główna domena Erlanga. Jeśli twoja firma korzysta z własnych lub otwartych rozwiązań w tym obszarze, weryfikacja jest krytyczna.

  2. Aktualizacja Erlang/OTP. Dostawcy opublikowali łatki. Należy zaktualizować środowiska do jednej z bezpiecznych wersji [^1] [^3]:

    • Gałąź OTP 27.x -> 27.3.4.13
    • Gałąź OTP 28.x -> 28.5.0.2
    • Gałąź OTP 29.x -> 29.0.2 W przypadku systemów opartych o kontenery (Docker, Kubernetes), należy przebudować obrazy z nową wersją bazową Erlanga lub Elixira.

  3. Ograniczenie ekspozycji (jeśli aktualizacja jest niemożliwa). Jeśli natychmiastowa aktualizacja nie wchodzi w grę, można rozważyć środki mitygujące. Ponieważ atak wymaga aktywnego połączenia SCTP, można:

    • Zablokować ruch SCTP na poziomie firewalla dla usług, które nie muszą być publicznie dostępne z użyciem tego protokołu.
    • Ograniczyć dostęp do portów SCTP tylko do zaufanych adresów IP. To rozwiązanie tymczasowe. Nie eliminuje luki, a jedynie utrudnia jej wykorzystanie z zewnątrz.

  4. Monitorowanie. Należy monitorować logi systemowe i aplikacyjne pod kątem nieoczekiwanych awarii procesów BEAM (w logach często widoczne jako beam.smp crashed). Nagły, powtarzający się restart usługi może wskazywać na próbę ataku DoS.

Zobacz też