Neo Security’s AI Research Agent Uncovers Critical Remote Code Execution Flaw in Zoom

Neo’s autonomous research agent read a stripped commercial binary, worked out what it is made of, found a component whose critical flaw had been patched upstream seven months earlier, and concluded it was probably reachable from remote input in Zoom's own code. A human research team then proved it: a remote crash with the return address fully under attacker control.

Key takeaways

• Neoverse found Zoom ran pjproject 2.14.1, vulnerable to CVE-2026-25994.
• Neo proved remote reachability: a crafted call crashed Zoom on four platforms.
• Zoom patched within 25 days; update to version 7.2.0 or later now.

Executive summary

Neoverse is a security intelligence engine that researches AI software apps. It reads software the way an expert human reverse engineer would - working out a program's underlying modules, its agentic capabilities, and the risks it carries - without having access to its source code, manifests, or anything the vendor chose to deliver.

Running against the shipping Zoom desktop client, Neoverse derived a component inventory directly from the binary and determined that the SIP/media stack, zSipSdk, statically links a pre-2.17 build of pjproject (pjnath) 2.14.1. That build predates the upstream fix for CVE-2026-25994, a critical (CVSS 3.0 base 9.8) stack based buffer overflow in ICE credential handling - a fix that had been public for roughly seven months when Neoverse first flagged it.

Neoverse concluded that the vulnerable function was reachable from remote input inside the product - a specially crafted input flows to the overflowing copy without a length check.

Neo's research team took the hypothesis and tested it against live clients. It held: on a Zoom-to-Zoom Phone peer-to-peer call, a specially crafted packet is relayed intact by Zoom's cloud SBC, overflows a 128-byte stack buffer on the peer, and overwrites the saved return address with attacker-controlled bytes. Reproduced on the then-current release on: macOS, Windows, iOS and Android. Zoom's security team was quick to acknowledge the report within 1 day and quickly shipped a remediated client. Full timeline below.

What agentic software research means

Traditional endpoint security reasons almost entirely about behavior. It watches processes, syscalls, api calls, network flows, and file operations, and decides whether what a program is doing right now looks malicious. That is a powerful lens, and it has a hard limit: it says nothing about what the software actually is.

Organizations don’t know what software is made of. Not in a meaningful sense. They know the vendor and the version string. They do not know which third-party libraries are compiled into it, which versions, which of those carry known flaws, what network-facing parsers it contains, or - increasingly - what agentic capabilities it ships with and what those can reach.

Neoverse exists to close that gap. It analyzes software to determine:

• What is it built from? The modules and components inside the shipped artifact, including third-party and open-source code no manifest declares.
• What it can do and on whose authority? The capabilities present in the software, like reading files, running commands, touching credentials, reaching the network, or driving a browser or IDE. For AI-enabled software, it also answers whether the software only produces content, acts upon human approval, or acts entirely on its own.
• What risk does it carry? Where untrusted input (a web page, a message, a file, a prompt) can reach those capabilities, through a vulnerable component. Whether the software is itself malicious and how that picture shifts with every version, with each finding backed by the code that proves it.

Deriving a bill of materials from a binary

Most software composition analysis starts from reading manifests - package.json, go.mod, a CycloneDX file handed over at procurement. Every one of those is a declaration: a statement by the producer about what they believe they shipped.

For commercial desktop software, none of those inputs exist publicly. You have an installer, inside it are binaries where third-party C and C++ libraries have been statically linked into a single object, symbol tables have been stripped on at least one platform, and the boundary between vendor code and vendored open source has been erased by the compiler.

Neoverse uses agentic techniques to derive the bill of materials from the artifact itself rather than from a declaration. Two evidence streams feed it, and neither is sufficient alone.

Published attribution data

Zoom publishes a machine-readable open-source attribution map covering the components in its products. This is a real transparency practice and far from universal - many vendors publish nothing comparable. Attribution data has limits by design. It is a licensing artifact, not a security one: it answers which projects are present for compliance purposes, on a publication cadence of its own. A strong prior - not proof of what is inside the binary running on the endpoint right now.

Agentic analysis of the binary

In parallel, Neoverse analyzes the shipped binaries directly - module decomposition, string and constant fingerprinting, structural matching against known library code, and residual symbol recovery where symbols survive. This is where a candidate becomes a confirmed component at a specific version.

Version discrimination was the whole game here. The question was not "is pjnath present" but "is the pre-2.17 pj_ice_sess_create_check_list() present" - a question about a 128-byte buffer and a missing length check, not about a project name.

From component match to reachability conclusion

