Katalog podatności CVE

LogicalDOC Enterprise do wersji 9.1.1 włącznie jest podatny na ślepą iniekcję SQL w komponencie WorkflowsDataServlet, co pozwala uwierzytelnionemu użytkownikowi manipulować zapytaniami SQL poprzez spreparowaną nazwę szablonu przepływu pracy.

kkFileView w wersjach od 5.0.0 do 5.0.2 zawiera podatność na przechodzenie po katalogach w FileController.java. Endpointy fileUpload, createFolder i existsFile akceptują parametr "path", który jest łączony z bazową ścieżką uploadu bez walidacji, co pozwala nieuwierzytelnionym atakującym na tworzenie dowolnych katalogów i zapisywanie dowolnych plików poza zamierzonym katalogiem głównym fileDir poprzez spreparowane żądanie multipart.

W JetBrains TeamCity w wersjach przed 2026.1.3 i 2025.11.7 możliwe było obejście piaskownicy Kotlin DSL, co prowadziło do zdalnego wykonania kodu (RCE) na serwerze. Podatność pozwala atakującemu na uruchomienie dowolnego kodu w kontekście serwera TeamCity.

W systemie Payload CMS, w adapterze @payloadcms/db-mongodb w wersjach przed 3.87.0 oraz w wersjach canary przed 4.0.0-canary.20, uwierzytelniony użytkownik mogący aktualizować dokument może modyfikować pola, do których kontrola dostępu na poziomie pola nie powinna mu pozwalać. Adaptery Postgres i SQLite nie są podatne.

W systemie Payload CMS w wersjach przed 3.90.0 i canary przed 4.0.0-canary.34 lokalne konfiguracje przesyłania, które akceptują pliki XML, mogą przechowywać plik XML i arkusz stylów wykonujący JavaScript w domenie Payload, gdy zalogowany użytkownik otworzy ten plik. Podatność prowadzi do wykonania kodu JavaScript w kontekście przeglądarki ofiary.

Payload to bezgłowy system zarządzania treścią typu open source. W wersjach przed 3.90.0 oraz w wersjach canary przed 4.0.0-canary.34 nieuwierzytelniony atakujący znający adres e-mail lub nazwę użytkownika konta może wykorzystać mechanizm blokady konta w kolekcji z lokalnym uwierzytelnianiem, aby uniemożliwić temu kontu zalogowanie się.

W systemie Payload CMS w wersjach przed 3.90.0 i canary przed 4.0.0-canary.34 uwierzytelniony użytkownik mogący aktualizować lub usuwać przesłane pliki przechowywane lokalnie może spowodować usunięcie przez mechanizm czyszczenia plików niepożądanych plików poza skonfigurowanym katalogiem przesyłania, co prowadzi do utraty danych lub zakłócenia usługi. Wdrożenia ograniczające zarządzanie przesyłaniem do zaufanych użytkowników są mniej narażone.

W systemie Payload CMS w wersjach przed 3.90.0 i canary przed 4.0.0-canary.34 kolekcja zezwalająca na przesyłanie plików SVG do pobrania może przechowywać złośliwy plik SVG, który omija sanityzację i wykonuje kod JavaScript kontrolowany przez atakującego, gdy użytkownik pobierze i otworzy ten plik. Prowadzi to do wykonania kodu w przeglądarce ofiary.

W systemie Payload CMS w wersjach po 3.0.0 i przed 3.90.0 uwierzytelnione pobieranie przesłanych plików z zewnętrznego adresu URL może przekazywać dane uwierzytelniające do przekierowanego miejsca, które nie zostało zweryfikowane jako zaufane, potencjalnie ujawniając ważną sesję niepożądanemu odbiorcy. Podatność została naprawiona w wersji 3.90.0.

Wtyczka @payloadcms/plugin-multi-tenant w wersjach przed 3.90.0 i canary przed 4.0.0-canary.34 domyślnie pozwala uwierzytelnionemu użytkownikowi przypisać własne konto do innych tenantów. Instalacje, które zastąpiły domyślne zachowanie zabezpieczonymi funkcjami tenants arrayFieldAccess.create i update, nie są podatne. Problem naprawiono w wersjach 3.90.0 i 4.0.0-canary.34.

W wersjach Payload przed 3.90.0 i canary przed 4.0.0-canary.34, specjalnie spreparowane żądanie do publicznej operacji first-register może zdalnie wykonać kod, gdy włączone jest lokalne uwierzytelnianie i nie utworzono jeszcze pierwszego użytkownika. Problem naprawiono w wersjach 3.90.0 i 4.0.0-canary.34.

