CVE-2026-1245 w bibliotece binary-parser (npm): wstrzyknięcie kodu i wykonanie dowolnego JavaScript w Node.js - Security Bez Tabu

CVE-2026-1245 w bibliotece binary-parser (npm): wstrzyknięcie kodu i wykonanie dowolnego JavaScript w Node.js

Wprowadzenie do problemu / definicja luki

CERT/CC opublikował notę o podatności CVE-2026-1245 w popularnej bibliotece binary-parser dla Node.js. Problem ma charakter code injection: jeśli aplikacja buduje definicję parsera z danych pochodzących od użytkownika lub z zewnętrznego, niezaufanego źródła, atakujący może doprowadzić do wykonania dowolnego kodu JavaScript w kontekście procesu Node.js.

W skrócie

  • Co jest podatne: binary-parser w wersjach < 2.3.0.
  • Warunek eksploatacji: aplikacja musi używać niezaufanych wartości do konstruowania definicji parsera (np. nazwy pól lub parametry encoding).
  • Skutek: wykonanie kodu w uprawnieniach procesu Node.js (potencjalnie odczyt danych lokalnych, manipulacja logiką, a w niektórych wdrożeniach także uruchamianie poleceń systemowych).
  • Ocena ryzyka (CVSS): w ekosystemie NVD widnieje 6.5 (Medium) z wektorem CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N (wartość dostarczona przez CISA-ADP).
  • Naprawa: aktualizacja do 2.3.0+.

Kontekst / historia / powiązania

Biblioteka binary-parser jest używana do deklaratywnego opisu struktur binarnych (np. protokoły, pliki binarne) i budowania wydajnych parserów w JavaScript. CERT/CC wskazuje, że problem wynika z podejścia implementacyjnego: biblioteka generuje kod JS w locie.

Co istotne czasowo:

  • Patch został zmergowany w repozytorium 26 listopada 2025 (PR #283).
  • Nota CERT/CC ma datę publikacji 20 stycznia 2026 (z rewizją 21 stycznia 2026).
  • Artykuł opisujący temat szerzej pojawił się m.in. 21 stycznia 2026.

Analiza techniczna / szczegóły luki

Gdzie tkwi błąd?

binary-parser (w wersjach < 2.3.0) buduje łańcuch źródłowego kodu JavaScript, a następnie kompiluje go przez Function constructor. Wrażliwe parametry – w szczególności nazwy pól parsera oraz parametry encoding – mogły zostać wstrzyknięte do generowanego kodu bez walidacji/sanitizacji.

Dlaczego to „tylko czasem” jest RCE?

CERT/CC podkreśla, że aplikacje z definicjami statycznymi, hardcoded (np. parser opisany w kodzie i niebudowany z wejścia użytkownika) nie są podatne. Ryzyko pojawia się dopiero, gdy:

  • definicje parsera są składane dynamicznie, oraz
  • do tych definicji trafiają wartości od użytkownika / z zewnętrznych źródeł (np. z danych sieciowych).

Co zmieniła poprawka?

Fix został wdrożony w ramach PR #283 (z datą merge 26.11.2025), a CERT/CC wskazuje na aktualizację do 2.3.0 jako rozwiązanie, obejmujące m.in. mechanizmy ograniczające niebezpieczną generację kodu.

Praktyczne konsekwencje / ryzyko

Jeśli warunki eksploatacji są spełnione, atakujący może wykonać kod w uprawnieniach procesu Node.js, co w praktyce może oznaczać:

  • dostęp do danych lokalnych widocznych dla procesu (sekrety, pliki konfiguracyjne, cache),
  • manipulację przebiegiem aplikacji (np. obejście logiki, fałszowanie wyników parsowania),
  • w zależności od środowiska uruchomieniowego – potencjalnie także wykonanie komend systemowych (np. przez funkcje i biblioteki dostępne w aplikacji).

Na poziomie oceny podatności NVD opis wskazuje na code injection prowadzące do wykonania kodu w kontekście procesu Node.js, gdy niezaufane wartości trafią do nazw pól lub encoding.

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj binary-parser do wersji 2.3.0 lub nowszej
    To podstawowa rekomendacja CERT/CC i status „patched” w bazie GitHub Advisory.
  2. Zablokuj dopływ niezaufanych danych do definicji parsera
    Nawet po aktualizacji, traktuj definicje parserów jako „kod”:
    • nie składaj nazw pól z danych wejściowych,
    • nie pozwalaj użytkownikowi sterować encoding (lub whitelista tylko bezpiecznych wartości),
    • stosuj schematy/kontrakty danych i walidację na wejściu.
  3. Szybka triage: sprawdź, czy w ogóle spełniasz warunki podatności
    • wyszukaj w kodzie miejsca, gdzie definicje parsera są budowane dynamicznie,
    • sprawdź, czy do .string(...), .array(...) lub podobnych konstruktorów trafiają wartości z requestów/API/plików użytkownika,
    • zidentyfikuj przepływ danych (data-flow) od wejścia do definicji parsera.
  4. Wzmocnij „blast radius” procesu Node.js
    • uruchamiaj z minimalnymi uprawnieniami,
    • ogranicz dostęp do systemu plików (kontenery, polityki, profile),
    • ogranicz sekrety w środowisku procesu i stosuj rotację.
      (To dobra praktyka na wypadek każdej podatności typu RCE.)

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Ten przypadek jest podręcznikowym przykładem ryzyka związanego z dynamiczną generacją kodu (eval/Function). Nawet jeśli intencją jest optymalizacja (kompilacja parsera do funkcji), bezpieczeństwo zaczyna zależeć od tego, czy cokolwiek z zewnątrz może wpłynąć na fragmenty składniowe generowanego kodu. CERT/CC opisuje to wprost: niezneutralizowane dane w nazwach pól i encoding mogą zmienić znaczenie generowanego kodu.

Podsumowanie / kluczowe wnioski

  • CVE-2026-1245 dotyczy binary-parser < 2.3.0 i sprowadza się do code injection przez elementy definicji parsera.
  • Podatne są głównie aplikacje, które budują definicje parserów z niezaufanych danych; statyczne definicje są poza zasięgiem tego scenariusza.
  • Najszybsza i zalecana ścieżka: update do 2.3.0+ oraz eliminacja niezaufanego wpływu na nazwy pól/encoding.

Źródła / bibliografia

  • CERT/CC – Vulnerability Note VU#102648 (binary-parser, code injection) (kb.cert.org)
  • NVD – CVE-2026-1245 (nvd.nist.gov)
  • GitHub Advisory Database – GHSA-m39p-34qh-rh3w / CVE-2026-1245 (GitHub)
  • PR #283 w repozytorium keichi/binary-parser (merge 26.11.2025) (GitHub)
  • The Hacker News – opis podatności i zalecenia aktualizacji (The Hacker News)