CVE-2026-82749

Podatność w bibliotece Ash pozwala użytkownikowi ustawić wartość prywatnego argumentu akcji na ścieżkach masowego usuwania i masowej aktualizacji. Argumenty zadeklarowane jako public?: false powinny być ustawiane tylko przez zaufany kod serwerowy, ale brak sprawdzenia public? w tych ścieżkach umożliwia ich modyfikację z danych wejściowych użytkownika.

W Ash przed wersją 3.33.4, polityki pól (field_policies) mają chronić przed ujawnianiem informacji przez filtry, ale nilling (zastępowanie wartością nil) był stosowany tylko do atrybutów, nie do obliczeń (calculations) ani agregatów (aggregates). Użytkownik może odwołać się w filtrze do obliczenia lub agregatu, którego nie może zobaczyć, i użyć filtra jako wyroczni do odczytania chronionej wartości (np. filter(secret_calc == "x")).

Nieprawidłowa walidacja określonej ilości w danych wejściowych w ash-project ash pozwala atakującemu na przechowywanie wartości o dowolnym rozmiarze w atrybucie, którego ograniczenie długości powinno ją ograniczać. Ash mierzy długość stringa za pomocą String.length/1 z Elixira, która liczy grafy Unicode, w ograniczeniach max_length i min_length Ash.Type.String, w Ash.Resource.Validation.StringLength oraz w funkcji wyrażenia string_length. Graf może zawierać nieograniczoną liczbę znaków łączących, więc podstawowy znak z milionem akcentów ostrych to jeden graf i megabajty danych, spełniający max_length: 2. Tam, gdzie warstwa danych nie nakłada niezależnego limitu (ETS, Mnesia lub kolumna text w Postgresie), cała wartość jest zapisywana, więc atakujący może zapisać całe ciało żądania do atrybutu z małym maksimum i nieograniczenie zwiększać pamięć. Jednostka liczenia różni się również od warstwy przechowywania, która liczy punkty kodowe, a nie grafy, więc wartość zaakceptowana przez ograniczenie może zostać odrzucona lub obcięta przez kolumnę. Kolumna varchar(n) w Postgresie ogranicza samą wartość i nie jest narażona. Problem dotyczy ash: od 0.10.0 przed 3.33.0.

Podatność nieprawidłowej autoryzacji w ash-project ash zwraca rekordy, które polityka odczytu w czasie wykonania (runtime read policy) odmawia każdemu aktorowi. Gdy zasób ma politykę odczytu typu :runtime (sprawdzaną per rekord, a nie kompilowaną do filtra), Ash.Policy.Authorizer decyduje o każdym rekordzie w check_result/1, odrzucając niemożliwe scenariusze polityki i sprawdzając, co pozostaje. Gdy każdy scenariusz dla rekordu był niemożliwy, co oznacza, że żadna polityka nie może go autoryzować i musi być zabroniony, gałąź pustego scenariusza zamiast tego zachowywała rekord i zwracała go jako autoryzowany. Poprawka zabrania rekordu, którego wszystkie scenariusze są niemożliwe. Problem dotyczy ash od 3.4.44 przed 3.32.2.

Podatność na nieprawidłową autoryzację w ash pozwala na autoryzację agregatu pod jednym działaniem odczytu, a obliczenie go pod innym, co może prowadzić do uruchomienia agregatu z politykami niezgodnymi z działaniem, dla którego był autoryzowany. Może to umożliwić ujawnienie informacji o rekordach, których aktor nie powinien czytać.

W bibliotece ash występuje podatność braku autoryzacji, która pozwala aktorowi na aktualizację rekordów zabronionych przez polityki zasobów poprzez ścieżkę atomową Ash.update_many/4. Gdy używana jest strategia atomowa, zapytanie aktualizuje wszystkie wiersze pasujące do klucza głównego bez stosowania polityk, co pozwala na modyfikację rekordów należących do innych aktorów lub tenantów. Poprawka ogranicza ścieżkę atomową do warstw danych wspierających filtry changeset, autoryzuje każdy changeset i scala filtr polityki.

W bibliotece ash występuje podatność nieprawidłowej kontroli dostępu, która pozwala akcji tworzenia nadpisać istniejący rekord, gdy używana jest warstwa danych ETS lub Mnesia, ponieważ nie egzekwują one unikalności klucza głównego. Atakujący, który może ustawić klucz główny podczas tworzenia, może cicho nadpisać istniejący rekord, niszcząc dane innego podmiotu bez przechodzenia przez akcję aktualizacji i jej polityki. Poprawka odrzuca tworzenie, gdy klucz główny już istnieje.

Podatność na niezabezpieczone niepowodzenie (failing open) w ash powoduje pominięcie zmiany Ash.Reactor, gdy kontrola ją blokująca zgłasza wyjątek. Oznacza to, że zmiana, która powinna zostać wykonana, nie jest wykonywana, co może prowadzić do naruszenia bezpieczeństwa.

Podatność na niekontrolowane zużycie zasobów w ash pozwala wolnemu asynchronicznemu odczytowi na zapętlenie wątku schedulera przy pełnym obciążeniu procesora, podczas gdy framework czeka na jego zakończenie. Funkcja AsyncLimiter.await_at_least_one/1 używała ciasnej pętli z Task.yield(task, 0), co powodowało busy-spinning.

W bibliotece ash występuje podatność niekontrolowanego zużycia zasobów, która pozwala atakującemu na wyczerpanie pamięci węzła poprzez dopasowanie filtra obejmującego wiele relacji to-many w pamięci. Funkcja flatten_relationships/2 buduje pełny produkt kartezjański relacji, co prowadzi do kombinatorycznego wzrostu pamięci. Poprawka strumieniuje rozszerzanie leniwie i przerywa przy pierwszym pasującym scenariuszu.