Zoom Annotation Flaws Could Let a Meeting Participant Hijack Another Attendee's Client

The newly disclosed vulnerabilities in Zoom’s annotation functionality demonstrate how seemingly ordinary collaboration features can become powerful attack surfaces when they process complex data received from other meeting participants. Three vulnerabilities, CVE-2026-53413, CVE-2026-53414 and CVE-2026-53415, affect the annotation engine used when participants draw, type text, create shapes or otherwise mark content during screen sharing. Two of the vulnerabilities can potentially provide remote code execution, while the third can cause denial of service and, according to the researchers, may also expose memory information useful for defeating exploit mitigations. The most concerning aspect is that exploitation does not require the victim to download a file, click a link or approve a request. Simply participating in a meeting where malicious annotation protocol messages can reach the vulnerable client may be sufficient. 

The attack surface exists because Zoom does not transmit annotations merely as pictures. When a participant draws a line, adds text or creates another annotation object, the client constructs a structured representation of that object and sends it through Zoom’s meeting infrastructure. The receiving Zoom client then reconstructs the corresponding in-memory object so that it can render the annotation locally. That means every participating client is effectively parsing structured binary input controlled, at least partially, by another meeting participant. Once complex remote data is being deserialized into native memory structures, annotation becomes a security-sensitive protocol rather than merely a drawing tool.

A Security’s researchers found that Zoom’s proprietary annotation protocol uses numerous count- and length-prefixed fields. The receiving client reads values supplied over the network and uses them to determine how much memory should be copied or how large an internal object should become. This design is common in network protocols, but every externally supplied size must be checked carefully before being trusted. CVE-2026-53413 exists because one such check was missing in the text-annotation parsing logic.

The vulnerable structure contained several fixed 128-byte buffers used for formatting information associated with text annotations. The protocol allowed the sender to provide a 32-bit count describing how much data should be copied into those buffers, but the parser did not adequately verify that the supplied count fitted inside the destination. A malicious participant could therefore specify a value larger than the available buffer and cause attacker-controlled bytes to overwrite adjacent memory.

This is a classic memory-corruption condition, but its placement inside a conferencing protocol makes the impact considerably more serious. An attacker does not need to send the victim an executable or convince them to open a malicious document. The malicious content arrives as part of normal meeting traffic and is automatically processed by the Zoom client because processing annotations is expected behaviour during a call.

The researchers demonstrated that the overflow could overwrite stack information on macOS and ultimately redirect program execution. Their proof of concept was able to manipulate the return path and invoke system functionality, demonstrating remote code execution rather than merely causing the Zoom application to crash. Once an attacker obtains code execution inside the victim’s Zoom process, the incident moves from application compromise to endpoint compromise.

The privileges available after exploitation depend on the operating system and the privileges under which Zoom is running, but conferencing clients commonly have access to sensitive resources. Users routinely grant them permission to use microphones, cameras and screen-sharing capabilities. They may also run inside sessions containing browser cookies, corporate credentials and access to local files. Remote code execution through a conferencing application can therefore become a route toward surveillance, credential theft, malware installation or further movement into the victim’s organization.

CVE-2026-53414 involves a different memory-safety failure in the same annotation engine. Zoom officially describes this issue as a buffer over-read capable of allowing one meeting participant to cause denial of service against another. The researcher’s analysis goes further, showing that under particular conditions the parser can allocate a buffer based on one attacker-controlled value while receiving less data than the allocation expects, leaving portions of uninitialized process memory exposed inside the resulting object.

According to A Security, their testing recovered live heap content containing code and virtual-table pointers. Such pointers can be valuable because modern operating systems use Address Space Layout Randomization to make exploitation more difficult by placing code and libraries at unpredictable addresses. If an attacker can leak a valid address from the victim’s process, they may be able to calculate where useful code resides and combine that information with a separate memory-write vulnerability.

