CVE-2026-22844 — Zoom Node Multimedia Router (MMR)

Type: Command Injection → Remote Code Execution (RCE)
CVSS v3.1 Score: 9.9 (Critical)
Severity: Critical
Exploitability: Remote network exploitation through meeting traffic
Exploit Availability: No confirmed public exploit code yet
Official Patch / Upgrade: https://www.zoom.com/en/trust/security-bulletin/zsb-26001/

What is this vulnerability?

CVE-2026-22844 is a serious flaw in the Zoom Node Multimedia Router (MMR) component used in hybrid Zoom meeting deployments (also applies to Meeting Connector deployments). The issue stems from improper handling of input received from meeting participants or other network traffic that the MMR processes.

In simple terms: the code that processes participant input on the MMR didn’t properly clean or validate that input. That means someone with access to the MMR — for instance, a participant in a Zoom meeting that uses that MMR — could insert or embed special characters or command fragments into legitimate protocol fields. The MMR’s backend code could then mistakenly hand those fragments to a system shell for execution.

If executed, those crafted fragments allow an attacker to run arbitrary operating system commands on the MMR box itself. That’s why it’s rated remote code execution — the attacker can run their own commands on the device without logging in or having admin rights, simply by sending network traffic that reaches the vulnerable MMR service.

Impact in real-world terms:
If exploited, an attacker can take over the MMR server, run malware, read files, disrupt or intercept meetings, and potentially use that foothold to move laterally within the affected environment.

How could it be exploited?

This isn’t a phishing trick or something that requires a user to click a link. Because the MMR is a service that processes network traffic, exploitation could happen simply by sending specially crafted data to it.

In practice an attacker would:

1. Identify an MMR instance running a vulnerable version (anything older than 5.2.1716.0).
2. Ensure they can send network traffic to that MMR — typically by being in a meeting that uses it or by direct network access.
3. Send payloads that include shell escape sequences (;, &&, backticks, $() etc.) embedded in fields that are normally part of meeting control or session messages.
4. When the MMR processes that data, the underlying code improperly concatenates it into a system command, causing the injected parts to run.

Because the vulnerability is in a high-privileged component of Zoom’s meeting infrastructure, this leads to critical impact — basically full compromise of the MMR host.

Is there a public exploit or PoC?

As of now there’s no confirmed public proof-of-concept exploit available. Security teams should assume a proof-of-concept could be developed quickly given the nature of the vulnerability. If exploit code leaks, attackers could weaponize it fast. That’s why even without a public PoC, impacted installations should immediately be patched.

How to detect attempted exploitation or proof-of-concept tests

1. Look for unusual or suspicious input patterns

Check logs or network captures for any of the following inside request fields:

• ; — semicolon used to chain commands
• && — logical and in shell
• `...` — old-style command execution
• $( & ) — modern command substitution

These sequences don’t normally appear in Zoom protocol content, so their presence should be investigated.

2. Application and service logs on the MMR host

Look for:

• Unexpected errors or unparsed lines in Zoom Node / MMR logs
• Log entries showing input with shell metacharacters
• Sudden service restarts or crash logs correlating with unusual input

3. System process creation logs

Use host auditing (Linux auditd or equivalent) to track if the MMR service ever spawns:

• Shell processes (sh, bash)
• Tools not normally used by Zoom (e.g., nc, curl, scripts)
• Processes with unusual command line arguments

4. Outbound network connections

If the MMR is compromised, attackers may:

• Reach back to attacker-controlled hosts
• Create tunnels or reverse shells

Monitor outbound connections from MMR hosts to unfamiliar destinations or ports.

Example benign test payloads

Important: Only run these in a secure test setup where you control and own the MMR infrastructure. Do not test on production systems without explicit authorization.

The goal here is to produce a recognizable marker if the input is incorrectly executed:

test; echo VULN_TEST

dummy && echo VULN_TEST

normal$(echo VULN_TEST)

If after injecting any of these you see the text VULN_TEST showing up in system output or error logs where it shouldn’t be, that’s a strong sign of command injection behavior.

Detection Rules

You can use these as starting points and adapt them to your own security toolset.

SIEM search example

Look for suspicious fields containing shell metacharacters:

index=zoom_node_logs
| search message="*;*" OR message="*&&*" OR message="*`*`*" OR message="*$(*"

If logged fields unexpectedly include those characters, investigate.

Host-based rule example

Alert when MMR process spawns /bin/sh or equivalent without expected context

How to respond if you suspect exploitation

1. Isolate the MMR node from the network but preserve logs and state for forensics.
2. Take forensic snapshots of the system image and memory.
3. Collect all relevant logs, including MMR logs, host syslogs, audit logs, and network captures.
4. Rotate credentials used by the MMR and associated systems.
5. Apply the official patch (see link at top).
6. Look for persistence mechanisms (unauthorized accounts, scheduled tasks, unusual binaries).

This approach lets you contain, investigate, and recover without wiping evidence.

Mitigations (short list)

• Update immediately to Zoom MMR version 5.2.1716.0 or later using the official Zoom support process.
• If you cannot patch instantly, restrict network access to the MMR interface to trusted hosts only.
• Enable logging and monitoring so you can catch suspicious input early.
• Review access controls and ensure only authorized participants can reach the MMR.

Why this is serious

Unlike many client-side flaws that require user interaction, this vulnerability targets a server-side component of Zoom’s hybrid meeting infrastructure. That means:

• An attacker doesn’t need to trick a user into clicking a link
• The vulnerability can be triggered simply by participating in a meeting
• The resulting compromise gives full control over the meeting router

That combination is why it has a critical score (9.9) and why administrators must act quickly.

Official Patch / Upgrade Link

🔗 Update and remediate using the official Zoom bulletin:
https://www.zoom.com/en/trust/security-bulletin/zsb-26001/

Final Takeaway

CVE-2026-22844 is a critical remote code execution vulnerability in Zoom’s Node Multimedia Router (MMR) caused by improper input handling that allows command injection. An attacker with network access to a vulnerable MMR—potentially even a meeting participant—could execute arbitrary operating system commands on the MMR host.

This issue is especially dangerous because it affects a server-side meeting infrastructure component, not an end user client. Successful exploitation could lead to full takeover of the MMR, meeting disruption or interception, data exposure, and use of the compromised system as a launch point for further attacks inside the network.

There is no confirmed public exploit code yet, but the vulnerability is straightforward to weaponize, making patching urgent.