CVE-2026-86249

Podatność na zdalne wstrzyknięcie poleceń w wbudowanej usłudze profilera sterty w Apache bRPC (wszystkie wersje < 1.15.0) na wszystkich platformach umożliwia atakującemu wstrzyknięcie zdalnego polecenia. Przyczyną jest to, że wbudowana usługa profilera sterty bRPC (/pprof/heap) nie waliduje parametru extra_options dostarczonego przez użytkownika i wykonuje go jako argument wiersza poleceń. Atakujący mogą wykonywać zdalne polecenia za pomocą parametru extra_options. Dotyczy to scenariuszy użycia wbudowanej usługi profilera sterty bRPC do profilowania pamięci jemalloc. Naprawa: 1. Zaktualizuj bRPC do wersji 1.15.0. 2. Zastosuj poprawkę ręcznie (https://github.com/apache/brpc/pull/3101).

W kliencie MySQL biblioteki Apache bRPC występuje dereferencja wskaźnika null podczas przetwarzania odpowiedzi serwera o zerowej długości ładunku. Pakiet o zadeklarowanej długości zero przechodzi kontrolę ramki, a następnie parser odczytuje bajt typu odpowiedzi przez nieograniczone pobranie 5 bajtów, które zwraca nullptr, co powoduje odczyt p[4] i awarię procesu klienta.

Podatność w parserze odpowiedzi usługi nazewniczej Discovery w Apache bRPC (wersje < 1.18.0) polega na wywoływaniu akcesorów RapidJSON przeznaczonych wyłącznie dla obiektów (FindMember) na wartościach JSON bez uprzedniego sprawdzenia ich typu. Zniekształcona odpowiedź Discovery, zawierająca nie-obiektowe wpisy w polach data/service lub na liście instancji, powoduje odczyt pamięci poza granicami i potencjalną awarię klienta bRPC.

Apache bRPC w wersji < 1.18.0 udostępnia wbudowane usługi /flags i /pprof, które pozwalają zdalnemu atakującemu na zmianę ścieżek zrzutu (bvar_dump_file, bvar_dump_tabs, mbvar_dump_file) i tworzenie katalogów lub nadpisywanie plików z uprawnieniami procesu serwera. Dodatkowo parametr ?seconds= w /pprof nie jest ograniczany, co umożliwia blokowanie procesowego profilera CPU na dowolnie długi czas.

Podatność typu HTTP request/response smuggling w bibliotece Apache bRPC w wersji < 1.18.0 wynika z niespójnej interpretacji nagłówków HTTP/1.1 przez wbudowany parser. bRPC akceptuje nieprawidłowe formy nagłówków (spacje przed dwukropkiem, spacje w wartościach Content-Length, obs-fold, traktowanie trailerów chunked jako nagłówków, listy Transfer-Encoding z odstępami), co pozwala atakującemu na przemycenie żądań lub nagłówków, gdy bRPC działa za proxy lub load balancerem.

W Apache bRPC (wersje < 1.18.0) występuje nieprawidłowa autoryzacja, która pozwala zdalnym atakującym na dostęp do usług wbudowanych przez port publiczny. Ścieżki protokołów opartych na protobuf nie egzekwowały flagi security_mode, umożliwiając wywołanie usług takich jak brpc.vars lub hotspots.

Podatność w Apache bRPC (wersje < 1.18.0) wynika z niezgodności interpretacji ścieżek HTTP między bRPC a frontowym proxy. Funkcja FindMethodPropertyByURI() pomija puste segmenty ścieżki (podwójne ukośniki), przez co ścieżki takie jak //flags są traktowane jak /flags, mimo że wg RFC 3986 są to różne ścieżki. Dodatkowo HTTP/2 nie waliduje pseudo-nagłówka :path, co pozwala na obejście reguł ACL proxy i dostęp do usług wewnętrznych.

W implementacji protokołu RTMP w Apache bRPC (wersja < 1.18.0) występuje użycie po zwolnieniu pamięci (use-after-free). Złośliwy peer RTMP może wysłać spreparowaną wiadomość Abort, powodując awarię procesu lub potencjalne uszkodzenie pamięci. Przyczyną jest usunięcie obiektu RtmpChunkStream przez wątek odbiorczy podczas gdy wątek wysyłający jednocześnie go używa bez synchronizacji.

Podatność w implementacji protokołu RTMP w Apache bRPC (wersje < 1.18.0) polega na dereferencji wskaźnika NULL, gdy serwer odrzuca żądanie createStream, zwracając null stream, a następnie próbuje wysłać odpowiedź błędu, co może spowodować awarię serwera. Atakujący może zdalnie wywołać odmowę usługi, wysyłając specjalnie spreparowane polecenie createStream i zamykając połączenie przed wysłaniem odpowiedzi.

Wyścig danych w transporcie RDMA Apache bRPC (wersje < 1.18.0) pozwala zdalnemu klientowi zawiesić proces serwera (odmowa usługi), gdy RDMA jest włączone podczas kompilacji i działania. Po zakończeniu uzgadniania RDMA serwer nadal przetwarza gniazdo TCP jako kanał RPC, współdzieląc bez synchronizacji bufory wejściowe i stan parsera z przetwarzaniem zdarzeń RDMA, co prowadzi do uszkodzenia danych i awarii.