CVE-2026-116569

W FreeSWITCH przed wersją 1.11.2 funkcja dtls_state_setup() porównuje certyfikat peera z odciskiem SDP a=fingerprint tylko gdy FreeSWITCH jest klientem DTLS, a nie gdy pełni rolę serwera. Nieuwierzytelniony peer może ukończyć handshake DTLS-SRTP z niepowiązanym certyfikatem, uzyskać klucze SRTP i wstrzykiwać media.

W FreeSWITCH przed wersją 1.11.2 w switch_xml_decode() występuje niedomiar liczby całkowitej powodujący zbyt małą alokację sterty, gdy dokument XML deklaruje encję z pustą wartością zastępczą. Kolejne kopiowanie przepełnia bufor.

W FreeSWITCH przed wersją 1.11.2 mod_event_socket używa nieuwierzytelnionej wartości Content-Length bezpośrednio jako rozmiaru alokacji treści wiadomości Event Socket. Wartości ujemne lub bardzo duże mogą przepełnić obliczenia terminatora lub wymusić błąd alokacji kończący proces.

W FreeSWITCH przed wersją 1.11.2 funkcja sofia_handle_sip_i_refer() umieszcza surowe parametry i nagłówki URI Refer-To w bloku zmiennych kanału przekazywanym do switch_ivr_originate(). Przecinek w wartości kontrolowanej przez atakującego jest traktowany jako separator zmiennych, co pozwala uwierzytelnionemu dzwoniącemu wstrzyknąć dowolne zmienne do nowo tworzonego legu.

W FreeSWITCH przed wersją 1.11.2 funkcja process_rtcp_report() używała zadeklarowanej w pakiecie RTPFB NACK długości nagłówka RTCP jako granicy pętli przetwarzania wpisów zwrotnych, zamiast zweryfikowanej wcześniej długości datagramu. Krótki pakiet z zawyżoną deklaracją mógł powodować odczyty daleko poza buforem odbiorczym o stałym rozmiarze 16 KiB. Każdy peer mogący wysłać RTCP do aktywnej rozmowy wideo może wykorzystać tę podatność.

W FreeSWITCH przed wersją 1.11.2 funkcja udptl_rx_packet() używała kontrolowanej przez peera liczby wpisów FEC bezpośrednio do wypełniania pięcioelementowych tablic FEC w sesji T.38 mod_spandsp. Większa liczba powodowała zapis danych kontrolowanych przez nadawcę poza tymi tablicami i utrwalenie zawyżonej liczby do późniejszego etapu rekonstrukcji. Każdy peer mogący dostarczyć UDPTL do ustanowionej sesji faksu T.38 może wykorzystać tę podatność.

W FreeSWITCH przed wersją 1.11.2 funkcja rtmp_i_connect() przekazywała pierwszy argument połączenia RTMP do amf0_object_get() bez sprawdzenia, czy wartość AMF jest obiektem. Ciąg znaków lub liczba w miejscu obiektu AMF powodowały interpretację bajtów unii z wiadomości jako wskaźników do węzłów i ich dereferencję. Każdy klient z dostępem sieciowym do włączonego nasłuchu mod_rtmp mógł wysłać zniekształcone polecenie połączenia przed logowaniem; moduł jest domyślnie wyłączony w standardowej kompilacji i konfiguracji.

W FreeSWITCH przed wersją 1.11.2 funkcja http_directory_auth() odtwarzała oczekiwane poświadczenia user@domain:password i kodowała je base64 do bufora o rozmiarze 80 bajtów przy użyciu kodera bez argumentu długości wyjściowej. Poświadczenie dłuższe niż 57 znaków powodowało przepełnienie stosu przed porównaniem dostarczonego hasła HTTP Basic. Nieuwierzytelniony klient musiał jedynie wskazać istniejącego użytkownika katalogu na wystawionym nasłuchu HTTP mod_xml_rpc; moduł jest kompilowany, ale nie ładowany w standardowej konfiguracji.

W FreeSWITCH przed wersją 1.11.2 funkcja rtmp_rtmp2rtpH264() ufała prefiksowi długości każdej przychodzącej jednostki NAL H.264 bez sprawdzenia go względem pozostałych bajtów w wiadomości RTMP. Zawyżona zadeklarowana jednostka powodowała niedomiar licznika pozostałych bajtów bez znaku i przesunięcie parsera poza bufor odbiorczy, gdzie kolejny odczyt prefiksu długości mógł spowodować awarię procesu. Podatność dotyczy wdrożeń, które kompilują i ładują mod_rtmp oraz akceptują sesje rozmów wideo, zwykle na porcie TCP 1935; ustanowienie połączenia wymaga logowania do katalogu, gdy auth-calls jest true, natomiast nie wymaga poświadczeń, gdy auth-calls jest nieobecne lub false.

W FreeSWITCH przed wersją 1.11.2 funkcja rtmp_handle_control() kopiuje treść komunikatu RTMP user-control do bufora stosu o rozmiarze 200 bajtów za pomocą niezabezpieczonej pętli sprintf sterowanej długością komunikatu. Komunikat o długości około 70 bajtów lub większej powoduje przepełnienie stosu jeszcze przed logowaniem RTMP, ponieważ handshake nie uwierzytelnia żadnej ze stron. Podatność dotyczy wdrożeń z modułem mod_rtmp, który domyślnie jest wyłączony, ale po włączeniu często nasłuchuje na porcie TCP 1935.