CVE-2026-73843

OpenChoreo przed wersjami 1.0.3, 1.1.3 i 1.2.0-rc.2 udostępniało /api/proxy/, /api/exec/ i /api/wirelogs/ na wewnętrznym listenerze bez wymogu certyfikatu klienta lub tokena, umożliwiając każdemu dostęp do sekretów Kubernetes, modyfikację obciążeń i wykonywanie poleceń w podłączonych płaszczyznach danych.

OpenChoreo przed wersjami 1.1.6 i 1.2.3 autoryzuje operacje component:exec i wirelogs:view przy użyciu parametru projektu dostarczonego przez wywołującego zamiast właściwego właściciela projektu z komponentu. Pozwala to użytkownikowi z uprawnieniami ograniczonymi do projektu na wykonywanie poleceń i odczyt logów w komponentach należących do innych projektów w tej samej przestrzeni nazw.

OpenChoreo przed wersjami 1.0.3, 1.1.3 i 1.2.0-rc.2 ma podatność w endpointcie POST /api/v1alpha1/autobuild. Wybór dostawcy webhooka opiera się na kontrolowanym przez atakującego nagłówku X-Event-Key, a żądania Bitbucket są akceptowane bez weryfikacji HMAC-SHA256. Pozwala to na nieuwierzytelnione wyzwalanie buildów dla komponentów dopasowanych po URL repozytorium i gałęzi, w tym ataki między dostawcami z użyciem podanych przez atakującego SHA commitów.

OpenChoreo przed wersjami 1.0.4, 1.1.4 i 1.2.0-rc.2 ma podatność w szablonach Workflow Plane, gdzie parametry kontrolowane przez programistę są interpolowane do kodu powłoki wykonywanego przez sh -c zamiast przekazywane przez container.env. Umożliwia to wykonanie dowolnych komend w podach workflow, a dotknięte szablony Podman nie miały hostUsers: false.

OpenChoreo przed wersjami 1.0.4, 1.1.4 i 1.2.1 ma podatność w backendzie Backstage, gdzie twardo zakodowano wyłączenie domyślnej polityki uwierzytelniania i zezwolono na dostęp gości poza środowiskiem deweloperskim. Skutkuje to brakiem uwierzytelnienia dla /api/*, umożliwiając nieuwierzytelniony odczyt katalogów, logów scaffolder oraz tworzenie lub usuwanie lokalizacji katalogów.