Proto6 w protobuf.js: sześć luk zagraża aplikacjom Node.js podatnym na RCE i DoS

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

Biblioteka protobuf.js jest szeroko wykorzystywana w środowiskach JavaScript i TypeScript do serializacji oraz deserializacji danych opartych na Protocol Buffers. Zidentyfikowany zestaw sześciu podatności, określany zbiorczo jako Proto6, pokazuje jednak, że niewłaściwe zaufanie do schematów, deskryptorów i metadanych wejściowych może prowadzić do bardzo poważnych skutków bezpieczeństwa.

Problem dotyczy nie tylko klasycznych awarii parsera. W części scenariuszy luki umożliwiają odmowę usługi, a w najgroźniejszych przypadkach także zdalne wykonanie kodu JavaScript w procesie Node.js lub wstrzyknięcie złośliwej logiki do wygenerowanych artefaktów.

W skrócie

Proto6 obejmuje sześć podatności w protobuf.js oraz powiązanych narzędziach CLI.
Najpoważniejsze skutki to RCE, DoS, awarie usług i kompromitacja pipeline’ów CI/CD.
Problem obejmuje między innymi protobuf.js do wersji 7.5.5 oraz 8.0.0–8.0.1.
Poprawki opublikowano w wersjach 7.5.6 i 8.0.2.
Dla protobufjs-cli za bezpieczne uznawane są wersje 1.2.1 oraz 2.0.2.

Kontekst / historia

Protocol Buffers od lat stanowi jeden z podstawowych formatów wymiany ustrukturyzowanych danych pomiędzy usługami, klientami API, brokerami wiadomości i komponentami chmurowymi. W praktyce protobuf.js jest często głęboko osadzony w stosie aplikacyjnym, od backendów Node.js po narzędzia automatyzujące budowanie i wdrażanie oprogramowania.

Współczesne środowiska deweloperskie coraz częściej traktują schematy i pliki konfiguracyjne jako dane zaufane, mimo że pochodzą one z repozytoriów, integracji partnerskich, kolejek komunikatów czy procesów CI/CD. To właśnie ten model zaufania okazał się kluczowy dla ryzyka związanego z Proto6.

Zidentyfikowane podatności oznaczono jako CVE-2026-44289, CVE-2026-44290, CVE-2026-44291, CVE-2026-44292, CVE-2026-44294 oraz CVE-2026-44295. Obejmują one zarówno błędy prowadzące do awarii procesów, jak i przypadki umożliwiające wstrzyknięcie kodu podczas generowania lub obsługi struktur Protobuf.

Analiza techniczna

Źródłem problemu jest założenie, że nazwy pól, opcje, identyfikatory i inne metadane przekazywane do protobuf.js są bezpieczne. W niektórych ścieżkach wykonania biblioteka używa tych danych do budowy struktur runtime albo generowania funkcji odpowiedzialnych za kodowanie i dekodowanie wiadomości.

Jeżeli wartości wejściowe nie są odpowiednio ograniczane i walidowane, dane przestają być biernym nośnikiem informacji, a zaczynają wpływać na logikę działania aplikacji. Taki model otwiera drogę do kilku klas błędów, które w ramach Proto6 przyjmują szczególnie niebezpieczną postać.

nieograniczona rekursja prowadząca do wyczerpania stosu i zatrzymania procesu,
niebezpieczne ścieżki opcji skutkujące DoS na poziomie całej aplikacji,
wykorzystanie prototype pollution jako elementu łańcucha prowadzącego do code generation,
wstrzyknięcie właściwości do generowanych konstruktorów wiadomości,
awarie generowanego kodu wywołane spreparowanymi nazwami pól,
bezpośrednie wstrzyknięcie kodu do statycznego wyjścia pbjs przy użyciu złośliwie przygotowanych nazw schematów.

Najgroźniejszy scenariusz techniczny dotyczy połączenia wcześniejszego zanieczyszczenia prototypu z mechanizmami generowania kodu. Jeśli aplikacja rozwiązuje typy przez odwołania do właściwości obiektów dziedziczących po prototypie, kontrolowany przez atakującego wpis może zostać potraktowany jako prawidłowy typ prosty. W efekcie złośliwy ciąg znaków może trafić do generowanej funkcji i zostać wykonany w kontekście procesu Node.js.

