CVE-2025-34152

What it actually does

This is an unauthenticated OS command injection flaw in the Shenzhen Aitemi M300 Wi‑Fi Repeater, hardware model MT02. The vulnerable `/protocol.csp?` endpoint passes the `time` parameter into the underlying operating system `date -s` command without sufficient input validation or shell metacharacter handling. An attacker who can reach the device’s management interface from the local, adjacent, or exposed network can inject additional operating system commands and execute them with the privileges of the web management process. Successful exploitation can enable full device compromise, configuration tampering, traffic interception, malware installation, persistence, and lateral movement into networks that trust the repeater.

Why it matters to the business

Compromise of a Wi‑Fi repeater can give an attacker control over a network access device, allowing them to disrupt connectivity, observe or redirect traffic, pivot into internal systems, or add the device to a botnet. Because exploitation is unauthenticated, weaponized, and has a high EPSS score of 0.60875, exposed or reachable devices should be treated as high-risk even though the vulnerability is not currently listed in CISA KEV. The issue is especially concerning for small offices, branch locations, retail sites, and home-office networks where low-cost repeaters may be unmanaged, unmonitored, or excluded from normal patch programs.

How an attack unfolds

An attacker first identifies a reachable Shenzhen Aitemi M300/MT02 repeater management interface, typically from the same Wi‑Fi/LAN segment or from the internet if the interface has been exposed through forwarding or misconfiguration. The attacker then sends an unauthenticated HTTP request to `/protocol.csp?` with a malicious `time` parameter containing shell metacharacters. Because the device passes that parameter to the internal `date -s` command without proper sanitization, the injected command is interpreted by the operating system. The attacker can use this execution primitive to run reconnaissance commands, download a secondary payload using utilities commonly present on embedded Linux devices, modify startup scripts, open a reverse shell, change DNS or routing behavior, or install botnet malware. This vector is stealthier than some configuration-changing paths because exploitation does not necessarily reboot the device or visibly alter settings in the web interface.

How to fix it

Apply vendor-provided firmware that explicitly fixes command injection in the `/protocol.csp?` `time` parameter if available. No fixed version information was provided, so organizations should check Shenzhen Aitemi/OEM firmware channels and hardware reseller advisories for MT02/M300 updates. If no patch is available, remove the device from production, replace it with a supported product, or strictly isolate it. At minimum, disable internet exposure of the management interface, block WAN-to-management access, restrict management to a dedicated administrative VLAN, use firewall rules to permit only trusted admin hosts, disable unnecessary remote administration features, rotate Wi‑Fi and administrative credentials, and monitor for suspicious outbound connections. Because embedded network devices are often difficult to clean after compromise, suspected compromised units should be factory reset, re-flashed with known-good firmware where possible, reconfigured from scratch, and considered for replacement.

How to confirm the fix worked

Confirm whether any Shenzhen Aitemi M300/MT02 devices are present by asset inventory, wireless infrastructure surveys, DHCP leases, ARP tables, switch MAC address tables, vulnerability scanning, and physical inspection. Verify that the management interface is not reachable from the internet and is only reachable from approved administrative networks. Validate firmware status against vendor documentation when available. Use a safe, non-destructive assessment process: confirm whether `/protocol.csp?` is accessible without authentication and whether the `time` parameter is accepted, but avoid sending command-execution payloads on production devices. After remediation, confirm that unauthorized clients cannot reach the management endpoint, that suspicious metacharacters in the `time` parameter are rejected or safely handled, and that configuration changes survive reboot without unexpected scripts, processes, or network connections. For replaced or isolated devices, verify firewall rules, VLAN segmentation, and absence from external scan results.

Typical attack path

1. Discover a reachable Shenzhen Aitemi M300 Wi‑Fi Repeater / MT02 management interface on a local, adjacent, or exposed network.
2. Probe the HTTP service and identify the `/protocol.csp?` endpoint.
3. Send an unauthenticated request containing command-separator characters in the `time` parameter.
4. Achieve command execution through unsafe invocation of the device `date -s` command.
5. Run basic system reconnaissance such as identifying architecture, network interfaces, processes, writable paths, and available download tools.
6. Retrieve or stage a payload using embedded utilities such as wget, curl, tftp, ftpget, or busybox where available.
7. Establish persistence or recurring execution using startup scripts, cron-like mechanisms, modified configuration files, or watchdog abuse.
8. Use the compromised repeater for traffic interception, DNS/router manipulation, botnet activity, credential harvesting, or lateral movement.

How to detect it

Review HTTP access logs from the device if available, upstream reverse proxies, firewall web logs, IDS/IPS telemetry, packet captures, and network detection tools for unauthenticated requests to `/protocol.csp?` where the `time` parameter contains shell metacharacters, URL-encoded metacharacters, command substitution, or embedded download/execution commands. Because many low-cost repeaters have limited local logging, prioritize network-side evidence: firewall sessions from untrusted clients to the device management IP, IDS alerts for command injection, DNS lookups from the repeater to unusual domains, outbound HTTP/TFTP/FTP connections from the repeater, and new persistent connections to external IPs. Inspect the device, where possible, for unexpected processes, modified startup scripts, altered DNS/gateway settings, unknown admin settings, new cron-like entries, and writable temporary-directory payloads. Look for common embedded-Linux post-exploitation utilities such as `wget`, `curl`, `tftp`, `busybox`, `sh`, `nc`, or architecture-specific dropped binaries executed shortly after suspicious `/protocol.csp?` requests. If the device has no reliable forensic capability, correlate switch, DHCP, DNS, firewall, and wireless-controller logs around the suspected exploitation window and consider replacement after preserving available network evidence.

• /protocol.csp?
• time=
• GET /protocol.csp?
• POST /protocol.csp?
• /protocol.csp?time=
• time=;
• time=%3B
• time=|
• time=%7C
• time=`
• time=%60
• time=$(
• time=%24%28
• /protocol.csp?time=%3B
• /protocol.csp?time=%7C
• /protocol.csp?time=%60
• /protocol.csp?time=%24%28
• /protocol.csp?time=*wget*
• /protocol.csp?time=*curl*
• /protocol.csp?time=*tftp*
• /protocol.csp?time=*ftpget*
• /protocol.csp?time=*busybox*
• /protocol.csp?time=*chmod*
• /protocol.csp?time=*sh*
• /protocol.csp?time=*nc*
• /protocol.csp?time=*telnetd*
• /protocol.csp?time=*dropbear*
• date -s

What your security team should do

• Immediately inventory networks for Shenzhen Aitemi M300 / MT02 Wi‑Fi repeaters and any rebranded/OEM equivalents.
• Prioritize remediation as high urgency because exploitation is weaponized and EPSS is high, even though the issue is not currently in CISA KEV.
• Remove internet exposure for all embedded device management interfaces, especially `/protocol.csp?`, and block inbound access from untrusted networks.
• If a vendor fix is available, upgrade firmware promptly; if no fixed firmware exists, plan device replacement or strict isolation.
• Treat devices with evidence of suspicious `/protocol.csp?` requests as potentially compromised and perform reset/reflash/replacement rather than relying only on configuration review.
• Hunt proxy, firewall, IDS, and DNS logs for requests to `/protocol.csp?` containing shell metacharacters or download commands in the `time` parameter.
• Monitor compromised-device behaviors such as unexpected outbound connections, DNS changes, new listening ports, repeated connections to public IPs, and traffic to known botnet infrastructure.
• Rotate administrative and Wi‑Fi credentials after remediation, especially if the repeater handled trusted network traffic.
• Add network-device firmware and management interface exposure checks to recurring vulnerability management and external attack surface management programs.