Katalog podatności CVE

CommServe zawiera podatność na obejście listy dozwolonych, która wpływa na autoryzację wykonywania poleceń. Zaleca się aktualizację do wersji z poprawką.

SAP Commerce Cloud umożliwia nieuwierzytelnionemu atakującemu wykorzystanie domyślnego klienta uwierzytelniającego i przesłanie specjalnie spreparowanych danych do funkcji bez odpowiedniej walidacji. Udane wykorzystanie może umożliwić wykonanie dowolnego kodu i naruszenie wewnętrznych komponentów, co ma wysoki wpływ na poufność, integralność i dostępność aplikacji.

W Picketlink Federation SAML stwierdzono wadę w obsłudze niechcianych odpowiedzi (unsolicited response handler), która akceptuje sfałszowane asercje bez weryfikacji lub walidacji. Pozwala to nieuwierzytelnionemu atakującemu na uwierzytelnienie się jako dowolny podmiot w dowolnej roli, co może prowadzić do ujawnienia informacji, dostępu do ograniczonych operacji lub innych wad.

Nagłówek żądania X-Grafana-URL kontroluje miejsce docelowe żądań wychodzących mcp-grafana, a narzędzie grafana_api_request pozwala wybrać metodę HTTP, ścieżkę i treść. Ponieważ miejsce docelowe nie jest ograniczone do skonfigurowanej instancji Grafana, wywołujący może kierować żądania do wewnętrznych, pętlowych i link-local usług sieciowych (w tym punktów końcowych metadanych) i czytać odpowiedzi, co prowadzi do podrabiania żądań po stronie serwera (SSRF). Poprawka dla CVE-2026-15583 zapobiegła wysyłaniu tokena konta usługi do niezamierzonych miejsc docelowych, ale nie ograniczyła samych miejsc docelowych.

W Crafty Controller występuje podatność na przechodzenie poza katalog (path traversal) w imporcie serwera i przesyłaniu plików przez administratora. Umożliwia zdalnemu, uwierzytelnionemu atakującemu przesyłanie plików do dowolnych ścieżek dozwolonych dla aplikacji Crafty Controller oraz wykonanie zdalnego kodu.

System zarządzania biurem podróży opracowany przez Win Men International ma podatność na wstrzykiwanie SQL. Zdalni, nieuwierzytelnieni atakujący mogą wstrzykiwać dowolne polecenia SQL, aby czytać, modyfikować i usuwać zawartość bazy danych.

SAP Manufacturing Integration and Intelligence (MII) pozwala atakującemu z wysokimi uprawnieniami na przesłanie specjalnie spreparowanych danych do określonych funkcji, które nie są wystarczająco walidowane. Udane wykorzystanie może pozwolić na wykonanie dowolnych poleceń na systemie operacyjnym, co ma wysoki wpływ na poufność, integralność i dostępność aplikacji.

SAP NetWeaver Application Server ABAP ma podatność na błędy logiczne w parsowaniu protokołu DIAG, co pozwala nieuwierzytelnionemu atakującemu na spowodowanie uszkodzenia pamięci. Może to ujawnić wrażliwe informacje systemowe lub doprowadzić do awarii systemu, co ma wysoki wpływ na poufność, integralność i dostępność.

Biblioteka react18-use (shim dla React 19) zawierała złośliwe commity w gałęzi domyślnej, które podczas `npm install` wykonywały zdalnie sterowany kod na maszynach deweloperskich. Kod pobierał payload JavaScript z kontrolowanego przez atakującego punktu końcowego, wyłączał weryfikację TLS i wykonywał go z dostępem do `require`. Wykonanie było celowo pomijane w środowiskach CI i chmurowych, celując w stacje robocze deweloperów.

ERPNext przed wersjami 15.118.0 i 16.29.0 zawiera podatność polegającą na niebezpiecznym renderowaniu szablonów w procesie generowania wyciągów z kont. Uwierzytelniony użytkownik z typową rolą operacyjną może wstrzyknąć wyrażenia szablonu, wykonać dowolny kod po stronie serwera i odczytać dane w całej aplikacji.

Firecrawl przed wersją 2.11.32 zawiera krytyczną podatność dowolnego odczytu plików w funkcji ekstrakcji z powodu niebezpiecznego rozwijania schematów JSON dostarczanych przez użytkownika. Uwierzytelniony atakujący może dostarczyć złośliwy schemat z referencją $ref, co pozwala na odczyt plików z systemu plików workera ekstrakcji oraz SSRF na wewnętrzne lub zewnętrzne punkty HTTP.

