posted in Technology
Vulnerability giving attackers full control of Macs is under active exploitation
arstechnica.com/security/2026/08/vulnerability-giving-attackers-full-control-of-macs-is-under-active-exploitation/posted in Technology
Vulnerability giving attackers full control of Macs is under active exploitation
arstechnica.com/security/2026/08/vulnerability-giving-attackers-full-control-of-macs-is-under-active-exploitation/Apparently requires VNC to be open to the internet
Honest question: who still uses VNC? I think it’s only relevant because it’s just kind of a safe fallback but not because it’s particularly great at anything.
Replying to @muusemuuse@sh.itjust.works
The underlying protocol (RFB) is very simple to implement, and in fact some friends and I implemented both a VNC client and server as part of a project we worked on at university nearly 20 years ago.
Because of this, it’s common to find it in various places, especially for interacting with systems that don’t have an OS installed yet:
Most good VPS providers provide VNC access so you can set up your own OS from an ISO, use Clonezilla to clone the drive over the network, recover files if the drive gets corrupted somehow, etc. It’s a built-in feature of KVM/libvirt that the providers usually expose using something like NoVNC in their control panel. The common off-the-shelf control panels (Virtualizor, SolusVM, Virtfusion, Proxmox, etc) all have it as a standard feature.
A lot of IPMI/BMC and KVM-over-IP systems use VNC too, for a similar purpose, just for physical hardware rather than VMs. The protocol being very simple makes it easy to build a simple version into an embedded system. This is also usually accessed via NoVNC in a web UI.
I’ve been in the cloud space so long that I’m like “vnc what the fuuuuck” while I dick about with cloudinit
I don’t trust the prebuilt images that providers provide so I like installing from my own ISO.
cloud-init is useful sometimes, but I recently had an issue with Alpine’s alternative implementation (tiny-init) where it was setting a root password I didn’t know. It was pulling it from some sort of metadata, but there was nowhere in my provider’s control panel to set the default root password. Alpine also doesn’t have any documentation about how to disable tiny-init, so I had to read the code and figure it out myself (create a file called /etc/tiny-cloud.disabled before init runs).
cloud-init also can’t configure LUKS encryption. I know its usefulness is limited on a VM (since the provider can snapshot the memory and retrieve the encryption key that way), but it’s still useful when the VM isn’t running or if you stop using that provider to ensure they can’t recover the data, and it’s required in some cases (eg Plaid required me to certify that all data is encrypted at-rest before they gave me access to their API)