{"slug": "zoomsday-zoom-zero-click-vulnerabilities-via-annotation", "title": "ZOOMSDAY, Zoom Zero-Click Vulnerabilities Via Annotation", "summary": "Ⓐ Security, an autonomous offensive security platform, discovered a critical zero-click remote code execution vulnerability in Zoom's annotation feature affecting all Zoom Workplace clients up to version 7.0.5, allowing an attacker in a meeting to take over any participant's device without user action. The exploit was developed using fewer than 20 prompts on publicly available AI models in under 24 hours, and Zoom has released fixes in versions 7.1.5 and 7.0.6, with the vulnerabilities tracked as CVE-2026-53413 and CVE-2026-53414.", "body_md": "A critical vulnerability in Zoom, a platform used by 70% of the Fortune 100, discovered by publicly available frontier models, allows an attacker participating in a meeting a zero-click remote code execution on all meeting participants across all native clients. This research emphasizes the risk of weaponized AI and how vulnerable we are as an industry.\n\n## Executive Summary\n\n- Ⓐ Security, the Autonomous Offensive Security and Remediation Platform, discovered a critical flaw in Zoom that let an attacker take complete control of another user's device during a live call. No click, no download, and nothing required of the victim but being in the meeting. The vulnerability is present in every version of Zoom on every device and operating system: Windows, Mac, iPhone, Android and Linux. The vulnerability exists in all versions up to and including 7.0.5.\n\n- All Zoom Workplace clients on all supported platforms before version 7.1.5 and 7.0.6 using end-to-end encryption settings are still vulnerable. We recommend updating your clients to the latest version.\n\n- The entire operation, from finding the flaw to building a working exploit, was carried out by Ⓐ using fewer than 20 prompts on publicly available AI models in under 24 hours.\n\n- This class of capability would previously have only been available to nation-state threat actors, but the model requiring elite teams, months of effort, and weapons-grade budgets has collapsed. Today, a single researcher was able to develop a nation-state-level exploit in less than a day.\n\n- The vulnerability is a memory-corruption bug that exploits Zoom's annotation feature.\n\nZoom annotation is built on a proprietary protocol — closed code with no public documentation or specification. Ⓐ Research was able to exploit the fact that every Zoom client automatically parses whatever it receives, sending a specially crafted message to corrupt the receiving client's memory and run code on it. The protocol opens a direct channel between a viewer and a sharer, letting the attacker target each participant individually.\n\n- The exploit enables attackers to either join or host a meeting, target any participant, and take over their machine with no required action from the victim and no visual cue indicating the compromise.\n\n- Once the nefarious code is running on the victim's device, the threat actor can quietly steal personal data, switch on the microphone or camera to spy on the target, or install other malicious software. In a large call, that's a room full of targets from a single message, with no safe seat in it.\n\n- Ⓐ Security collaborated with Zoom to address the issue. The company reported the vulnerability to Zoom in June 2026. Zoom acknowledged receipt and deployed client-side and server-side fixes.\n\n- The first two vulnerabilities are tracked as CVE-2026-53413 and CVE-2026-53414. Zoom has issued a security alert.\n\n- A third vulnerability, CVE-2026-53415, was reported but had already been found and fixed by Zoom before our report.\n\n## Intro\n\nⒶ found a critical, nation-state-grade vulnerability in Zoom in a single working day using an AI agent and models anyone can access today.\n\nExploits like this one are weapons. Governments regulate their export. Criminal organizations pay millions for them. Acquiring one has always required nation-state infrastructure, elite teams, and months of work.\n\nThat barrier is gone.\n\nAI security research has been building to this in steps: first solving CTF challenges, then finding bugs in public bug-bounty programs. That work was impressive, but it lived in controlled or open environments, targets with published scope and known rules. Zoom is neither. It's closed-source enterprise software with no public internals, the kind of target that defenders assume is protected by obscurity and scrutiny. Producing a working exploit here sits in the category nation-states spend months and millions to reach.\n\nThe flaw allowed an attacker to take control of a device during any live Zoom call, with no action required from the victim, no click, no download. It worked in both directions: a compromised presenter could reach every participant, and any participant could reach the presenter. It was confirmed on all platforms Zoom runs on: Windows, macOS, iOS, and Android.\n\nThis matters beyond Zoom. Zoom is a core infrastructure for 70% of the Fortune 100, most of the Fortune 500, and federal agencies. Additionally, it is the platform where millions meet their doctors, lawyers, and families. But the real finding isn't the bug. It's the speed. The barrier to producing this class of weapon has collapsed, and it won't come back.\n\nWe disclosed the vulnerability to Zoom privately; their team engaged quickly and shipped a fix before publication.\n\nThe takeaway for security leaders: defenses built for a world where these weapons were scarce no longer hold. The only durable response is to turn the same capability inward, testing your own environment continuously, before an adversary gets there.\n\n## Technical Deep-dive\n\n### Why Zoom, and where we started\n\nⒶ's mission is to secure modern enterprises against weaponized AI.\n\nThat means testing more than the systems our customers own. It means testing the software they depend on and cannot audit.\n\nZoom is one of those tools. It is closed-source, publishes no protocol specifications, and is deployed nearly everywhere that matters.\n\nWe started from the Android client, version 7.0.4. The Android Package is a container, Dalvik bytecode plus 121 native shared libraries. The Java layer is mostly UI and IPC glue. Anything that touches untrusted bytes at speed lives in native code, so the native side was the target.\n\nThat is still far more surface than anyone can reverse by hand, so the first job was ranking it.\n\n### How we mapped the attack surface\n\nPROMPTI’ve Decompiled Zoom Android v7.0.4. Java in the dex, 121 native`.so`\n\nfiles, IDA available.\n\nMap the attack surface end to end: enumerate the native libraries and what each does, then for every function reachable from a JNI entry point, score its exposure to dangerous sinks (memcpy/strcpy/sprintf families, computed-size allocators) weighted by severity, function size and call depth.\n\nGive me a ranked work queue plus a one-line 'library → entry point → sink class' map.\n\nTo find the targeted library our agents built a static pre-ranker that automatically scored every function reachable from a JNI entry point by its calls to dangerous sinks (memcpy/strcpy/sprintf, computed-size allocators), weighted by CWE severity, function size and call depth. It produced a ranked work queue of 3,762 functions across 70 libraries, topped by the video, image and audio stacks\n\nThat queue told us where Java could reach dangerous code and that turned out to be the wrong question. Its top entries were local paths: frame-capture and render entry points driven by the device's own camera, not by another participant. The one bug we did find on that side of the house, a 32-bit width × height overflow in a native video receive worker, we reached it sits behind a network thread with no JNI entry point at all so a JNI-rooted ranker was structurally blind to it. And it went nowhere: it turned out to be unreachable with the input shapes a real meeting produces.\n\nThat surface came up dry, so we flipped the search: instead of hunting for dangerous code, we hunted for what a remote participant can actually reach. That put the focus on the protocol itself — the messages clients send and receive from each other during a meeting, and how much of each one the sender controls. To find it we traced the client dynamically through a Frida MCP, exercising each meeting feature in a live call while watching which libraries loaded and which functions fired underneath. Annotation, a collaboration feature that lets you draw, type text, add shapes, or place stamps directly on a shared screen or digital whiteboard during a meeting, was the one that paid off: drawing an object lit up `libannotate.so`\n\n, and with it the serialize and deserialize routines that build the message on the sender and rebuild it on the receiver. It's also worth noting that the feature can be exploited whether the user is working with the tool in a particular meeting or not. It is “always on” and in older versions of the client “always vulnerable”\n\nThat put `libannotate.so`\n\nat the front. The static score had ranked it #45. It sits directly on the protocol that's reachable from remote — a proprietary, non-CVE library with complex messages that are built and sent over the wire and received on the other user's client. Also worth mentioning: the same source compiles into the Windows, macOS, iOS and Android clients, so a bug here isn't one-platform, it runs across the entire product line.\n\n### Reverse engineering the Annotation library\n\nPROMPT\n\nReverse the annotation protocol in IDA.\n\nI want the full opcode → handler map: which message types construct objects, which carry a full body vs. an id-only reference, how objects are created / synced / removed / full-synced, and where each handler forwards the deserialized object.\n\nRename handlers in the IDB as you go.\n\n#### Annotation objects\n\nThe first thing to understand is that nothing about a drawing travels as an image.\n\nWhen a participant draws on a shared screen or whiteboard, their client doesn't ship pixels, it builds a typed in-memory object describing the mark.\n\nA freehand stroke becomes a `CAnnoObjSmoothPen`\n\n; a text box becomes a `CAnnoObjTextbox`\n\n; shapes, highlights, and arrows each have their own class.\n\nEvery one of them descends from a common base, `CAnnoObj`\n\n, which carries the shared header that contains object type, flags, geometry. Each subclass adds its own fields afterwards.\n\nTo leave the machine, that object is **serialized**: flattened into a byte stream and wrapped in a Protocol Data Unit (`CAnnoPduAddObj`\n\nand its siblings: add, update, remove, clear).\n\nThe PDU is what actually crosses the network.\n\nOn the far side the process runs in reverse — the receiver **deserializes** the bytes back into the same object graph and hands it to the renderer. Serialize and deserialize are mirror images of each other, and that symmetry is exactly what made the protocol recoverable: every field written by a `stream_write`\n\non the send side has a matching `stream_read`\n\non the receive side, so walking the caller sets of those two primitives reconstructs the whole grammar, field by field.\n\nThe format itself is self-describing in the worst way for a defender: it is a flat sequence of length-prefixed and count-prefixed reads. The parser reads a value off the wire, then trusts that value to decide how much more to read, how many styled runs a text frame contains, how many code units a glyph buffer holds. Those counts come from the sender.\n\n#### How a drawing reaches every participant\n\nAnnotation PDUs don't go peer-to-peer. They are handed to Zoom's **MMR** (Multimedia Router) server and MMR doesn't blind-fan one client's object out to the whole room, every participant holds a channel to the sharer, and the sharer holds one back to each participant.\n\nUpstream, participant → sharer carries the objects a viewer draws.\n\nDownstream, sharer → participant carries the sharer's replies on that same channel, `DocRequestDrawAck`\n\n, `AddObjAck`\n\nand the receiving client runs them through the full deserialize stack.\n\nNothing on the receiving side enforces that the downstream channel carries only acknowledgements. `CAnnoPduFactory::create`\n\nreads the opcode off the wire and dispatches to that class's deserializer; on the paths traced here there is no sender-role or origin check. `AddObj`\n\nis 0x10001 and `AddObjAck`\n\nis 0x10002. One increment separates \"here is an object\" from \"I received your object,\" and the factory cannot tell which seat the sender occupied.\n\nPut 0x10001 and a serialized object graph where an ack body belongs and the victim reconstructs the object to full depth.\n\nThat is the design bug: an ack is allowed to carry an object body, and the receiver deserializes it.\n\nThe sharer seat is the stronger position, and the asymmetry is reach.\n\nFrom it you hold a direct, addressed channel to every participant, so you can drive one victim's parser at a time.\n\nFrom a viewer seat the same primitive exists but points at exactly one deserializer, the sharer's.\n\n#### The Vulnerabilities\n\nPROMPT\n\nThe deserialize side is remotely reachable — any participant's PDU gets rebuilt on the receiving client. That's the attack surface, so scope everything to those functions. Audit libannotate's object deserializers for memory-safety bugs: wire counts used as sizes, copies with no destination bound, allocations that don't match the bytes actually read.\n\nRESULT\n\nStrongest hit: CAnnoFormatBlock::Deserialize — unbounded copy into a fixed buffer.The function holds four fixed 128-byte buffers. For each one it reads a 32-bit count off the wire and copies 2 × count bytes in. The count is checked only for being non-zero — there is no comparison against the 128-byte destination anywhere in the function, and the copy routine it calls measures only the source, handing over as many bytes as the packet still has left. Neither side is guarding the destination.\n\nThe buffer being filled is the last field in the object, and that object is a member of the 704-byte text range that CAnnoTextFrame::Deserialize builds as a local variable in its own stack frame. So an oversized count does not stop at the end of the object — it keeps writing forward through the frame, into the saved registers and the return address.\n\nBoth halves of the write are attacker-supplied: the count sets how far it runs, and the bytes copied are the packet's own. This is a remotely triggerable stack buffer overflow.\n\nPROMPT\n\nBuildthePDUthatreachesitthroughnormalparsing.Noshortcuts -walkeveryfieldtheparserexpects:thefactorytypefortheobject,theflagbitthatselectsthetext-framebody,thetext-range header,thentheoversizedchannelcountandtheoverflowpayload.Givemethebytelayout,anddeliveritovertherealtransportfromoneclienttoanother.Thevictim'sownparserdoesthework,noinstrumentationonthatside.\n\nRESULT\n\n745-byteAddObj PDU:opcode0x10001,objectflagsbit3(TextFrame),fourthchannelcount0x100.DeliveredfromaviewertothepresenteroverZoom'sownencryptedtransport,withnothingattachedtothevictim:\n\n[F8]HIJACKEDDocRequestDrawAckserialize->emitted745BF8payload(cap128B->745B)\n\n[drain]sub_F9DE4ran\n\n•\n\n•\n\nXX-XXXX:XX:XX.XXX1384513845Flibc:stackcorruptiondetected(-fstack-protector)\n\n### CVE-2026-53413 : The overwrite:\n\nBoth bugs live in the same place: the text annotation. It is a nested object in the protocol, and that is what makes it the richest target.\n\nA text annotation is built in four layers and the receiver rebuilds every one of them from the wire. The CAnnoObj starts with the header which holds a flag bit that describes the object type, value 3 means \"this object has a text body\" and the parser follows it into a CAnnoTextFrame.\n\nThe text frame holds a list of CAnnoTextRange items — one per styled run of text. Each run carries its characters and its formatting, and the formatting lives in a CAnnoFormatBlock: a small header followed by four fixed 128-byte buffers, each holding a UTF-16 string such as a font name. 128 bytes is 64 characters. The wire supplies a character count per buffer, and the parser copies 2 × count bytes into it.\n\nA run can hold a format block in either of two places. Normally it is a member of the range itself, and the range is a 704-byte local variable inside the text frame's deserializer — so it lives on the stack. But a run can also declare an extension: a single gate byte on the wire that, when non-zero, makes the receiver allocate a separate 592-byte child object on the heap, carrying its own format block.\n\nEach count is a 32-bit value taken straight off the wire, and each buffer is a fixed 128 bytes. There is no bounds check to stop a count from exceeding the buffer length. The 4th buffer is the last buffer, so an oversized fourth count writes past the end of whatever object holds it: the 704-byte range on the stack, or the 592-byte child on the heap.\n\n**Stream_Read - **this function is the write primitve that gets the wire input stream, the dst buffer and the wire size and copy to the buffer :\n\n*CAnnoTextFrame::Deserialize*\n\n*CAnnoFormatBlock : *`buf4`\n\nis the last field, so an oversized `count4`\n\nruns off the end of the object:\n\n**CAnnoExtBlock** , **CAnnoExtChild** deserializers (the object allocation on the heap):\n\n### CVE-2026-53414 : The over-read:\n\nA separate bug - the glyph buffer is allocated from a wire count but filled from the packet: the receiver reads a character count, allocates 2 × count + 2 bytes without zeroing them, then copies in however many bytes actually arrived. Send a large count with a short body and the untouched tail is live receiver heap, with a terminating NUL written only at the far end. Confirmed live on the victim's own client. One captured slab held live code and vtable pointers from a single loaded library, alongside resource strings and rendering data - module-base material of exactly the kind an ASLR bypass needs.\n\n### Exploitation: Achieving RCE on MacOS\n\nPROMPTI control`PC`\n\n,`X19–X28`\n\n,`X29`\n\n/`X30`\n\n, and a contiguous stack, with no PAC or canary on this bundle. Find a one-shot shared-cache gadget that turns my controlled registers into a real call with an argument I control. Then prove it executes to completion with a visible effect on the victim, not just a crash or a hung branch\n\nThe macOS `annoter`\n\nbundle ships as plain **arm64 with neither PAC nor stack canary**.\n\nSo the overflow runs clean into the function's epilogue, which restores a batch of registers from the stack and then returns wherever the stack points.\n\nWe just overwrote that stack region, so it restores *our* values and jumps to *our* address.\n\nOne PDU hands us the program counter (`PC`\n\n) plus the callee-saved registers `X19-X28`\n\nand the frame/link pair `X29`\n\n/`X30`\n\n, every one of them loaded straight from our overflow bytes. That is complete control.\n\nWith no PAC to authenticate anything, we don't need a complex exploit. We can just point the return address (`X30`\n\n/`LR`\n\n) at one ready-made instruction sequence (a \"gadget\") in the system's shared library cache, and let the epilogue pre-load the argument registers for us.\n\nThe overwrite plants three things, each landing in the register the gadget uses:\n\nBecause we control `X19`\n\nand `X21`\n\ndirectly, the gadget just copies them into `X0`\n\n/`X1`\n\nand calls, no need to find the values anywhere else. The gadget, the path string, and the argument list all live in the *same* shared cache. macOS shifts that cache by a random amount each boot (ASLR), but shifts it as one block so a **single** leaked pointer rebases all three at once.\n\nOn the hijacked return, `execvp(\"…/Safari\", argv)`\n\nruns and the victim's `zoom.us`\n\nprocess is replaced by the launched app. Fired live against a real target, it **popped Safari open on the victim's Mac.**\n\n#### Leak-free control-flow hijack via heap shaping on Android\n\nPROMPTMy overflow now runs off a heap chunk in a fixed size class instead of the stack.\n\nI have no address knowledge though. can I get control purely through heap shaping, no leak? Spray the same size class to place an object I control adjacent to the overflow source, then corrupt only the low byte of its vtable pointer so the virtual call retargets to an offset inside the module regardless of ASLR slide. Find the un-gated op that fires that vcall, and prove it hijacks PC on an uninstrumented victim from the tombstone alone — layout doing the work an info-leak normally would.\n\nAn alternative path to leveraging the over-read vulnerability is a classic heap spray.\n\nBy spraying arbitrary data objects and partially corrupting their vtable pointers using the heap overflow primitive an attacker can gain controlled code execution.\n\nThe same overflow, using the **heap version **`ExtChild`\n\n(`new(0x250)`\n\n, the 592-byte size class), gives us a controlled write past the end of a chunk. This can lead to code execution but requires some shaping.\n\n**Shape the heap first.** Every `ExtChild`\n\nlands in the same 592-byte size class, so spraying them over `AddObj`\n\nlays them out back-to-back. This lets us place an object we control directly after our overflow source. Now the overflow doesn't spill into whatever happened to be there; it spills into a neighbor whose layout we know exactly. We size it to reach just the neighbor's first field: its **C++ vtable pointer**.\n\nWe can partially overwrite the pointer as our overflow is controlled. A vtable's low bytes are fixed relative to the module base no matter where ASLR loaded the module, so a partial overwrite retargets the virtual call to a chosen offset inside the module with zero address knowledge.\n\n**Triggering the bug.** The corrupted pointer dispatches through an un-gated teardown path: normal wire ops (`RemoveObj`\n\n/ `ModifyObj`\n\n) run a destructor that calls through the child's vtable. It triggers on any participant, viewer or presenter.\n\n## Demo Video\n\n### CVE-2026-53415\n\n### The Sequel - A Second, Independent RCE\n\nOur work on Zoom's annotation engine didn't end with the first bug. The same AI-assisted research surfaced a second, independent flaw in the very same engine.\n\nZoom's parser handles a message type internally numbered **75** - an \"auto-shape\" metadata object (`CAnnoObjAutoMetaShape`\n\n) - by reading attacker-supplied bytes directly into an internal linked-list structure and then unlinking that list, without ever validating the pointers it was handed. Lidor Elias identified and triaged this bug.\n\nThe result is a **write-what-where** primitive: the attacker controls both the value written and the address where it lands, providing a potential path to remote code execution. When shared the bug upon triage, Zoom already knew about it and had deployed a server-side mitigation that filters malicious messages (both to this CVE and the previous) before it reaches clients, but that defense carries the same gap as before: it cannot apply to end-to-end encrypted (E2EE) meetings, where the server is deliberately blind to call content. On E2EE calls, the crafted message passed through untouched and the vulnerability remained fully exploitable. Zoom closed it properly on the client side in version 7.1.5.\n\n## Disclosure\n\nⒶ Research identified this vulnerability on June 8, 2026, and confirmed a working zero-click RCE against Zoom Client v7.0.5 across all platforms the following day. We reported it to Zoom on June 10, and Zoom acknowledged receipt within a day. Their response was fast and thorough: a client-side fix shipped in v7.1.0 just twelve days after our report, and Zoom followed up with a server-side mitigation on July 15 to protect users still running earlier client versions before they could update.\n\nBecause a zero-click RCE requires no user interaction, we prioritized giving customers time to receive both the client patch and the server-side mitigation before publishing. This post follows that coordinated timeline, and we are releasing it alongside CVE assignment.\n\n2026-06-08 - Ⓐ Research discovers the Zoom annotation memory-corruption vulnerability.\n\n2026-06-09 - Zero-click RCE confirmed on Zoom client v7.0.5 (all platforms).\n\n2026-06-10 - Ⓐ Research reports the vulnerability to Zoom.\n\n2026-06-11 - Zoom acknowledges receipt.\n\n2026-06-22 - Zoom deploys client-side fix in v7.1.0 including patch for CVE-2026-53413,CVE-2026-53414.\n\n2026-07-15 - Zoom deploys server-side mitigation for earlier versions.\n\n2026-07-20 - Zoom deploys client-side fix in v7.1.5 including patch for CVE-2026-53415.\n\n2026-08-11 - Public disclosure.\n\n## Guidance for Mitigation\n\nZoom's bulletin [ZSB-26015](https://www.zoom.com/en/trust/security-bulletin/zsb-26015/), [ZSB-26016](https://www.zoom.com/en/trust/security-bulletin/zsb-26016/) & [ZSB-26017](https://www.zoom.com/en/trust/security-bulletin/zsb-26017/) lists the affected products:\n\n- Zoom Workplace, all supported platforms, before version 7.1.5 and 7.0.6 in their respective branches\n- Zoom Workplace VDI Client for Windows, before versions 7.0.11 and 6.6.16 in their respective branches\n- Zoom Rooms, all supported platforms, before version 7.1.0\n- Zoom Meeting SDK, all supported platforms, before version 7.1.0\n\nUpdating closes these CVEs. Until every client is updated, you can disable the **end-to-end encryption **setting. Since Zoom's server-side mitigation, malicious annotation messages are filtered before they reach clients, and enhanced encryption, Zoom's default, leaves that filter in place. E2EE removes it, because a server cannot inspect what it cannot read. E2EE would not have stopped this attack anyway: the attacker sits in the meeting, holding the keys. It has its own uses, just not this one.\n\nBeyond this vulnerability, prepare for the next one, because there will be a next one and not necessarily in Zoom. Every endpoint runs software that parses bytes chosen by outsiders, and you cannot audit any of it.\n\nThe first obvious action is to **patch fast**: a published patch is a map to the bug, so the risk to an unpatched fleet rises the moment a fix ships, and that gap could run to months. In Zoom you can set a per-platform minimum version, for guests as well as staff. But patching is not enough, because your exposure starts when someone finds the bug, not when the vendor hears of it, and exploits of this class are now cheap to produce.\n\nHence, **reducing the attack surface** is just as important, both who can reach you and what they reach. This exploit needed only presence in the meeting, so joining rules are access control: waiting rooms, passcodes, authenticated-users-only, no published personal meeting link. Then cut what nobody uses, because every optional feature is another parser. In Zoom, consider locking annotation, file transfer, whiteboarding, remote control and third-party apps, and limiting screen sharing to hosts. Beyond settings, consider the client itself: Zoom's browser client has no annotation or whiteboarding at all, and what it does run is sandboxed; and where compromise is least acceptable, keep such software off the endpoint and join from a separate device or VDI.\n\nSome attacks will land anyway, so **endpoint protection platforms (EPP/EDR)** are what stop the next step and tell you it happened. Code running inside these applications inherits their permissions, which in a conferencing client means camera, microphone and screen recording. A meeting client has no reason to launch a browser, a shell or a script interpreter, so block it where you can and alert on it everywhere; our exploit made `zoom.us`\n\nopen Safari. Collect client crash reports centrally too, because failed attempts crash long before a working one lands.\n\n## Conclusion & Impact analysis\n\nOne malformed annotation, drawn by anyone in the call, was enough to take over every other device in the room. The same source compiles into the Windows, macOS, iOS, and Android clients.\n\nBut the vulnerability is not the story. The story is what it cost to find it.\n\nThis is closed-source enterprise software with no published protocol, the class of target defenders assume is safe because it is large, scrutinized, and opaque.\n\nProducing a working exploit against it has always been nation-state work: elite teams, months of effort, budgets that governments regulate as weapons.\n\nⒶ did it in a single day, with an AI agent and models anyone can access today.\n\nThat is the shift security leaders have to price in. The barrier that kept these weapons scarce has collapsed, and it will not come back. Attackers already have this capability.\n\nThe only open question is whether defenders reach their own exposures first. The durable response is to turn the same offensive capability inward and run it against your own environment continuously, before someone else does.", "url": "https://wpnews.pro/news/zoomsday-zoom-zero-click-vulnerabilities-via-annotation", "canonical_source": "https://a.security/blog/asecurity-zoomsday", "published_at": "2026-08-13 15:27:59+00:00", "updated_at": "2026-08-13 20:40:35.058706+00:00", "lang": "en", "topics": ["ai-safety", "ai-research", "ai-tools"], "entities": ["Ⓐ Security", "Zoom", "CVE-2026-53413", "CVE-2026-53414", "CVE-2026-53415"], "alternates": {"html": "https://wpnews.pro/news/zoomsday-zoom-zero-click-vulnerabilities-via-annotation", "markdown": "https://wpnews.pro/news/zoomsday-zoom-zero-click-vulnerabilities-via-annotation.md", "text": "https://wpnews.pro/news/zoomsday-zoom-zero-click-vulnerabilities-via-annotation.txt", "jsonld": "https://wpnews.pro/news/zoomsday-zoom-zero-click-vulnerabilities-via-annotation.jsonld"}}