A matched component plus a matching CVE is an alert, not a finding. Most of them are noise: the vulnerable code path may be compiled out, unused, unreachable from any input an attacker controls, or guarded elsewhere in the product. The volume of alerts is exactly the problem defenders already have.

So Neoverse carried the analysis further, into Zoom's own code. It traced the client's SDP handling and concluded that the vulnerable sink sits at the end of a path a remote call peer can drive, with the attacker-controlled a=ice-ufrag stored in full and passed along without length validation:

parseIceRemoteSdp  (stores a=ice-ufrag, full, unvalidated)
  -> verifyIceSdp
    -> iceAppStartNgeo
      -> pj_ice_strans_start_ice
        -> pj_ice_sess_create_check_list          [overflow]

Neoverse's conclusion was explicit: the flaw is remotely reachable in the shipping product, not merely present in a vendored library. That is a different class of output from a dependency alert. It is a prioritized, evidence-backed hypothesis about a specific product, with the path that justifies it attached.

Why we put human researchers on it

Neoverse produces conclusions at machine scale. We decided this one is worth disclosing because of Zoom’s reach and the vulnerability’s severity.

Zoom is among the most widely deployed communication tools in existence, standard issue across enterprises, governments, healthcare systems and schools, virtually everywhere. A remotely triggerable memory-corruption bug in that client is not an abstract risk to a handful of installations.

The underlying flaw is rated critical, and the primitive is a fully attacker-controlled overwrite of a saved return address - the kind that leads to remote code execution rather than a nuisance crash.

Neo's research team took the hypothesis and reproduced it on live clients.

This is the working model. The agent does the derivation, the matching and the narrowing - the weeks of specialist reverse engineering that make the question answerable at all. Humans decide what matters and prove it. The researcher starts at the last mile instead of the first.

The finding

Root cause

In pjproject (2.16 and earlier), pj_ice_sess_create_check_list() in pjnath/src/pjnath/ice_session.c builds a STUN USERNAME of the form <remote_ufrag>:<local_ufrag> in a fixed 128-byte stack buffer, and copies the attacker-controlled remote ufrag with no bound:

char buf[128];   /* pjproject 2.14.1 */
/* pj_strcpy(&username{buf}, rem_ufrag)
     == memcpy(buf, rem_ufrag->ptr, rem_ufrag->slen)  -- no bound */

A 600-byte rem_ufrag copies 600 bytes into a 128-byte buffer. Upstream fixed this on 2026-02-11 in pjproject 2.17 (commit 063b3a155) by bounding the buffer and rejecting over-long credentials:

- char buf[128];
+ enum { MAX_USERNAME_LEN = 512 };
+ char buf[MAX_USERNAME_LEN];
+ if (rem_ufrag->slen >= MAX_USERNAME_LEN ||
+     ice->rx_ufrag.slen > MAX_USERNAME_LEN - 1 - rem_ufrag->slen)
+     return PJ_ETOOBIG;

The client analyzed in this report vendored the pre-fix 2.14.1.

Reachability and proof of concept

On a Zoom-to-Zoom Phone call the client switches to ICE mid-call. The received SDP is parsed inside zSipSdk and flows to the sink along the path above with no length validation, and Zoom's cloud SBC relays an over-long a=ice-ufrag to the peer intact.

To demonstrate it, two same-tenant Zoom Phone extensions were placed on a P2P call. The attacking client advertised a=ice-ufrag = "A"x600 in its ICE offer - implemented by hooking encodeSessionInSdp at runtime while keeping the attacker's own internal ufrag short, so the attacker does not self-crash. A real attacker would use a custom client or a custom ICE endpoint. The SBC relayed the offer; the victim's create_check_list overflowed.

macOS - process crashed:

Exception: EXC_BAD_ACCESS (SIGSEGV) / KERN_INVALID_ADDRESS at 0x13e959.  Faulting thread 22.

Faulting-thread backtrace:
  zSipSdk +0x688660  pj_pop_exception_handler_
  zSipSdk +0x688580  pj_throw_exception_
  zSipSdk +0x685504
  zSipSdk +0x68b1ec  pj_pool_allocate_find
  zSipSdk +0x694930  pj_strdup
  zSipSdk +0x699364  pj_ice_sess_create_check_list
  ?       +0x414141414141

Windows - with attached WinDbg:

