Katalog podatności CVE

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.

W Dokploy przed wersją 0.29.13 potok tworzenia kopii zapasowych i przywracania konstruuje polecenia powłoki, bezpośrednio interpolując kontrolowane przez użytkownika pola bazy danych do ciągów bash -c "..." i sh -c "...", a następnie wykonuje je przez child_process.exec(). Uwierzytelniony administrator/właściciel może wstrzyknąć dowolne polecenia systemu operacyjnego, które wykonują się na hoście, na którym działa Dokploy (nie tylko wewnątrz kontenera). Podatność naprawiono w wersji 0.29.13.

W Dokploy przed wersją 0.29.13 pole dockerImage jest interpolowane bez cudzysłowów do poleceń powłoki w buildRemoteDocker() w pliku docker.ts i walidowane tylko jako opcjonalny ciąg znaków. Uwierzytelniony użytkownik z uprawnieniami do tworzenia lub aktualizacji aplikacji może użyć podstawienia poleceń w dockerImage, aby wykonać dowolne polecenia na lokalnym hoście budowania lub zdalnym celu SSH, ujawniając sekrety hosta i innych projektów. Problem naprawiono w wersji 0.29.13.

W Dokploy przed wersją 0.29.13 funkcje swarm.getNodes, swarm.getNodeInfo, swarm.getNodeApps i swarm.getAppInfos w pliku swarm.ts akceptują serverId innej organizacji bez sprawdzenia własności activeOrganizationId, a getNodeInfo w docker.ts interpoluje nodeId do execAsyncRemote, umożliwiając wywołującemu z uprawnieniami server:read wykonanie dowolnych poleceń jako skonfigurowany użytkownik SSH na serwerze innego najemcy. Problem naprawiono w wersji 0.29.13.

TBEA TLogger V2.1.0.0B0.0.0.0 zawiera obejście uwierzytelniania w swoim serwerze WWW. Po wcześniejszym uwierzytelnieniu użytkownika na urządzeniu, nieuwierzytelniony atakujący może bezpośrednio uzyskać dostęp do chronionych funkcji przez punkt końcowy /index.asp bez podawania ważnych poświadczeń. Umożliwia to atakującemu dostęp do funkcji przeznaczonych dla uwierzytelnionych użytkowników i może ujawnić lub zmodyfikować konfigurację i dane urządzenia. Wylogowanie z ominiętego stanu może dodatkowo spowodować awarię serwera WWW.

Nieuwierzytelniona podatność na wstrzyknięcie SQL istnieje w serwerze WWW TBEA TLogger V2.1.0.0B0.0.0.0. Wiele punktów końcowych HTTP włącza kontrolowane przez atakującego parametry bezpośrednio do zapytań SQLite bez wystarczającej walidacji lub parametryzacji. Zdalny nieuwierzytelniony atakujący może wykorzystać te punkty końcowe do odczytu, modyfikacji lub usunięcia danych przechowywanych w bazie danych CCU.db urządzenia.

Zakodowane na stałe lub domyślne poświadczenia konta root w TBEA TLogger V2.1.0.0B0.0.0.0 umożliwiają nieuwierzytelnionemu zdalnemu atakującemu uzyskanie dostępu na poziomie root do urządzenia przez wystawioną usługę SSH. Hasło root można odzyskać z hasha przechowywanego w /etc/shadow i użyć do uwierzytelnienia w usłudze SSH. Skuteczne wykorzystanie zapewnia pełną kontrolę administracyjną nad urządzeniem.

Dokploy przed wersją 0.29.13 nie waliduje pól bitbucketOwner i bitbucketRepository podczas zapisywania dostawcy Bitbucket, a następnie interpoluje je do poleceń git clone wykonywanych przez execAsync lub execAsyncRemote. Umożliwia to członkowi z uprawnieniami do wdrażania usług wykonanie dowolnych poleceń systemu operacyjnego na hoście Dokploy lub serwerze docelowym.

Dokploy przed wersją 0.29.13 w subskrypcji tRPC backup.restoreBackupWithLogs przekazuje parametr databaseName do funkcji przywracania, gdzie polecenia PostgreSQL, MariaDB, MySQL i MongoDB osadzają tę wartość w zagnieżdżonym tekście powłoki wykonywanym przez Node.js exec. Uwierzytelniony użytkownik z uprawnieniem backup:restore może dostarczyć spreparowany databaseName, który powłoka /bin/sh rozszerza przed docker exec, co prowadzi do wykonania dowolnych poleceń w kontekście hosta z uprawnieniami Docker.

Dokploy przed wersją 0.29.13 w pliku destination.ts interpoluje pola accessKey, secretAccessKey, region, endpoint, provider i bucket z destination.testConnection do polecenia rclone ls wykonywanego przez child_process.exec. Ścieżka z uprawnieniem "destination", "create" pozwala członkowi organizacji o niskich uprawnieniach na dotarcie do mutacji, zamknięcie cytowanego argumentu spreparowanym polem i wykonanie dowolnych poleceń w kontenerze root Dokploy, który ma dostęp do gniazda Docker hosta.

Dokploy od wersji 0.29.3 do 0.29.13 ma niekompletną poprawkę dla CVE-2026-45628, pozostawiając pola gałęzi w schema/compose.ts bez walidacji po stronie serwera, co pozwala na bezpośrednie żądanie compose.update do przechowywania złośliwego customGitBranch, branch, gitlabBranch, bitbucketBranch lub giteaBranch. Uwierzytelniony użytkownik o niskich uprawnieniach może wywołać compose.deploy, który przekazuje zapisaną gałąź do poleceń git clone opartych na powłoce, co prowadzi do wykonania dowolnych poleceń na hoście.

Dokploy przed wersją 0.29.13 w operacji compose.update przechowuje niezweryfikowany composePath, który jest interpolowany do poleceń docker compose -f, docker stack deploy -c i touch wykonywanych przez /bin/sh -c. Uwierzytelniony członek z uprawnieniami do zapisu i wdrażania compose może dostarczyć spreparowany composePath, wywołać compose.deploy lub startCompose i wykonać dowolne polecenia systemu operacyjnego w kontekście hosta z uprawnieniami Docker.