CVE-2026-75969

W Tugtainer przed wersją 1.30.6 uwierzytelniony użytkownik może spowodować, że serwer backend wyśle zewnętrzne żądania HTTP na dowolne adresy URL podane przez użytkownika za pośrednictwem punktu końcowego testowania powiadomień. Punkt /settings/test_notification przyjmuje pole urls i przekazuje je bezpośrednio do Apprise bez ograniczeń protokołów, nazw hostów, adresów localhost, prywatnych zakresów IP ani adresów metadanych chmury. Może to być wykorzystane jako uwierzytelnione ślepe SSRF.

W Tugtainer Agent przed wersją 1.30.4, gdy AGENT_SECRET nie jest skonfigurowany, dostęp do API zarządzania Dockerem jest możliwy bez uwierzytelnienia. Funkcja weryfikacji podpisu w agent/auth.py zwraca sukces, jeśli Config.AGENT_SECRET jest pusty, co powoduje, że chronione API stają się dostępne bez uwierzytelnienia.

W Tugtainer przed wersją 1.30.3 uwierzytelnianie OIDC może być inicjowane nawet gdy OIDC_ENABLED=false. Punkt końcowy /auth/oidc/enabled poprawnie informuje, że OIDC jest wyłączone, ale bezpośrednie żądanie do /auth/oidc/login nadal uruchamia proces logowania OIDC, zwraca HTTP 302, ustawia ciasteczko oidc_state i przekierowuje użytkownika do skonfigurowanego punktu autoryzacji OIDC. To omija wyłącznik OIDC.

W Soft Machine w wersjach 0.2.247 i wcześniejszych dwie funkcje pomocnicze w /app/server.js — verifyContainerAuth() i authenticateWorkspaceHttp() — akceptują globalny CONTAINER_SHARED_SECRET jako token bearer bez weryfikacji, do którego workspace należy wywołujący. Ponieważ ten sekret jest ustawiony identycznie na każdym kontenerze w aplikacji Fly i jest dostępny w środowisku procesów widocznym dla użytkownika, każdy najemca może użyć go do uwierzytelnienia w API workspace innego najemcy. Skutkuje to dostępem do operacji odczytu, zapisu i niszczącego przywracania między workspace'ami.

Zdalny, nieuwierzytelniony klient TLS może spowodować awarię serwera lub wywołanie przez zwolniony wskaźnik, jeśli jego sni_callback przypisze inny kontekst do SSLSocket.context (udokumentowany sposób wyboru certyfikatu per nazwa serwera) i nic innego nie utrzymuje oryginalnego ssl.SSLContext przy życiu. Typowe przypadki to serwery tworzące SSLContext na połączenie lub zastępujące go, gdy połączenia są otwarte; serwery, które opakowują nim gniazdo nasłuchujące, nie są dotknięte. Obejście: trzymaj referencję do każdego SSLContext, który ustawia sni_callback, przez cały czas życia serwera. Klienci TLS nie są dotknięci.

Wszystkie wersje Zammad, w tym najnowsza alfa, umożliwiają lokalnemu użytkownikowi zammad eskalację uprawnień do roota.

Zammad w wersjach 6.3.0 do 6.5.4 jest podatny na przejęcie sesji, co prowadzi do zdalnego wykonania kodu jako użytkownik zammad. Podatność występuje również w wersjach 7.0.0 do 7.1.3, ale nie jest tam wykorzystywalna ze względu na warunki środowiskowe.

W Internet2 Grouper przed wersją 7.5.1 (w niektórych konfiguracjach) użytkownik, który ma uprawnienia do tworzenia lub edytowania reguł w interfejsie użytkownika, może eskalować uprawnienia.

Rozszerzenie Joomla - OrdaSoft Joomla CCK przed wersją 8.3.16 zawiera nieuwierzytelnione zdalne wykonanie kodu. Plik site/uploader.php jest osiągany przez normalny routing frontendu (task=getContent), bez uwierzytelnienia lub kontroli ACL. Walidacja zawartości pliku używa prawdziwego sprawdzenia MIME, ale lista dozwolonych rozszerzeń jest zakomentowana. Rozszerzenie zapisywanego pliku pochodzi bezpośrednio z nazwy pliku podanej przez atakującego, bez walidacji, a plik jest zapisywany w katalogu wykonywanym przez PHP. Poliglot obraz/PHP przeszedł kontrolę treści z rozszerzeniem .php.

Rozszerzenie Joomla - JCTables 1.21.1 zawiera nieuwierzytelnioną iniekcję SQL w zapytaniach odczytu i zapisu. Kontroler API CRUD na froncie nie wykonuje walidacji tokena Joomla ani kontroli uwierzytelnienia na żadnym zadaniu. Nazwy tabel, kolumn i wartości są pobierane bezpośrednio z parametrów żądania i łączone w zapytania SQL, co pozwala na SQLi w zapytaniach odczytu i zapisu.