CVE-2026-40164
WysokieCVSS 7.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 29 - wyżej niż 29% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Atak jest łatwy do przeprowadzenia (mały payload) i może prowadzić do znacznego obciążenia CPU, co wpływa na działanie potoków CI/CD, usług sieciowych i skryptów przetwarzających dane, powodując odmowę usługi.
Rekomendacja
Należy natychmiast zaktualizować jq do wersji zawierającej commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784 lub nowszej, aby wyeliminować podatność na ataki kolizyjne.
Inne podatności w jq
Zobacz wszystkie- CVE-2016-4074Wysokie
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.
- CVE-2024-53427Średnie
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.
- CVE-2015-8863Krytyczne
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.
- CVE-2026-33948Średnie
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.
- CVE-2026-39979Średnie
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.
- CVE-2026-39956Średnie
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.
Oryginalny opis (angielski, źródło NVD)
jq is a command-line JSON processor. Before commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784, jq used MurmurHash3 with a hardcoded, publicly visible seed (0x432A9843) for all JSON object hash table operations, which allowed an attacker to precompute key collisions offline. By supplying a crafted JSON object (~100 KB) where all keys hashed to the same bucket, hash table lookups degraded from O(1) to O(n), turning any jq expression into an O(n²) operation and causing significant CPU exhaustion. This affected common jq use cases such as CI/CD pipelines, web services, and data processing scripts, and was far more practical to exploit than existing heap overflow issues since it required only a small payload. This issue has been patched in commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

