CVE-2026-55437

W Coder przed wersjami 2.24.5, 2.29.13, 2.30.8, 2.31.12, 2.32.2 i 2.33.3 funkcja `azureidentity.Validate()` nie weryfikuje podpisu PKCS#7, a jedynie sprawdza, czy certyfikat podpisującego pochodzi od zaufanego urzędu certyfikacji Azure. Atakujący może osadzić prawdziwy certyfikat Azure wraz z dowolną treścią, np. `{"vmId":"<target>"}`, a sfałszowane `vmId` zostanie zaakceptowane, co umożliwi przejęcie tokena sesji agenta ofiary.

W Coder przed wersjami 2.29.17, 2.32.7, 2.33.8 i 2.34.2, mechanizm proxy aplikacji obszaru roboczego oparty na subdomenie umożliwiał ominięcie kontroli CORS dla tego samego właściciela. Gdy segment subdomeny z nazwą obszaru roboczego był parsowany jako UUID, obszar roboczy był rozpoznawany po ID bez weryfikacji, czy nazwa użytkownika w URL-u odpowiada rzeczywistemu właścicielowi, podczas gdy middleware CORS ufał niezweryfikowanej nazwie użytkownika w nazwie hosta.

W Coder od wersji 2.30.0 do 2.32.7, 2.33.8 i 2.34.2, serwer proxy AI Bridge (`aibridgeproxyd`) domyślnie akceptował każdy certyfikat TLS dla połączeń HTTPS z serwerem Coder. Luka wynika z ustawienia `InsecureSkipVerify: true` w domyślnym transporcie, co umożliwia atak typu man-in-the-middle.

W Coder przed wersjami 2.29.7, 2.32.7, 2.33.8 i 2.34.2 endpoint odtwarzania devcontainera sprawdzał tylko uprawnienie `ActionRead` na workspace, pomijając kontrolę `ActionUpdate` przed destrukcyjną przebudową. Atakujący z niskimi uprawnieniami i dostępem do workspace'a mógł wykorzystać tę lukę do nieautoryzowanej przebudowy.

W Coder przed wersjami 2.29.7, 2.32.7, 2.33.8 i 2.34.2, wywołanie RPC `CreateSubAgent` nie sprawdzało żądanego poziomu udostępniania aplikacji względem `MaxPortSharingLevel` szablonu przed zapisaniem aplikacji obszaru roboczego. Pozwalało to właścicielowi obszaru roboczego na przekroczenie skonfigurowanego przez administratora maksymalnego poziomu udostępniania portów.

Podatność w Coder CLI pozwala na kradzież tokena sesji użytkownika poprzez otwarcie złośliwego adresu URL aplikacji workspace. Atakujący (twórca szablonu) może skonfigurować zewnętrzną aplikację workspace, która po uruchomieniu komendy `coder open app` podmienia token sesji w adresie URL, a następnie otwiera go w przeglądarce ofiary.

Podatność w Coder umożliwia atakującemu przekierowanie ruchu z proxy aplikacji workspace do dowolnego hosta poprzez nagłówek X-Forwarded-Host. Problem występuje, gdy włączone jest subdomenowe routowanie aplikacji (wildcard hostname), ofiara odwiedza współdzieloną aplikację atakującego, a upstream proxy nie usuwa tego nagłówka.

W Coder przed wersjami 2.29.7, 2.32.7, 2.33.8 i 2.34.2 funkcja `UpsertWorkspaceApp` nadpisuje istniejący wpis aplikacji, a `insertAgentApp` akceptuje identyfikator aplikacji z ładunku `CompleteJob` bez weryfikacji, czy należy on do budowanego workspace. Pozwala to na przypisanie agenta z innego workspace, co wymaga podwyższonych uprawnień autora szablonu lub operatora zewnętrznego provisionera.

W Coder przed wersjami 2.29.7, 2.32.7, 2.33.8 i 2.34.2 koordynator sieci tailnet nie sprawdza poprawności adresów IP dostarczonych przez agenta w polu AllowedIPs, co pozwala agentowi na podszywanie się pod inne UUID i przechwytywanie ruchu sieciowego. Luka umożliwia nieautoryzowanym agentom dodawanie własnych tras do konfiguracji WireGuard, potencjalnie prowadząc do ataku typu man-in-the-middle.

Podatność w Coder pozwala na wstrzyknięcie dowolnej konfiguracji SSH do pliku ~/.ssh/config użytkownika poprzez niesanitowane wartości HostnameSuffix i SSHConfigOptions dostarczane przez serwer. Atak wymaga kontroli nad serwerem Coder (złośliwy wdrożenie, atak MITM lub dostęp administracyjny).