This is a useful reminder that vulnerability chains often matter more than individual CVE scores. One bug may provide a memory disclosure while another provides the ability to overwrite memory. Individually they may appear less reliable, but together they can remove the defensive barriers that make modern exploitation difficult. Security teams should therefore evaluate related vulnerabilities affecting the same component collectively rather than assuming each one will always be exploited independently.

The third vulnerability, CVE-2026-53415, is a use-after-free issue in the same annotation engine. Zoom rates it as high severity and states that it may allow a meeting participant to achieve remote code execution against another participant over the network. A Security describes the flaw as involving an auto-shape metadata object that can lead to manipulation of internal linked-list pointers and potentially create a write-what-where primitive, an extremely valuable capability for exploit development because it allows controlled data to be written to an attacker-selected memory location.

The three vulnerabilities collectively illustrate why native parsing code remains a high-risk component of desktop applications. Zoom clients process significant volumes of real-time audio, video, screen-sharing and collaboration data, much of which is handled by high-performance native libraries written in languages where incorrect memory handling can become exploitable corruption. The performance advantages are substantial, but the security consequence is that every remote parser requires exceptionally careful bounds checking and object-lifetime management.

Another particularly interesting weakness involved how annotation messages were routed between participants. Zoom’s protocol maintains communication paths between the screen sharer and people viewing the shared content. Different message types are expected depending on which side of the screen-sharing relationship is sending them, but the researchers found that the receiving parser did not consistently enforce the sender’s role before dispatching certain annotation messages.

This allowed message types intended for one direction of communication to be supplied through another path. A viewer could potentially send a fully serialized annotation object toward the presenter where the application expected an acknowledgement, while a malicious presenter had a communication path toward viewers. The result was that both sides of a screen-sharing session could potentially become targets rather than the vulnerability applying only to the person sharing their screen.

This is an important protocol-design lesson. Security should not depend solely on participants behaving according to the expected application workflow. If a viewer is expected to send only particular message types, the receiver must enforce that restriction cryptographically or through protocol validation. A malicious participant can construct protocol messages directly and has no obligation to use the official user-interface buttons.

The attack also shows why meeting membership has become an important security boundary. Organizations often treat joining a Zoom meeting as substantially lower risk than opening a document or visiting an unknown website because participants assume they are merely receiving audio and video. In reality, the client is processing numerous complex protocols generated by other participants. Once remote participants can reach native parsers, admission to the meeting becomes a form of network access to the endpoint.

Waiting rooms, authenticated-user requirements, meeting passwords and careful distribution of meeting links therefore provide more than protection against disruption or “Zoom bombing.” They reduce the number of untrusted parties capable of delivering protocol traffic to participants. These controls cannot replace patching, but they reduce exposure to future vulnerabilities requiring meeting participation.

Organizations hosting public webinars, recruitment interviews, customer support sessions or large external meetings should pay particular attention because participants may be people whom employees have never previously met. A vulnerability requiring only meeting participation is far more useful to an attacker when joining the meeting is expected and socially normal.

The researcher’s description of the attack as “zero-click” should also be understood precisely. The victim still has to be participating in the Zoom meeting, so this is not an internet-wide exploit that can compromise any Zoom user simply because the application is installed. Once the victim and attacker are in the same applicable meeting context, however, no additional action such as clicking an annotation, downloading a file or accepting a prompt is required for the vulnerable parser to process the malicious message.

This makes traditional security-awareness training relatively ineffective against this specific class of attack. There is no suspicious attachment for the user to identify and no obviously fraudulent login page to avoid. The victim may be participating in a completely legitimate meeting while another participant sends malformed protocol data invisibly in the background.

The strongest defensive measure is therefore updating the client. Zoom Workplace users on supported platforms should move beyond affected versions, with the relevant fixed branches including 7.1.5 and 7.0.6. Windows VDI users should ensure they are running at least the corrected versions 7.0.11 or 6.6.16, while Zoom Rooms and Meeting SDK deployments also require corrected builds according to the relevant CVE. Organizations should preferably standardize on the newest supported Zoom release rather than remaining indefinitely on the minimum version containing these fixes.

