CVE-2021-27561

What it actually does

This is an unauthenticated network command-injection vulnerability in Yealink Device Management 3.6.0.20. The vulnerable API path, /sm/api/v1/firewall/zone/services, accepts attacker-controlled input that is passed to an operating-system command without safe validation or escaping. Because the service executes with root privileges, successful exploitation can result in arbitrary command execution as root, enabling full compromise of the appliance or server. The CVSS 9.8 rating reflects that exploitation is remote, low complexity, requires no authentication, and can fully compromise confidentiality, integrity, and availability.

Why it matters to the business

A vulnerable Yealink Device Management instance can be taken over remotely without valid credentials. An attacker could disrupt phone/device-management operations, alter configuration, steal sensitive management data, pivot further into the network, install persistence, or use the server as infrastructure for additional attacks. This vulnerability is listed in CISA KEV, has documented in-the-wild exploitation, and had a CISA remediation deadline of 2021-11-17, so any remaining exposure should be treated as urgent and potentially already targeted. The provided affected-product metadata references tensorflow/tensorflow fixed at commit 37c01fb5e25c3d80213060460196406c43d31995, which does not align with the Yealink Device Management vulnerability description; organizations should verify product inventory and vendor advisories rather than assuming that TensorFlow remediation addresses this Yealink issue.

How an attack unfolds

An attacker first identifies an internet-facing or internally reachable Yealink Device Management 3.6.0.20 instance. Because the vulnerable endpoint does not require authentication, the attacker sends a crafted request to /sm/api/v1/firewall/zone/services containing input that breaks out of the intended firewall-service handling logic and is interpreted by the underlying shell. The application executes the injected command as root. From there, the attacker can run reconnaissance commands, write or download tooling, create persistence, modify device-management settings, collect credentials or configuration files, and use the compromised management host to reach managed devices or adjacent internal systems. Given KEV status and high EPSS, exploitation should be assumed plausible for exposed instances even if no named actor attribution is available.

How to fix it

Upgrade Yealink Device Management to a vendor-supported version that corrects the unauthenticated command injection. If an official fixed Yealink version is not immediately identifiable, contact Yealink support, obtain the current patched release, and validate that the vulnerable /sm/api/v1/firewall/zone/services behavior is removed or safely handled. Do not rely on the supplied TensorFlow fixed commit 37c01fb5e25c3d80213060460196406c43d31995 for this Yealink vulnerability, as the product metadata is inconsistent with the described flaw. Until upgraded, remove Yealink DM from internet exposure, restrict access to trusted administrative networks or VPN, enforce firewall allowlisting, place the service behind strong authentication where possible, and monitor or block requests to the vulnerable endpoint. If exposure existed, perform incident-response review before returning the service to production, because exploitation yields root-level access.

How to confirm the fix worked

Confirm the running Yealink Device Management version and verify it is no longer 3.6.0.20 or any other vendor-confirmed vulnerable release. Validate that the management interface is not directly reachable from untrusted networks. Review web-server, application, reverse-proxy, and network logs for requests to /sm/api/v1/firewall/zone/services. In a controlled authorized test, send a benign request that exercises the firewall zone services API and confirm user input is treated as data rather than executed by the operating system; do not run destructive commands. Check host telemetry to ensure the Yealink DM web/application process is not spawning shells or network utilities. Confirm compensating controls such as ACLs, VPN requirements, WAF rules, and segmentation are active.

Typical attack path

1. Scan for Yealink Device Management web interfaces, especially exposed management portals running version 3.6.0.20.
2. Send unauthenticated HTTP requests to /sm/api/v1/firewall/zone/services to determine whether the endpoint is reachable and vulnerable.
3. Inject operating-system command syntax through vulnerable request parameters handled by the firewall zone services API.
4. Execute commands as root under the context of the Yealink DM service.
5. Stage follow-on activity such as downloading tools, modifying files, creating accounts or keys, or opening outbound command-and-control connections.
6. Collect device-management configuration, credentials, logs, or other sensitive operational data.
7. Use the compromised management server to pivot to managed phones, adjacent systems, or internal services.

How to detect it

Use web access logs, reverse-proxy logs, WAF logs, application logs, EDR telemetry, shell history, auditd/sysmon-style process events, DNS logs, and network flow records. Search for any request to /sm/api/v1/firewall/zone/services, particularly unauthenticated requests, requests from unfamiliar sources, bursts of probing, nonstandard user agents, HTTP 500 responses, or parameters containing command separators and URL-encoded shell characters. On the host, look for the Yealink DM service or web-server process spawning /bin/sh, /bin/bash, busybox, wget, curl, nc, ncat, python, perl, chmod, chattr, iptables, or similar utilities. Review /tmp, /var/tmp, /dev/shm, web application directories, cron locations, systemd unit paths, authorized_keys files, and recently modified binaries or scripts. Check outbound connections shortly after suspicious requests, especially to unfamiliar IPs over HTTP, HTTPS, DNS, SSH, or high-numbered ports. Because this is KEV-listed and long public, absence of a ransomware flag does not reduce the need to hunt for prior exploitation.

• /sm/api/v1/firewall/zone/services
• GET /sm/api/v1/firewall/zone/services
• POST /sm/api/v1/firewall/zone/services
• /sm/api/v1/firewall/zone/services?
• %3B
• %7C
• %26%26
• %60
• %24%28
• ;wget
• ; curl
• |wget
• | curl
• &&wget
• && curl
• `wget
• `curl
• $(wget
• $(curl
• /bin/sh -c
• /bin/bash -c
• busybox wget
• chmod +x /tmp
• chmod +x /var/tmp
• chmod +x /dev/shm
• /tmp/
• /var/tmp/
• /dev/shm/
• /etc/cron.d/
• /etc/crontab
• /var/spool/cron/
• /etc/systemd/system/
• /root/.ssh/authorized_keys
• wget http://
• curl http://
• nc -e
• ncat -e
• bash -i
• /dev/tcp/

What your security team should do

• Treat any exposed Yealink Device Management 3.6.0.20 instance as a priority-one remediation item because the vulnerability is unauthenticated, root-level, KEV-listed, and actively exploited in the wild.
• Immediately inventory Yealink Device Management deployments and verify whether any are internet-facing or reachable from broad internal networks.
• Patch to a vendor-supported fixed Yealink DM release; if patching is delayed, isolate the service and restrict access to trusted administrative sources only.
• Hunt historical logs for access to /sm/api/v1/firewall/zone/services, especially requests containing shell metacharacters, encoded command separators, or references to download/execution utilities.
• Perform host-level compromise assessment on any vulnerable or formerly exposed system, including process history, new files, cron/systemd changes, unauthorized accounts, SSH keys, outbound connections, and suspicious child processes.
• Rotate credentials and secrets stored on or accessible from the management server if exploitation is suspected or cannot be ruled out.
• Add network and application-layer detections for unauthenticated access attempts to the vulnerable URI and for web-service processes spawning shells or command-line download tools.
• Verify the inconsistent TensorFlow package metadata with software-composition tooling, but handle Yealink DM remediation separately from TensorFlow dependency remediation.