CVE-2026-109301

Parse Server w wersji od 5.4.0 do 8.6.96 oraz od 9.0.0 do 9.10.2-alpha.5 współdzieli stan transakcyjny partii między równoczesnymi żądaniami, pozwalając żądaniu transakcyjnemu dowolnego klienta zakłócać zapisy do bazy danych innych klientów. W przypadku PostgreSQL lub zestawów replik i klastrów shardowanych MongoDB potwierdzone zapisy innych klientów są wycofywane, jeśli partia zawiedzie, a transakcje PostgreSQL mogą pozostać otwarte bezterminowo, powodując niepowodzenie kolejnych zapisów.

Podatność w Parse Server umożliwia nieuwierzytelnionym atakującym, posiadającym publiczne Application Id i klucz klienta, odtworzenie zapytania introspection z pamięci podręcznej Apollo Server, aby uzyskać schemat GraphQL, w tym prywatne nazwy klas i pól. Kontrola introspection jest stosowana tylko do bezpośrednio przesyłanych zapytań, nie do tych z pamięci podręcznej.

Parse Server przed wersjami 8.6.67 i 9.7.0-alpha.11 zawiera podatność, w której atakujący może ominąć kontrolę dostępu walidatora Cloud Function, dodając "prototype.constructor" do nazwy funkcji w URL. Powoduje to pominięcie całej kontroli dostępu, umożliwiając nieuwierzytelnionym wywołanie funkcji chronionych walidatorami.

Parse Server przed wersjami 8.6.3 i 9.1.1-alpha.4 jest podatny na atak, w którym nieautoryzowany napastnik może sfałszować token uwierzytelniający Google z algorytmem 'alg: "none"', co pozwala na logowanie się jako dowolny użytkownik powiązany z kontem Google bez znajomości jego danych uwierzytelniających.

Parse Server to open source backend, który można wdrożyć na dowolnej infrastrukturze działającej na Node.js. W wersjach przed 8.6.0-alpha.2, przepływ pracy GitHub CI jest wyzwalany w sposób, który przyznaje podwyższone uprawnienia GitHub Actions, dając dostęp do sekretów GitHub i uprawnień zapisu zdefiniowanych w przepływie pracy. Kod z forka lub skrypty cyklu życia mogą być potencjalnie uwzględnione. Dotyczy to tylko infrastruktury CI/CD repozytorium, w tym publicznych forków GitHub z włączonym GitHub Actions. Problem został naprawiony w wersji 8.6.0-alpha.2 oraz commitach 6b9f896 i e3d27fe.

Parse Server przed wersjami 5.5.2 i 6.2.1 jest podatny na zanieczyszczenie prototypu, co może prowadzić do zdalnego wykonania kodu poprzez parser BSON MongoDB.

Parse Server przed wersją 8.6.93 oraz w gałęzi 9.0.0 przed 9.10.1-alpha.13 nie egzekwuje ochrony pól chronionych (authenticated, role lub grupy per-user) na zapytaniach count używających operatora $relatedTo, ujawniając rozmiar chronionych pól Relation. Uwierzytelniony użytkownik, który może odczytać właściciela obiektu, może połączyć liczby z ograniczeniem objectId jako wyrocznię członkostwa, aby ujawnić poufne członkostwa, takie jak prywatne grupy lub listy blokowane.

Parse Server w wersjach od 8.2.2 do 8.6.92 oraz od 9.0.0 do 9.10.1-alpha.12 zawiera podatność ujawnienia informacji, w której komunikaty błędów walidacji GraphQL ujawniają ukryte nazwy klas, gdy publiczna introspekcja jest wyłączona. Nieuwierzytelnieni atakujący posiadający jedynie publiczny Application Id mogą wysyłać spreparowane operacje wywołujące błędy nieznanego argumentu lub nieprawidłowej wartości enum, aby poznać klasy docelowe wskaźników i relacji.

Parse Server w wersjach >= 9.0.0 < 9.10.1-alpha.10 i >= 8.0.2 < 8.6.91 nie weryfikuje kodu autoryzacyjnego u dostawcy zewnętrznego podczas logowania z nazwą użytkownika i hasłem, gdy używane są adaptery uwierzytelniania oparte na kodzie (GitHub, Google Play Games, Instagram, LINE, LinkedIn, Microsoft, QQ, Spotify, WeChat, Weibo). Umożliwia to uwierzytelnionemu użytkownikowi o niskich uprawnieniach dołączenie dowolnej, niezweryfikowanej tożsamości dostawcy do swojego konta, a także przejęcie konta ofiary, która później zaloguje się przez tego dostawcę. Problem został naprawiony w wersjach 9.10.1-alpha.10 i 8.6.91.

Parse Server w wersjach >= 9.0.0 i < 9.10.1-alpha.8 oraz < 8.6.89 ocenia uprawnienie protectedFields na poziomie klasy względem niekompletnie rozwiązanego kontekstu wywołującego: role subskrybenta nie są rozwiązywane, a gdy subskrypcja nie dostarcza własnego tokenu sesji, ładunek zdarzenia jest redagowany względem tożsamości anonimowej, mimo że odczyt był autoryzowany względem połączonego użytkownika. W rezultacie maski pól zdefiniowane dla roli, uwierzytelnionych użytkowników lub konkretnego użytkownika nie są stosowane, więc uwierzytelniony subskrybent może otrzymywać wartości pól, które REST API poprawnie ukrywa. Dotyczy tylko klas z włączonym LiveQuery, które definiują protectedFields w grupach role:, authenticated lub per-user; maski w grupie public (*) są stosowane poprawnie. Naprawiono w 9.10.1-alpha.8 i 8.6.89.