CVE-2026-7838
WysokieCVSS 8.8Prawdopodobieństwo exploitacji (EPSS)
Podwyższone ryzykoPercentyl 63 — wyżej niż 63% wszystkich znanych CVE
Streszczenie
W UltraVNC viewer do wersji 1.8.2.2 wykryto przepełnienie liczby całkowitej prowadzące do przepełnienia bufora sterty w ścieżce parsowania odpowiedzi protokołu RFB. Pole reasonLen o rozmiarze 4 bajtów (typ CARD32) jest przekazywane jako reasonLen+1 do funkcji CheckBufferSize(), co przy wartości 0xFFFFFFFF powoduje przepełnienie do 0 i alokację tylko 256 bajtów, a następnie odczyt 4 GiB danych do tego bufora. Podatność jest osiągalna bez uwierzytelnienia przez typy wiadomości rfbConnFailed i rfbVncAuthFailed.
Ocena ryzyka
Zdalny serwer VNC lub osoba atakująca w środku transmisji (MITM) może wykorzystać tę podatność, gdy ofiara łączy się z serwerem, co może prowadzić do zdalnego wykonania kodu na komputerze ofiary z uprawnieniami użytkownika uruchamiającego przeglądarkę VNC.
Rekomendacja
Należy natychmiast zaktualizować UltraVNC viewer do wersji nowszej niż 1.8.2.2, gdy tylko producent wyda łatkę. Do czasu aktualizacji zaleca się unikanie łączenia się z niezaufanymi serwerami VNC oraz stosowanie szyfrowania tunelowego (np. SSH) w celu ochrony przed atakami MITM.
Oryginalny opis (angielski, źródło NVD)
UltraVNC viewer through 1.8.2.2 contains an integer overflow leading to a heap buffer overflow in the RFB protocol failure-response parsing path. In vncviewer/ClientConnection.cpp, the 4-byte network-supplied reasonLen field (type CARD32) is passed as reasonLen+1 to CheckBufferSize(). Because both operands are unsigned 32-bit, a reasonLen of 0xFFFFFFFF overflows to 0, causing CheckBufferSize to allocate only 256 bytes. The subsequent ReadString(m_netbuf, reasonLen) call then performs ReadExact for the original 4 GiB length into that 256-byte heap buffer. This overflow is reachable via rfbConnFailed (auth-scheme negotiation) and rfbVncAuthFailed (post-handshake) message types without successful authentication. A malicious VNC server, or any man-in-the-middle on the RFB stream, can trigger this condition when the victim viewer connects, potentially resulting in remote code execution as the user running the viewer. The crash was confirmed with AddressSanitizer on a portable reproduction harness (heap-buffer-overflow WRITE at offset 256).