ConnectWise opublikował 8 września 2026 bulletin dla ScreenConnect 26.6.5 (CVE-2026-84869): w określonych warunkach możliwe jest przesyłanie i wykonywanie plików podczas aktywnej sesji zdalnej bez wymaganej autoryzacji lub potwierdzenia po stronie Host. CVSS 3.1 to 9.9. Ale vendor dodaje zdanie, które zmienia sposób prowadzenia remediation: „ScreenConnect servers are not impacted”.
TransferFiles ze wszystkich session groups.Remediation graph, nie numer wersji
Patch serwera bywa wymaganym delivery mechanism, mimo że root cause nie jest w serwerze:
Dlatego status powinien być liczony po populacji rollout, a nie po wersji centralnej platformy:
Cloud nie znaczy „nic do zrobienia”
ConnectWise aktualizuje instancje cloud automatycznie, ale bulletin i tak instruuje: „reinstall your host clients and update your access agents”. Shared responsibility: w cloud provider łata serwer, ale rollout klientów pozostaje po stronie klienta. Endpoint offline podczas rolloutu nie ma właściwych binariów — desired state vs observed runtime state.
CVSS 9.9 vs vendor „Important / Priority 1”
Publiczny CVSS to 9.9 (Critical), a ConnectWise klasyfikuje bulletin jako Severity: Important, Priority: 1 – High. To nie błąd danych — to dwie różne taksonomie (ilościowy model techniczny vs operacyjna kategoria vendora vs urgency). VM ma przechowywać wszystkie z provenance, nie nadpisywać jednej drugą. Uwaga: „Priority 1” (targetowane lub podwyższone ryzyko) to nie potwierdzone active exploitation — nie wymyślaj tego statusu.
Weryfikacja pokrycia i mitygacji
Weryfikacja mitygacji to nie „administrator mówi, że TransferFiles wyłączone”, lecz: wszystkie role wyliczone, uprawnienie nieobecne wszędzie (16 z 17 ról to niepełny control). Po rolloucie: ilu klientów raportuje poprawiony build, ilu offline/stale/failed, plus negatywny test (operacja wymagająca autoryzacji nie przechodzi bez niej). Patch zamyka znaną ścieżkę, ale nie odpowiada, czy wcześniej doszło do wykorzystania — przy podejrzeniu: izolacja, przegląd ról/haseł/MFA, audit log.
Wniosek
Dojrzały VM nie kończy się na wersji centralnego produktu. Trzeba śledzić patch authority → distribution point → runtime affected component → rollout coverage → security property verification. Dopiero po całym łańcuchu można uczciwie powiedzieć „gotowe”.
Powiązane na blogu
- N-central: patch lineage i supersedence — remediation jako relacja, nie flaga
- OpenSearch: remediation w service software — kto i gdzie łata
Źródła
- ConnectWise — ScreenConnect 26.6.5 Security Patch (08.09.2026) — connectwise.com
- GitHub Advisory Database — GHSA-rc8v-f46m-jcgm (CVE-2026-84869) — github.com/advisories
Nota redakcyjna: stan informacji 9 września 2026. CVE-2026-84869 (ScreenConnect, CVSS 9.9): podatność w kliencie/sesji, serwer nie jest impacted; fix 26.6.5 wymaga reinstalacji Host Clientów i aktualizacji Access Agents. Artykuł koncentruje się na tym, że remediation target ≠ komponent z root cause i że status liczy się po rollout coverage.