If you have ever sat in a Zoom call with someone you did not entirely trust, here is an uncomfortable thought. Until recently that person could have taken over your computer by scribbling on a shared screen. Researchers at A Security have disclosed three memory-safety flaws in Zoom's annotation feature, the drawing and text tool participants use to mark up a slide or a whiteboard. Zoom published three matching bulletins on August 11 and has already shipped fixes.
The attack asked nothing of the victim beyond being in the meeting. In the researchers' words there was "no click, no download, and nothing required of the victim but being in the meeting", and no visual cue that anything had happened. It worked in both directions, a presenter reaching every participant or any participant reaching the presenter.
What is affected
Zoom tracks the issues as CVE-2026-53413 (a buffer over-write, bulletin ZSB-26015, 8.3 High), CVE-2026-53414 (a buffer over-read, ZSB-26016, 6.5 Medium) and CVE-2026-53415 (a use after free, ZSB-26017, 8.3 High). Two share Zoom's own root cause: "Missing bounds check in the annotator function of Zoom Clients". Affected are Zoom Workplace before 7.1.5 and 7.0.6 in their respective branches, the Workplace VDI Client for Windows before 7.0.11 and 6.6.16, and Zoom Rooms and the Meeting SDK before 7.1.0 in the first two bulletins and 7.1.5 in the third. The records name Windows, macOS, Linux, iOS and Android.
The two sources disagree on severity. A Security calls all three "critical 9.0 CVSS:4.0 scores", while Zoom, which issued the CVEs, scores them under CVSS 3.1 and marks user interaction as required, which sits awkwardly against the zero-click framing. Neither side explains the gap.
How the attack works
Annotation never sends a picture. It sends a typed object the receiving client rebuilds field by field, trusting counts the sender chose. Buried in there is a block of four fixed 128-byte buffers for short strings such as font names. The parser reads a character count off the wire and copies twice that many bytes in, and per the writeup that count "is checked only for being non-zero", with nothing comparing it against the 128-byte destination. Make the fourth count large enough and the copy runs off the end, through the stack frame and into the saved return address.
Underneath sits a routing flaw. "Here is an object" is message 0x10001, the acknowledgement "I received your object" is 0x10002, and the client never checks which seat a message came from. The researchers put it bluntly: "an ack is allowed to carry an object body, and the receiver deserializes it." One 745-byte message was enough. On macOS, where they note the component ships without pointer authentication or a stack canary, it handed over full register control and they made the victim's Zoom process launch Safari. On Android they managed it without leaking a memory address at all. No working exploit is shown for Windows or iOS. The third flaw, which Zoom credits to its own offensive security team after Lidor Elias triaged it, is a potential path to code execution rather than a demonstrated one.
The encryption twist
Zoom's stopgap while clients updated was a server-side filter that strips malicious annotation messages before they arrive. It cannot work on end-to-end encrypted meetings, because the server is deliberately blind to what is inside them, so on those calls the crafted message passed through untouched. The privacy setting was the setting that kept you exposed. A Security's advice, for unpatched fleets only, is to switch end-to-end encryption off until clients are updated, since it "would not have stopped this attack anyway: the attacker sits in the meeting, holding the keys". That is the researchers' recommendation and not Zoom's, whose bulletins say only to apply the latest updates.
What you should do
Update clients, and do not assume everyone else has: Zoom lets administrators set a per-platform minimum version for guests as well as staff. Because the attack needed only presence in the call, joining rules are access control, so use waiting rooms, passcodes and authenticated-users-only. Turn off features you do not use, on the researchers' principle that "every optional feature is another parser". A meeting client also has no business launching a browser or a shell, which is worth an alert. No indicators of compromise were published, and nobody reports these flaws being used against anyone in the wild.
One footnote deserves its own headline. A Security says the work, from first look to working exploit, took "fewer than 20 prompts on publicly available AI models in under 24 hours". The first pass failed: a ranking step scored 3,762 functions across 70 libraries and its top leads went nowhere. The annotation library sat 45th, and surfaced only when the team stopped asking where dangerous code was and started tracing what a remote participant could actually reach. The models are not named. We have seen the pattern before, when researchers turned an 18-year-old Linux flaw into a container escape. Video conferencing is having a rough week besides, with attackers separately caught backdooring TrueConf servers to infect meeting guests.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.