CVE-2026-41257

Funkcja jv_dump_term w jq 1.5 umożliwia zdalnym atakującym spowodowanie odmowy usługi poprzez przygotowany plik JSON, co prowadzi do zużycia stosu i awarii aplikacji. Problem został naprawiony w jq 1.6_rc1-r0.

Funkcja decNumberCopy w pliku decNumber.c w jq do wersji 1.7.1 nieprawidłowo traktuje wartość NaN jako liczbową, co prowadzi do przepełnienia bufora na stosie i zapisu poza zakresem. Problem można wykorzystać na przykład przez użycie opcji --slurp z operacją odejmowania, taką jak filtr .-. przy odpowiednio spreparowanym wejściu.

Błąd off-by-one w funkcji tokenadd w pliku jv_parse.c w jq umożliwia zdalnym atakującym spowodowanie awarii (denial of service) poprzez długi, zakodowany w JSON numer, co prowadzi do przepełnienia bufora w pamięci heap.

W jq w wersji 1.8.1 i wcześniejszych ścieżki importu akceptują osadzone bajty NUL na poziomie języka jq, ale podczas wyszukiwania modułów i plików danych są one przetwarzane przez operacje na łańcuchach C. Powstaje rozbieżność między logicznym łańcuchem importu a rzeczywistą ścieżką otwieraną na dysku.

W jq w wersji 1.8.1 i wcześniejszych funkcja decNumberFromString przy literale liczbowym o długości INT_MAX-1 (2147483646) cyfr powoduje przepełnienie makra D2U() w arytmetyce ze znakiem. Zawinięta wartość ujemna omija sprawdzenie rozmiaru alokacji sterty i prowadzi do zapisu około 1,4 GiB danych kontrolowanych przez atakującego poza bufor stosu.

W jq w wersji 1.8.1 i wcześniejszych programy jq najwyższego poziomu ładowane z pliku przez opcję -f są obcinane na pierwszym osadzonym bajcie NUL. Spreparowany plik filtra może zostać skompilowany i wykonany tylko jako prefiks przed bajtem NUL, co pozostawia niespójność między prefiksem a pełnym buforem na ścieżce kompilacji.

jq przed commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784 używało MurmurHash3 z zakodowanym na stałe, publicznie widocznym ziarnem (0x432A9843) dla wszystkich operacji na tablicach mieszających obiektów JSON. Umożliwiło to atakującemu wstępne obliczenie kolizji kluczy offline i dostarczenie spreparowanego obiektu JSON (~100 KB), w którym wszystkie klucze trafiają do tego samego koszyka, powodując degradację wyszukiwania z O(1) do O(n) i wyczerpanie CPU.

jq to procesor JSON wiersza poleceń. Commity przed 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b zawierają podatność, w której parsowanie danych wejściowych CLI pozwala na obejście walidacji poprzez osadzone bajty NUL. Podczas czytania JSON z plików lub standardowego wejścia jq używa strlen() do określenia długości bufora zamiast rzeczywistej liczby bajtów z fgets(), co powoduje obcięcie danych wejściowych na pierwszym bajcie NUL i parsowanie tylko poprzedzającego prefiksu. Umożliwia to atakującemu stworzenie danych wejściowych z nieszkodliwym prefiksem JSON przed bajtem NUL, po którym następują złośliwe dane końcowe, gdzie jq waliduje tylko prefiks jako poprawny JSON, jednocześnie po cichu odrzucając sufiks. Przepływy pracy polegające na jq do walidacji niezaufanego JSON przed przekazaniem go do dalszych odbiorców są podatne na ataki różnic parserów, ponieważ ci odbiorcy mogą przetwarzać pełne dane wejściowe, w tym złośliwe końcowe bajty. Problem został załatany commitem 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b.

W bibliotece libjq (część narzędzia jq) w funkcji jv_parse_sized() występuje podatność na odczyt poza zakresem bufora. Podczas przetwarzania błędnego JSON-a w buforze niezakończonym znakiem NUL, funkcja formatująca błąd używa %s, które czyta dane aż do napotkania NUL-a, zamiast ograniczyć się do długości podanej przez wywołującego.

jq przed wersją 1.8.2 zawiera podatność w wbudowanej funkcji _strindices, która przekazuje argumenty do jv_string_indexes() bez weryfikacji, czy są one stringami. Funkcja jv_string_indexes() polega wyłącznie na asercjach, które są usuwane w wersjach release kompilowanych z -DNDEBUG. Atakujący może spowodować awarię jq, np. przez _strindices(0), a także uzyskać kontrolowany dereferencję wskaźnika i ograniczony odczyt pamięci.