Enterprise administrators should enforce minimum Zoom versions centrally rather than relying on users to notice update prompts. Collaboration applications are installed on enormous numbers of endpoints, and patch compliance can vary substantially when every employee controls their own update schedule. Minimum-version policies can prevent significantly outdated clients from continuing to join corporate meetings.

Third-party participants create another challenge because organizations cannot always control which Zoom version an external customer or partner uses. Meeting hosts should therefore consider whether highly sensitive discussions genuinely require every optional interactive capability to remain enabled for external attendees. Reducing unnecessary features decreases attack surface even though it cannot substitute for patched clients.

Zoom has also deployed server-side filtering intended to block malicious annotation messages from reaching older clients. This provides valuable defence in depth and can protect clients that have not yet received the update. However, A Security notes an important limitation involving end-to-end encrypted meetings: because Zoom’s servers cannot inspect the encrypted meeting content, server-side filtering cannot necessarily apply in the same way.

This creates an unusual security trade-off. End-to-end encryption provides strong confidentiality protection against intermediaries, but encryption also prevents a trusted service provider from examining traffic for malformed application-level structures. E2EE therefore protects one security property while removing an inspection layer that can mitigate another vulnerability.

The lesson should not be interpreted as an argument against end-to-end encryption. The correct response is to eliminate unsafe parsing in the clients so server inspection is unnecessary for security. Encryption should not have to choose between confidentiality and memory safety. Until all vulnerable endpoints are updated, however, organizations using older clients need to understand that server-side mitigations may not provide equivalent protection in E2EE meetings.

Disabling annotation where it is not required provides another useful risk reduction. Many corporate meetings involve presentations where participants never legitimately draw on shared content. Leaving annotation enabled by default means every client continues supporting and parsing a feature the organization may not actually use. Reducing unused functionality narrows the reachable code surface for future vulnerabilities.

The same principle applies beyond annotation. File transfer, remote control, whiteboarding, third-party meeting applications and participant screen sharing all introduce additional protocol handlers and authorization logic. Collaboration platforms have gradually evolved from video-conferencing applications into complete interactive environments, and every additional feature expands the software exposed to untrusted meeting participants.

Administrators should therefore design meeting policies according to business requirements rather than enabling every feature globally because it is available. Internal engineering collaboration may legitimately require annotation and remote control, while an external company presentation may need nothing beyond audio, video and host-controlled screen sharing.

Endpoint detection also provides useful protection after exploitation. A conferencing application normally has little reason to launch command shells, scripting interpreters or unrelated executables. If `zoom.exe` or the macOS Zoom process unexpectedly starts PowerShell, a shell, Python, Safari or another process, EDR should treat the relationship as suspicious even when the original memory-corruption vulnerability was previously unknown.

This behavioural approach is particularly useful against zero-days. Endpoint security may not recognize the malicious annotation packet, but it can detect unusual actions resulting from successful code execution. Application behaviour baselines therefore provide a layer of protection independent of the specific vulnerability.

Organizations should also collect crash telemetry from Zoom clients. Failed exploitation attempts against memory-corruption vulnerabilities often cause application crashes before an attacker achieves reliable code execution. A sudden increase in Zoom crashes associated with particular meetings or participants could provide early warning of malicious experimentation.

Crash information should be correlated across users rather than treated as isolated desktop-support problems. If several employees experience unusual Zoom crashes while participating in meetings involving the same external identity, that pattern deserves security investigation.

Mobile platforms should not be forgotten. The shared annotation code affects Zoom clients across operating systems, and A Security says the vulnerable engine was present on Windows, macOS, Linux, iOS and Android. Organizations frequently apply strong endpoint controls to corporate laptops while phones and tablets receive significantly less security monitoring, even though executives and administrators routinely join sensitive meetings from them.

Mobile device management should therefore enforce supported application versions and prevent outdated Zoom clients from remaining on managed devices. App-store automatic updates help, but organizations handling sensitive environments should verify compliance rather than assume users have enabled them.

