The issue in TurboVNC was fixed in 2.2.3, but it never existed in
TigerVNC. The issue allowed a specially-crafted VNC viewer to send a
malformed RFB fence message and overflow the server's stack, but the
viewer had to successfully authenticate first. Thus, the worst case was
that the issue might have allowed a clever hacker to remotely execute
code after successful authentication, but all VNC servers allow remote
code execution after successful authentication. That is quite literally
their purpose. :)
On 9/20/21 9:01 AM, techmon wrote:
> Good day,
>
> I realize these articles are from 2019....
> Are *all* of these vulnerabilities fixed since we're now in 2021? or is
> <
https://www.cybersecurity-review.com/news-november-2019/critical-flaws-in-vnc-threaten-industrial-environments/>
>
>
https://usa.kaspersky.com/blog/vnc-vulnerabilities/19962/