Katalog podatności CVE

Capgo przed wersją 12.244.1 zawiera podatność integralności między dzierżawcami w procesie czyszczenia metadanych, który ufa kluczom obiektów obrazów z mutowalnych wierszy bazy danych bez weryfikacji własności.

Capgo (capgo.app) do wersji 12.261.0 zawiera niekompletną poprawkę kontroli dostępu dla tabeli public.sso_providers. Migracja 20260826100000_sso_providers_block_direct_active_insert.sql instaluje wyzwalacz BEFORE UPDATE (enforce_sso_provider_client_update_guard()), który blokuje tylko kolumny dns_verified_at, domain, status i enforce_sso, pozostawiając kolumnę provider_id (oraz metadata_url i attribute_mapping) możliwą do zapisu. Ponieważ tabela ma przyznane uprawnienie ALL dla ról anon i authenticated bez ograniczeń na poziomie kolumn, a polityki row-level security (np. allow_org_admins_update_sso_providers) ograniczają tylko które wiersze mogą być aktualizowane, a nie które kolumny, użytkownik z uprawnieniem org_admin (org.update_settings) może przez PostgREST zmienić provider_id na kontrolowanego przez siebie dostawcę tożsamości. Ponieważ provider_id jest kotwicą zaufania wiążącą domenę e-mail z autoryzowanym IdP, atakujący może następnie uwierzytelnić się przez własny IdP, podając e-mail właściciela organizacji; dopasowanie po stronie serwera kończy się sukcesem, a procedura scalania przypisuje tożsamość SSO atakującego do istniejącego konta właściciela, zeruje jego hasło i usuwa inne tożsamości oraz sesje. Prowadzi to do eskalacji uprawnień z org_admin do właściciela organizacji/super_admin, przejęcia konta i zablokowania prawowitego właściciela. Eksploatacja wymaga aktywnego dostawcy SSO w organizacji docelowej oraz posiadania przez atakującego roli org_admin w tej organizacji. Brak dostępnej wersji z poprawką.

Flowise do wersji 3.1.4 udostępnia punkty GET /api/v1/upsert-history/:id i PATCH /api/v1/upsert-history bez kontroli uprawnień, a usługa nie weryfikuje przynależności do obszaru roboczego.

Flowise do wersji 3.1.4 nie wymusza autoryzacji na pulpicie administracyjnym BullMQ. Gdy serwer działa w trybie kolejki z włączonym pulpitem, każdy uwierzytelniony użytkownik może uzyskać dostęp do /admin/queues.

Flowise do wersji 3.1.4 identyfikuje użytkowników SSO i logowanych hasłem wyłącznie na podstawie adresu e-mail, bez wiązania dostawcy lub identyfikatora. Atakujący może zalogować się jako każdy istniejący użytkownik, używając jego adresu e-mail.

Flowise do wersji 3.1.4 zawiera obejście uwierzytelniania w ścieżce logowania SSO, gdy e-mail w wywołaniu zwrotnym pasuje do użytkownika ze statusem INVITED. Procedura kopiuje rekord użytkownika z tymczasowym tokenem do rejestracji, co pozwala na przejęcie zaproszenia.

Flowise do wersji 3.1.4 brakuje kontroli RBAC na trasach wiadomości czatu, co pozwala kluczom API o niskich uprawnieniach na odczyt i usunięcie historii czatu.

W projekcie CloudClassroom-PHP-PHP do konkretnego commita wykryto podatność SQL injection w pliku mydetailsfaculty.php poprzez argument myfid. Atak może być przeprowadzony zdalnie.

W projekcie CloudClassroom-PHP-Project do konkretnego commita wykryto podatność SQL injection w pliku updatedetailsfromstudent.php poprzez argument eno. Atak może być przeprowadzony zdalnie.

W jądrze Linux wykryto podatność w mechanizmie cgroup, dotyczącą iteracji po umierających zadaniach (dying_tasks) z zerowym licznikiem referencji. Błąd powoduje wyścig (race condition), w którym iterator może uzyskać dostęp do zadania po jego zwolnieniu, co prowadzi do użycia po zwolnieniu (use-after-free).

Wtyczka Testimonials Widget do WordPressa do wersji 4.0.4 nie przeprowadza kontroli uprawnień ani własności w formularzu przesyłania opinii na froncie. Pozwala to nieuwierzytelnionym użytkownikom na modyfikację lub tworzenie dowolnych wpisów, w tym nadpisywanie tytułu, treści i autora istniejących wpisów.

Wtyczka MCP Server for WordPress przed wersją 1.8.2 nieprawidłowo weryfikuje nonce WordPress REST API dla żądań uwierzytelnionych ciasteczkami, gdy występuje warunek, który atakujący może wpłynąć. Pozwala to nieuwierzytelnionym atakującym na wykonywanie działań zarezerwowanych dla administratorów, w tym tworzenie nowego konta administratora, poprzez nakłonienie zalogowanego administratora do odwiedzenia spreparowanej strony.