Osobną kategorię stanowią ryzyka związane z narzędziem pbjs i generowaniem statycznego kodu. Jeżeli pipeline kompiluje schematy pochodzące z niezaufanych źródeł, odpowiednio spreparowane nazwy mogą doprowadzić do wygenerowania artefaktów zawierających niepożądane instrukcje. W praktyce oznacza to zagrożenie dla sekretów buildowych, tokenów dostępowych czy kluczy API obecnych w środowisku CI/CD.

Konsekwencje / ryzyko

Skutki biznesowe i operacyjne zależą od sposobu wykorzystania protobuf.js, ale potencjalny wpływ jest bardzo szeroki. W aplikacjach internetowych przyjmujących niezaufane komunikaty Protobuf najprostszym skutkiem może być zdalne unieruchomienie usługi, co bezpośrednio przekłada się na utratę dostępności.

W architekturach opartych na kolejkach, gRPC lub komunikacji międzyserwisowej awaria jednego komponentu może propagować się dalej i destabilizować większą część platformy. Jeszcze poważniejszy jest scenariusz RCE, w którym atakujący uzyskuje możliwość wykonania własnych instrukcji w procesie Node.js, a następnie kradzieży sekretów środowiskowych, modyfikacji danych, uruchamiania poleceń systemowych lub dalszego ruchu bocznego.

Wysokie ryzyko dotyczy również łańcucha dostaw oprogramowania. Organizacje automatycznie pobierające i kompilujące schematy Protobuf mogą narazić się na kompromitację samego procesu budowania. Jest to szczególnie istotne dla środowisk chmurowych, platform danych, usług AI oraz rozwiązań integracyjnych, gdzie schematy są intensywnie wymieniane pomiędzy wieloma systemami.

Rekomendacje

Najważniejszym krokiem jest szybkie ustalenie, czy w środowiskach produkcyjnych, testowych i buildowych używane są podatne wersje protobuf.js lub protobufjs-cli. Jeśli tak, aktualizacja powinna zostać potraktowana priorytetowo.

zaktualizować protobuf.js co najmniej do wersji 7.5.6 albo 8.0.2,
zaktualizować protobufjs-cli co najmniej do wersji 1.2.1 albo 2.0.2,
traktować schematy Protobuf, deskryptory i pliki konfiguracyjne jako dane niezaufane,
ograniczyć możliwość dostarczania własnych schematów przez użytkowników i partnerów,
wprowadzić walidację nazw pól, opcji i identyfikatorów przed etapem generowania kodu,
odseparować proces deserializacji i code generation od krytycznych komponentów aplikacji,
monitorować nietypowe restarty procesów Node.js, błędy stosu i anomalie w pipeline’ach,
przeprowadzić przegląd aplikacji pod kątem wcześniejszych błędów prototype pollution,
ograniczyć uprawnienia środowisk CI/CD oraz usunąć z nich nadmiarowe sekrety.

Zespoły bezpieczeństwa powinny również skanować zależności pośrednie. protobuf.js często występuje jako składnik innych bibliotek i frameworków, dlatego brak bezpośredniej deklaracji zależności nie oznacza automatycznie braku podatności. Warto też przeanalizować wcześniej wygenerowane artefakty, jeśli schematy były kompilowane z mniej kontrolowanych źródeł.

Podsumowanie

Proto6 pokazuje, że granica między danymi a wykonywalnym zachowaniem aplikacji staje się coraz cieńsza. W przypadku protobuf.js problem nie sprowadza się wyłącznie do błędów parsera, lecz dotyczy samego modelu zaufania do schematów i metadanych.

Organizacje korzystające z Node.js, Protocol Buffers i zautomatyzowanych pipeline’ów powinny potraktować tę klasę podatności bardzo poważnie. Szybka aktualizacja, ścisła kontrola źródeł schematów i ograniczenie zaufania do wejścia pozostają najważniejszymi elementami obrony.