Biblioteka react-tracked zawierała złośliwe commity w gałęzi domyślnej, które podczas `npm install` wykonywały zdalnie sterowany kod na maszynach deweloperskich. Kod pobierał payload JavaScript z kontrolowanego przez atakującego punktu końcowego, wyłączał weryfikację TLS i wykonywał go z dostępem do `require`. Wykonanie było celowo pomijane w środowiskach CI i chmurowych, celując w stacje robocze deweloperów.

W systemie Feast występuje błąd polegający na nieprawidłowej deserializacji funkcji zdefiniowanych przez użytkownika (UDF) przechowywanych w rejestrze, które są serializowane za pomocą biblioteki 'dill'. Zdalny atakujący może przechowywać złośliwą UDF, co prowadzi do nieuwierzytelnionego wykonania dowolnego kodu na serwerze funkcji w domyślnej konfiguracji. Uwierzytelniony atakujący może również osiągnąć wykonanie kodu na serwerze rejestru, omijając kontrolę autoryzacji podczas deserializacji.

W interfejsie API MaaS występuje podatność pozwalająca dowolnemu podowi w klastrze na ominięcie bramy AuthPolicy Kuadrant poprzez sfałszowanie nagłówków HTTP `X-MaaS-Username` i `X-MaaS-Group`, które są ufane bez weryfikacji. Brak uwierzytelniania pierwszej strony umożliwia atakującemu nieautoryzowany dostęp i eskalację uprawnień, w tym tworzenie tokenów ServiceAccount w przestrzeniach nazw innych dzierżawców, odwoływanie kluczy API i eksfiltrację wrażliwych danych konfiguracyjnych modeli.

Dokploy przed wersją 0.29.13 pozwala uwierzytelnionemu użytkownikowi na wykonanie dowolnych poleceń na lokalnym lub połączonym przez SSH serwerze docelowym, ponieważ funkcje registry.testRegistry i registry.testRegistryById interpolują pole hasła do polecenia powłoki execAsyncRemote zamiast używać bezpiecznego polecenia safeDockerLoginCommand.

Dokploy przed wersją 0.29.13 pozwala uwierzytelnionemu członkowi z niskimi uprawnieniami na wykonanie dowolnych poleceń na hoście kontrolnym, ponieważ pole volumeName przyjmowane przez volumeBackup.create i volumeBackup.runManually jest interpolowane bez cudzysłowów w packages/server/src/utils/volume-backups/backup.ts i wykonywane przez child_process.exec, a dostęp do gniazda Docker sprawia, że wykonanie jest równoważne z rootem na hoście.

W Dokploy od wersji 0.29.2 do 0.29.13 funkcje schedule.create i schedule.update w pliku schedule.ts pobierają serviceId z applicationId lub composeId i wykonują kontrolę właściciela/admina tylko w alternatywnej gałęzi. Umożliwia to członkowi z dostępem do jednej aplikacji dołączenie jej applicationId do harmonogramu dokploy-server i uruchomienie dostarczonego skryptu jako root przez schedule.runManually. Problem naprawiono w wersji 0.29.13.

W Dokploy w wersji 0.28.8 i wcześniejszych uwierzytelniony użytkownik, który może tworzyć lub aktualizować montowania plików dla usługi, może wstrzyknąć metaznaki powłoki do filePath, powodując wykonanie przez Dokploy poleceń kontrolowanych przez atakującego na skonfigurowanym zdalnym serwerze przez SSH. W domyślnym modelu wdrożenia prowadzi to do zdalnego wykonania kodu na hoście z poziomu interfejsu webowego.

W Dokploy przed wersją 0.29.13 schemat apiCreateCertificate w schema/certificate.ts akceptuje dostarczony przez klienta certificatePath, a usługa certificate.ts łączy tę wartość z katalogiem głównym certyfikatów bez ograniczeń. Uwierzytelniony użytkownik z uprawnieniami do tworzenia lub usuwania certyfikatów może użyć certificatePath do zapisu treści certyfikatu poza zamierzonym katalogiem lub usunięcia katalogu poza głównym. Podatność naprawiono w wersji 0.29.13.

W Dokploy przed wersją 0.29.8 funkcja getRegistryCommands() w pliku upload.ts interpoluje registry.password i registry.registryUrl bezpośrednio do polecenia powłoki bez odpowiedniego escapowania. Uwierzytelniony użytkownik z dostępem do projektu może skonfigurować złośliwe dane uwierzytelniające rejestru i wywołać wdrożenie swarm, aby wykonać dowolne polecenia systemu operacyjnego na serwerze Dokploy, czytać lub modyfikować pliki hosta oraz uzyskać dostęp do innych kontenerów przez Docker. Problem naprawiono w wersji 0.29.8.