Wtyczki WordPress File Manager przed 8.0.5, FileOrganizer przed 1.2.1 oraz File Manager Pro przed 2.1.3 nieprawidłowo walidują pochodzenie komunikatów okna odbieranych przez przeglądarkę plików ładowaną na ekranach administracyjnych. Akceptują dowolne pochodzenie będące przedrostkiem adresu witryny, co pozwala nieuwierzytelnionemu atakującemu uruchomić dowolny JavaScript w sesji zalogowanego administratora odwiedzającego stronę pod jego kontrolą. Wada leży w bibliotece file-manager dołączanej przez wszystkie trzy wtyczki i występuje w każdej wersji poniżej 2.1.70.

Wtyczka WordPress wp-review-slider-pro przed wersją 12.7.12 nie wykonuje sprawdzenia uprawnień w handlerze AJAX zapisującym formularze zgłaszania recenzji, a chroniący go nonce jest generowany dla każdego odwiedzającego. Umożliwia to każdemu uwierzytelnionemu użytkownikowi, np. subskrybentowi, nadpisanie aktywnego formularza wartościami pól, które są wyprowadzane bez escapowania na publicznych stronach, co prowadzi do przechowywanego Cross-Site Scripting.

Wtyczka WordPress wp-review-slider-pro przed wersją 12.7.12 nie wykonuje sprawdzenia uprawnień w jednym ze swoich handlerów AJAX, a chroniący go nonce jest generowany dla każdego odwiedzającego. Umożliwia to każdemu uwierzytelnionemu użytkownikowi, np. subskrybentowi, zapisanie dowolnej treści recenzji, która jest później wyprowadzana bez escapowania na publicznych stronach, co prowadzi do przechowywanego Cross-Site Scripting.

Wtyczka WordPress WP Directory Kit przed wersją 1.5.8 nie sanityzuje ani nie escapuje niektórych pól kategorii i lokalizacji przed wyprowadzeniem ich w atrybutach strony. Umożliwia to użytkownikom z rolą zarządzania ogłoszeniami specyficzną dla wtyczki (bez uprawnienia unfiltered_html) przeprowadzenie ataków przechowywanego Cross-Site Scripting, które wykonują się u każdego odwiedzającego dotkniętą stronę.

OpenClaw w wersjach 2026.5.1 do 2026.7.0 nie stosuje skonfigurowanej ścieżki zatwierdzania wykonania do poleceń węzła Google Meet. Polecenie googlemeet.chrome akceptuje tablice poleceń audio dostarczone przez wywołującego i wykonuje je na sparowanym węźle bez normalnego przepływu zatwierdzania system.run. W środowiskach z włączoną wtyczką Google Meet, sparowanym węzłem Chrome i dozwolonym poleceniem googlemeet.chrome, agent z dostępem do narzędzi może wykonać wybrane przez atakującego procesy na sparowanym węźle, wpływając na pliki, poświadczenia, profile przeglądarki i dostępność. Problem naprawiono w wersji 2026.7.1; jako obejście można usunąć googlemeet.chrome z dozwolonych poleceń węzła lub wyłączyć wtyczkę Google Meet.

OpenClaw (pakiet npm openclaw) przed wersją 2026.7.1 nieprawidłowo wiąże reakcje zatwierdzania Signal. W dotkniętych wersjach reakcja mająca rozwiązać strukturalne żądanie zatwierdzenia może zamiast tego zostać przypisana do zwykłej wiadomości wychodzącej, gdy w tej samej konwersacji występują niezwiązane wiadomości wychodzące i oczekujące zatwierdzenie. W rezultacie reakcja osoby zatwierdzającej na niezwiązany tekst może zostać zinterpretowana jako zatwierdzenie lub odrzucenie oczekującej akcji hosta; praktyczny wpływ zależy od oczekującego żądania, czasu konwersacji i działań dostępnych dla procesu OpenClaw. Problem nie zmienia uprawnień poprawnie zidentyfikowanych osób zatwierdzających. Naprawiono w wersji 2026.7.1.

OpenClaw (pakiet npm 'openclaw') przed wersją 2026.7.1 jest podatny na wyścig typu time-of-check time-of-use w operacjach mutacji lokalnego systemu plików OpenShell mirror. Operacje remove, mkdir i rename mogą działać na innym celu systemu plików po zakończeniu przez OpenClaw kontroli bezpieczeństwa ścieżki w sandboxie, jeśli ścieżka zostanie zmieniona jednocześnie. Atakujący, który wygra wyścig, może spowodować, że operacja w sandboxie usunie, utworzy lub zmieni nazwę ścieżki hosta poza zamierzonym katalogiem głównym mirror z uprawnieniami użytkownika procesu OpenClaw. Nie wymaga to przyznania operatorowi dostępu do systemu plików hosta poza sandboxem. Problem naprawiono w wersji 2026.7.1.

OpenClaw w wersjach przed 2026.7.1 nieprawidłowo autoryzuje niebędących właścicielami użytkowników wykonujących zmiany konfiguracji MCP przez polecenia /mcp set i /mcp unset. Atakujący mogą utrwalić dowolne polecenia stdio MCP, które wykonują się z uprawnieniami procesu OpenClaw podczas ładowania konfiguracji, naruszając poufność, integralność i dostępność hosta.