CVE-2026-44645
ŚrednieCVSS 6.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 23 - wyżej niż 23% wszystkich znanych CVE
Streszczenie
W wersjach 10.25.7 i poniżej silnika szablonów LiquidJS istnieje możliwość całkowitego obejścia opcji renderLimit poprzez użycie pustego tagu {% for %} lub {% tablerow %}. To pozwala na nieograniczone zużycie czasu renderowania, co może prowadzić do ataków typu DoS.
Ocena ryzyka
Organizacje korzystające z LiquidJS w wersjach 10.25.7 i poniżej mogą być narażone na ataki DoS, które mogą zablokować wątki pętli zdarzeń Node.js, co prowadzi do problemów z dostępnością aplikacji.
Rekomendacja
Zaleca się aktualizację do wersji 10.26.0 lub nowszej, aby zabezpieczyć się przed tym problemem oraz rozważyć dodatkowe mechanizmy ochrony przed atakami DoS.
Inne podatności w LiquidJS
Zobacz wszystkie- CVE-2026-45618Krytyczne
LiquidJS to silnik szablonów zgodny z Shopify/GitHub Pages. Przed wersją 10.26.0 możliwe jest wykonanie dowolnego kodu za pomocą spreparowanych szablonów. Wersja 10.26.0 naprawia ten problem.
- CVE-2026-69222Wysokie
W LiquidJS przed wersją 10.27.2 filtr join w src/filters/array.ts oblicza złożoność na podstawie długości tablicy i separatora, a nie całkowitej długości wygenerowanego ciągu. Filtr concat może tanio podwajać tablice referencji, a następnie join materializuje treść, obciążając tylko liczbę elementów, co pozwala przekroczyć skonfigurowany memoryLimit. Podobny problem ma filtr array_to_sentence_string, co może prowadzić do awarii procesu.
- CVE-2026-61556Wysokie
W LiquidJS od wersji 10.26.0 do 10.27.1 filtr strip_html w src/filters/html.ts może wejść w nieskończoną pętlę, gdy wejściowy ciąg zawiera '<', ma co najmniej jeden poprzedzający znak i nie ma późniejszego '>'. Powoduje to zablokowanie renderowania szablonu i może prowadzić do odmowy usługi przy bardzo krótkim wejściu, np. 'a<'.
- CVE-2026-55575Wysokie
W bibliotece LiquidJS przed wersją 10.27.1 filtr 'pop' alokuje pełną kopię tablicy wejściowej bez uwzględniania limitu pamięci (memoryLimit). Pozwala to na wykonanie szablonu, który alokuje poza budżetem pamięci, np. przez {{ huge_array | pop }}.
- CVE-2026-45617Wysokie
LiquidJS to silnik szablonów kompatybilny z Shopify/GitHub Pages, który w wersjach 10.25.7 i poniżej zawiera filtr strip_html z błędnym wyrażeniem regularnym. To prowadzi do ataku ReDoS poprzez kwadratowe cofanie, co blokuje pętlę zdarzeń Node.js.
- CVE-2026-45357Wysokie
W wersjach 10.25.7 i poniżej silnika szablonów LiquidJS występuje podatność związana z filtrem daty, który nieprawidłowo przetwarza specyfikatory szerokości, co prowadzi do nieograniczonego łączenia ciągów i omijania limitów pamięci oraz renderowania.
- CVE-2026-44646Średnie
W wersjach 10.25.7 i poniżej silnik szablonów LiquidJS nieprawidłowo propaguje wartość ownPropertyOnly z kontekstu nadrzędnego, co prowadzi do cichego obejścia zabezpieczeń. W rezultacie, deweloperzy mogą nieświadomie ujawniać właściwości z łańcucha prototypów w niebezpiecznych renderach.
- CVE-2026-44644Średnie
LiquidJS, silnik szablonów kompatybilny z Shopify/GitHub Pages, ma podatność na XSS w wersjach 10.25.7 i poniżej z powodu błędu w logice filtru strip_html. Błąd ten pozwala na ominięcie sanitizacji HTML, co umożliwia atakującym wstrzykiwanie złośliwego kodu.
- CVE-2026-41311Wysokie
LiquidJS przed wersją 10.25.7 zawiera podatność na atak DoS poprzez cykliczne odwołania bloków w {% layout %} / {% block %}, co powoduje wyczerpanie pamięci i awarię procesu Node.js.
- CVE-2026-39859Wysokie
LiquidJS przed wersją 10.25.3 ma podatność, która pozwala na odczyt dowolnych plików. Mimo że root jest ustawiony na ograniczenie dostępu, ładowanie plików najwyższego poziomu nie egzekwuje tego ograniczenia. Instancja Liquid skonfigurowana z pustym katalogiem tymczasowym jako root może zwrócić zawartość dowolnych plików.
Oryginalny opis (angielski, źródło NVD)
LiquidJS is a Shopify/GitHub Pages compatible template engine written in pure JavaScript. In versions 10.25.7 and below, the renderLimit option can be fully bypassed by a {% for %} (or {% tablerow %}) tag whose body is empty. The renderLimit option is documented in docs/source/tutorials/dos.md as the mechanism that "mitigates this by limiting the time consumed by each render() call." The per-iteration time check is reached only when the body contains at least one template node, so a template such as {%- for i in (1..N) -%}{%- endfor -%} iterates the full collection without ever consulting renderLimit. With a configured renderLimit of 50 ms, a single parseAndRenderSync call has been observed to consume 2.26 seconds (~45× over the limit) and scales linearly with N up to memoryLimit, allowing a low-privileged template author to wedge an event-loop thread for an attacker-chosen duration. Deployments that rely on a finite renderLimit for DoS protection (common in multi-tenant template-authoring environments) can still be forced by a single crafted template to monopolize a Node.js event-loop worker for attacker-controlled time, potentially stalling in-flight requests, with availability impact only. This issue has been fixed in version 10.26.0.