CVE-2026-116570

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 msrp_parse_buffer() odejmowała ramkowanie separatora od kontrolowanego przez peera krótkiego segmentu, którego zakres bajtów MSRP kończył się na *, bez uprzedniego sprawdzenia, czy segment jest wystarczająco długi. Wynik bez znaku zawijał się w pobliżu SIZE_MAX i trafiał do switch_msrp_msg_set_payload() zarówno jako rozmiar alokacji, jak i długość memcpy, a powiązana arytmetyka wskaźników mogła odczytywać przed buforem odbiorczym. Nasłuch jest domyślnie wyłączony w msrp.conf.xml, ale każde wdrożenie z włączonym portem MSRP TCP lub TLS przetwarza to ramkowanie przed uwierzytelnieniem.

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.