Zoom Rooms are another important category because conference-room systems may remain deployed for long periods with little user interaction. Employees naturally update their laptops more frequently than dedicated meeting-room equipment. Central management should verify that conference-room clients have received the corrected versions rather than assuming appliance-style systems update themselves reliably.

Developers embedding the Zoom Meeting SDK also need to update. A vulnerable SDK incorporated into a third-party application may continue exposing annotation parsing even when ordinary Zoom Workplace applications inside the organization have been corrected. Software inventories should therefore include embedded communication SDKs and not merely installed desktop applications.

The incident further demonstrates the importance of memory-safe software development for network-facing parsers. Bounds-checking failures, uninitialized memory and use-after-free conditions have been responsible for critical vulnerabilities for decades. Where technically feasible, vendors should migrate complex protocol processing toward memory-safe languages or introduce safer abstractions that prevent unchecked copies and invalid object access automatically.

Where native languages remain necessary, fuzzing should be extensive. Annotation protocols are excellent candidates for coverage-guided fuzzing because they contain complex nested objects and attacker-controlled length values. Automated systems can generate malformed structures far beyond the cases engineers are likely to produce manually.

Protocol fuzzing should also test invalid message direction and participant roles. The sender should not merely supply malformed contents inside a valid message; testing should deliberately send valid message types from identities or channels that should never be permitted to originate them. This would have helped expose the trust problem around annotation acknowledgement channels.

The disclosure contains another important dimension: A Security says AI-assisted analysis reduced the effort required to identify and weaponize the vulnerabilities dramatically. The company claims that fewer than 20 prompts to publicly available AI models helped a researcher progress from analysis to a working exploit within a day. That claim comes from the research company itself and should therefore be treated as its reported methodology rather than an independently verified benchmark.

Nevertheless, the underlying trend is important. AI systems can accelerate reverse engineering, source analysis, vulnerability triage and exploit development by helping researchers navigate enormous codebases and reason through unfamiliar functions. Tasks that previously consumed significant manual effort can increasingly be partially automated.

The researchers’ own account also shows that AI did not magically identify the vulnerability immediately. Their initial static analysis ranked thousands of functions and did not prioritize the vulnerable annotation library highly enough. Human-guided dynamic analysis of a live Zoom meeting ultimately redirected the research toward the annotation protocol. This provides a more realistic picture of current AI-assisted vulnerability research: automation can dramatically accelerate capable researchers, but effective target selection and validation still matter.

For defenders, the appropriate response is not attempting to prevent attackers from accessing AI tools. The more practical response is reducing the time between vulnerability discovery, patch deployment and enterprise remediation. If exploit development becomes faster, organizations can no longer assume a long period between vendor disclosure and reliable weaponization.

Continuous attack-surface testing also becomes more important. Vendors and enterprises can use similar AI-assisted analysis to find weaknesses before adversaries do. Security teams should expect vulnerability research to become cheaper on both sides and should invest in faster detection and remediation rather than relying on complexity or proprietary code to discourage attackers.

The Zoom vulnerabilities also demonstrate the danger of assuming closed-source software is inherently harder to analyse. A Security reverse-engineered the Android application and native libraries, traced runtime behaviour and reconstructed significant portions of the proprietary annotation protocol without source access. Attackers can perform the same analysis against widely deployed commercial software.

Security by obscurity therefore provides diminishing protection when modern tooling can automate binary analysis and protocol reconstruction. The protocol must remain safe even after an attacker understands exactly how it works.

The lack of reported exploitation is reassuring, particularly because Zoom patched the vulnerabilities before coordinated public disclosure. Zoom shipped the first client-side corrections weeks before the technical details became public and deployed server-side mitigation for older clients. This reduces the exposure window compared with disclosures where proof-of-concept details appear simultaneously with the first available patch.

