CVE-2026-86121 dotyczy Cua computer-server przed wersją 0.3.42. Opis jest wyjątkowo prosty: gdy zmienna CONTAINER_NAME nie jest ustawiona, authentication może zostać pominięte; a server domyślnie binduje się do 0.0.0.0. Razem: unauthenticated RCE. To świetny case dla VE, bo problem nie leży w jednym „fatalnym” defaultcie — leży w kompozycji dwóch.
CONTAINER_NAME → auth pominięte; bind 0.0.0.0 → ekspozycja sieciowa.run_command (shell), odczyt/zapis plików, interaktywny PTY — pełna command/file capability procesu servera.127.0.0.1 (defense-in-depth).Composition risk: każdy default z osobna „uzasadniony”
Brak CONTAINER_NAME to niby detal konfiguracji — ale decyduje o authentication enforcement. Bind 0.0.0.0 nie jest sam w sobie podatnością — to wygodny default dev-toolingu. Problem powstaje z iloczynu:
To jest composition failure — dlatego „secure by default” trzeba oceniać jako system: authentication ON AND network exposure minimal. Jeśli prawdziwa jest tylko jedna z tych rzeczy, błąd drugiej warstwy nadal daje podatność.
Scanner zna wersję, ale nie zna env
SCA wykryje computer-server 0.3.41 i zgłosi CVE — to dobrze. Ale realna exploitability zależy od runtime:
Ustawienie CONTAINER_NAME nie oznacza automatycznie „not affected”. Lepszy status to NOT_EXPLOITABLE_CURRENT_CONFIG (affected code present + vulnerable auth branch not active), a nie FALSE_POSITIVE — bo zmiana deployment config może przywrócić attack path. Stąd re-evaluation trigger na zmianę env, runtime, host networking czy chart values.
AI/agent infrastructure zasługuje na wyższy asset context
Cua służy do computer-use / desktop-control — taki server może mieć dostęp do sesji desktopowej, filesystemu, shella, stanu przeglądarki i credentiali użytkownika. Nawet jeśli to „developer tooling”, impact bywa znaczny. VM powinien unikać skrótu dev tool = low criticality bez analizy capabilities.
Wniosek
CVE-2026-86121 pokazuje, że security posture powstaje z kompozycji: auth fallback × bind default × high-power API — i dopiero iloczyn daje Critical RCE. Pytanie nie brzmi tylko „czy mamy podatną wersję?”, ale „czy runtime wpadł w allow-all branch i czy jest osiągalny z sieci?”. To pozwala oddzielić affected population od realnie exploitable population — bez fałszywego zamykania findingów.
Powiązane na blogu
- Sigma Forms: vulnerable by default — precondition dostarczona przez producenta
- Linux SCTP: LPE tylko przy wyłączonym cookie auth — status not_exploitable zależny od konfiguracji
Źródła
- VulnCheck — Cua computer-server before 0.3.42 Unauthenticated RCE (05.09.2026) — vulncheck.com
- GitHub Advisory Database — GHSA-pccw-h89v-h9cj (CVE-2026-86121) — github.com/advisories
- Cua — repozytorium — github.com/trycua
Nota redakcyjna: stan informacji 6 września 2026. CVE-2026-86121 (Cua computer-server < 0.3.42, CVSS v4 9.3): kompozycja allow-all authentication branch (brak CONTAINER_NAME) i bind 0.0.0.0 daje unauthenticated RCE; fix 0.3.42 poprawia auth i zmienia bind na loopback. Artykuł koncentruje się na composition risk i oddzieleniu affected od realnie exploitable.