(f2cc.d53c): Access violation - code c0000005 (first chance)
VCRUNTIME140!__except_validate_jump_buffer_common+0x24 [jbcxrval.c @135]:
00007ff9`b39add58 4c8b4210  mov r8,qword ptr [rdx+10h]  ds:0000000000000010=????????????????
0:001> kb
00 VCRUNTIME140!__except_validate_jump_buffer_common+0x24
01 VCRUNTIME140!__except_validate_jump_buffer+0x24
02 VCRUNTIME140!longjmp+0x14
03 zSipSdk!sqlite3_backup_remaining+0x35808
04 zSipSdk!sqlite3_backup_remaining+0x32c30
05 zSipSdk!sqlite3_backup_remaining+0x32650
06 zSipSdk!sqlite3_backup_remaining+0x3308c
07 41414141`41414141

iOS

Process: Zoom [1753]
Identifier: us.zoom.videomeetings
Version: 7.1.5 (37198)
OS Version: iPhone OS 26.6.1 (23G83)
Architecture: ARM64

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Address: 0x000000000008c101
Faulting Thread: 63
PC: 0x000000010407c46c
FAR: 0x000000000008c101
ESR: Data Abort - byte read Translation fault

Backtrace:
0 Zoom 0x000000010407c46c
6 ??? 0x0000004141414141

Severity and impact

The in-product score is narrower than the generic case because reaching the sink requires a call. The corruption primitive is identical: a fully attacker-controlled, arbitrary-length linear stack overwrite of the saved return address and jmp_buf. Successful exploitation would allow an attacker to execute arbitrary code remotely on a victim machine, triggered by a call.

Affected builds

Users running Zoom with a version earlier than 7.2.0 on macOS, Windows, iOS, Android are affected, and encouraged to update their version immediately.

Zoom's response

Zoom's security team handled this disclosure quickly and professionally.

What this opens up for endpoint security

One CVE in one client is a footnote. The capability that produced it is not.

Endpoint security has spent two decades getting very good at watching what software does. It has never been able to answer, at scale, what software is. That question has been dependent on human reverse engineers - expensive, slow, and available for a small fraction of the binaries running in any real environment. With agentic driven research - a long list of previously impractical things become routine:

• Understanding agentic capabilities in shipped software. As more applications embed AI agents, tool access and autonomous behavior, the security question shifts from what a program does today to what it is capable of invoking.
• Composition you can actually verify. A bill of materials derived from the binary on the endpoint, not from the document the vendor supplied at procurement - and kept current as versions change underneath you.
• Reachability-aware prioritization. The difference between "this binary contains a vulnerable library" and "this flaw can be triggered by a remote peer in this product" is the difference between an alert queue and a decision. Agents can make that determination per product, at scale.
• Pre-deployment vetting that means something. Evaluating a vendor binary before it lands on ten thousand endpoints, rather than trusting an attestation and finding out later.
• Supply chain drift detection. Noticing when a routine auto-update quietly re-vendors a component, or fails to.

None of this replaces human researchers. This report exists precisely because humans took an agent's conclusion and proved it. What changes is the ratio: the agent covers the whole fleet's software, continuously, and surfaces the small number of things worth a human's week. Applied across every binary in an enterprise rather than one application at a time, that is a different kind of endpoint security than the industry has been able to build so far.

Key takeaways

Agentic research changes what a defender can know about their software. Comprehension of a binary - its components, its capabilities, its reachable risk - has always been possible and never been scalable. That constraint is lifting.

Your real dependency inventory is in the binary, not the manifest. Every declared SBOM is a statement of intent. For statically linked native code, the declaration and the artifact diverge silently, and conventional SCA will not tell you when.

Reachability is what turns an alert into a finding. A component match is a starting point. Establishing that a flaw can actually be triggered in the shipping product is what justifies anyone's attention - and it is now something a machine can reason about.

Vendor speed and transparency still decide the outcome. Published attribution data supported this analysis; a security team that triaged and patched quickly kept it from becoming an incident. Both behaviors deserve to be named.

About Neoverse

Neoverse is a security intelligence engine for AI software apps: a continuously updated map of the software on today's endpoints, from desktop apps and IDEs to browser extensions, MCP servers and skills. Drawing on both static and runtime evidence, its agents establish what each product is built from, what it can do and on whose authority, what risk it carries, and how common it is in organizations like yours. That risk ranges from reachable vulnerabilities and AI features that can be steered to dangerous combinations of capabilities and outright malicious behavior, tracked across every version. Neo's platform can automatically alert on and block risky AI software, so security, compliance and AI governance teams can govern that software, not just read about it. Anyone can sign in to Neoverse and look up the security verdict for an MCP server, agent skill, desktop app, or browser or IDE extension before it reaches their machine. To see a deeper analysis and learn more about how Neo can protect your organization, request a demo.