Organizations should nevertheless avoid interpreting the absence of known exploitation as evidence that urgent patching is unnecessary. Detailed technical information is now public, and the research explains the vulnerable structures and protocol paths sufficiently to make additional analysis easier. Unpatched clients become more attractive after disclosure, not less.

Incident responders should investigate suspicious Zoom crashes, unusual child processes launched by the application and unexpected endpoint behaviour occurring during external meetings. There are currently no public reports of active exploitation, so organizations should avoid treating every Zoom crash as evidence of compromise, but the possibility should now form part of forensic triage for systems that remained vulnerable.

Meeting security policies should also differentiate between trusted and untrusted participants. Internal authenticated meetings carry a different threat profile from public events where anybody possessing a link may join. Waiting rooms, authenticated-user restrictions and controlled admission reduce the possibility that an unknown attacker can reach endpoint protocol parsers.

Public meeting links should not be reused indefinitely, and personal meeting IDs should not become permanent internet-visible conference rooms. Reusing the same access information allows attackers to return repeatedly and test vulnerabilities against different participants.

Hosts should restrict screen sharing to expected participants, particularly in large external meetings. Because the annotation protocol is connected with shared content, reducing who can become a sharer can reduce some avenues of interaction even though the research indicates both presenter and viewer roles can have attack reach under vulnerable conditions.

Organizations handling particularly sensitive meetings can consider browser-based participation or isolated meeting devices where operationally practical. Browser sandboxes provide a different security boundary from native clients and may reduce the consequences of future client-specific memory vulnerabilities, although browser-based conferencing has its own security considerations and feature limitations.

Virtual desktop infrastructure can provide another isolation option for high-risk users. Executing collaboration software inside a controlled remote environment separates the meeting client from credentials and data stored directly on the employee’s main endpoint. VDI is not a universal solution, but it can reduce blast radius for executives, security personnel and users regularly meeting unknown external parties.

The larger security lesson is that collaboration applications should be treated as internet-facing endpoint software even when they communicate through vendor infrastructure rather than accepting obvious inbound connections. Every meeting participant can provide untrusted media, messages and protocol objects that the local client must parse.

That makes Zoom, Teams, Webex and similar software comparable in some respects to browsers and document readers. Their parsers continuously consume attacker-influenced input, and vulnerabilities in those parsers can create direct paths to endpoint compromise.

Enterprises should therefore maintain aggressive patch policies for collaboration clients. Delaying a conferencing application update for months because the software appears less critical than an operating-system patch misunderstands the exposure. The application is continuously interacting with external participants and processing large volumes of complex native data.

The Zoom annotation vulnerabilities ultimately demonstrate how little visible activity may be required for a sophisticated attack. The victim does not need to click a malicious link, enable a macro or download an executable. They simply join a meeting and allow the conferencing software to perform the function it was designed to perform.

For developers, the lesson is to distrust every value arriving from another participant, enforce message roles explicitly and eliminate unsafe memory handling. For enterprises, the immediate requirement is to update Zoom Workplace, VDI, Zoom Rooms and Meeting SDK deployments to corrected versions and enforce those minimum versions centrally.

For meeting administrators, unnecessary participant capabilities should be disabled and external attendees should pass through controlled admission processes. For endpoint teams, unusual behaviour originating from conferencing clients should receive the same scrutiny as suspicious browser or document-reader activity.

The most important lesson is that a meeting participant is also a network peer supplying structured data to every other participant’s software. Human beings may see a familiar face, a presentation and a few drawings on the screen, but the application sees a continuous stream of attacker-controlled protocol objects.

Security needs to be designed for the second reality, not merely the first.

Anyone sharing their screen on a Zoom call could have taken over the computers of everyone watching, and anyone watching could have taken over the presenter's. The flaw sat in the annotation tool, the feature that lets participants draw and type on a shared screen, and it asked nothing of the victim beyond being in the meeting. No click, no download, no prompt, and nothing on screen to show it

Source: Zoom Annotation Flaws Could Let a Meeting Participant Hijack Another Attendee's Client via The Hacker News — published 11 Aug 2026.