W wersjach Payload przed 3.90.0 i 4.0.0-canary.34, atakujący z dostępem do odczytu i tworzenia lub aktualizacji kolekcji zawierającej pole json lub pole blocks z włączonym blocksAsJSON może wstrzyknąć SQL przez spreparowaną ścieżkę pola i operatory. Kolekcje bez tych pól oraz pola richText nie są podatne. Pakiety SQLite naprawiono w wersjach 3.90.0 i 4.0.0-canary.34, a Postgres w wersji 3.73.0.

W wersjach Payload przed 3.90.0 i canary przed 4.0.0-canary.34, serwer nie egzekwuje ograniczenia access.update na poziomie pola dla pola hasła w kolekcji uwierzytelniania. Problem naprawiono w wersjach 3.90.0 i 4.0.0-canary.34.

W wersjach Payload od 3.0.0 przed 3.90.0 i canary przed 4.0.0-canary.34, nieprawidłowo sformułowane żądanie multipart może spowodować bardzo długie przetwarzanie Content-Type multipart, prowadząc do niekontrolowanego zużycia zasobów. Problem naprawiono w wersjach 3.90.0 i 4.0.0-canary.34.

Payload to bezgłowy system zarządzania treścią typu open source. W wersjach przed 3.90.0 oraz w wersjach canary przed 4.0.0-canary.34 odpytywanie czytelnej kolekcji powiązanej relacją z inną kolekcją może ujawnić informacje o powiązanych dokumentach chronionych przez ograniczenia access.read.

Payload CMS w wersjach od 3.0.0 przed 3.90.0 i canary przed 4.0.0-canary.34 zawiera podatność w operacji duplikacji, która kopiuje wartości z dokumentu źródłowego nawet gdy pole jest ukryte lub reguły access.read/access.create odrzucają wartość dla wywołującego. Ustawienie disableDuplicate nie zapobiega temu obejściu kontroli dostępu. Problem naprawiono w wersjach 3.90.0 i 4.0.0-canary.34.

W @payloadcms/plugin-ecommerce w wersjach przed 3.90.0 i canary przed 4.0.0-canary.34, użycie adaptera płatności Stripe może pozwolić na przetworzenie potwierdzenia zamówienia Stripe więcej niż raz w określonych warunkach. Problem naprawiono w wersjach 3.90.0 i 4.0.0-canary.34.

W wersjach Payload od 3.0.0 przed 3.90.0 i canary przed 4.0.0-canary.34, użytkownicy ze zwykłym dostępem do odczytu do innych dokumentów uwierzytelniania w kolekcji z włączonym useAPIKey mogą uzyskać aktywne klucze API i korzystać z uprawnień docelowych kont, dopóki te klucze nie zostaną obrócone lub wyłączone. Problem naprawiono w wersjach 3.90.0 i 4.0.0-canary.34.

MCP TypeScript SDK w wersjach od 1.12.0 przed 1.31.0 i 2.2.0 pozwala serwerowi MCP, do którego klient się podłącza, decydować, który serwer autoryzacji otrzyma poświadczenia OAuth klienta. Przechowywane i wstępnie zaopatrzone poświadczenia nie były powiązane z serwerem autoryzacji, do którego należą. Złośliwy lub skompromitowany serwer MCP może wskazać własny serwer autoryzacji w metadanych chronionego zasobu. Bez interakcji użytkownika klient wysyłałby temu serwerowi `refresh_token` i `client_secret` zapisane z wcześniejszego logowania (1.x) lub skonfigurowany `client_secret` lub podpisaną asercję z dołączonego nieinteraktywnego dostawcy (1.x i 2.x). Dotyczy to tylko aplikacji używających SDK jako klienta MCP przez HTTP z `authProvider`: własnym `OAuthClientProvider` lub dołączonym `ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider` lub (2.x) `CrossAppAccessProvider` i które mogą łączyć się z serwerem MCP, któremu właściciele nie ufają w pełni, trzymając poświadczenia dla legalnego serwera autoryzacji. `@modelcontextprotocol/sdk` 1.31.0 (1.x) i `@modelcontextprotocol/client` 2.2.0 (2.x) łatają problem. Dostępny jest workaround dla tych, którzy nie mogą zaktualizować. 2.0.0 i 2.1.0 już akceptują `expectedIssuer`. W 1.x jedynym workaroundem jest łączenie klientów z włączonym OAuth tylko z zaufanymi serwerami MCP.

Dell Container Storage Modules w wersjach przed 1.18.0 zawiera podatność związaną z użyciem niewystarczająco losowych wartości. Nieuwierzytelniony atakujący z lokalnym dostępem może ją wykorzystać, prowadząc do manipulacji informacjami.