EUVD-2026-83712
GHSA-72pp-r64r-349h
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessExtract app-level auth params from runtime
-
DeliveryCall /account/verify.serv with target email
-
ExploitConfirm account registered
-
ExecutionRetrieve real backend account ID
-
ImpactFeed account ID into takeover (CVE-2026-86553)
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V8 - Authorization Least privilege enforcement
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires that the attacker obtain the SmartLife application-level authentication parameters that the app generates in its own runtime process - these are extractable by anyone running or reverse-engineering the SmartLife app, so they do not constitute a per-user credential barrier. With those params, the attacker calls the backend /account/verify.serv interface over the network. The only meaningful limiting factor is possession of a valid target email address to test; no victim interaction, no per-account authentication, and no non-default configuration are required. Exploitation is confined to ZTE's own SmartLife app ecosystem. |
| Impact | This is a low-to-moderate severity information-disclosure issue, not a genuine privilege escalation despite its tag. The vendor CVSS of 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) assumes PR:L, but the 'authentication parameters' in question are SmartLife APPLICATION-level credentials that the app itself generates at runtime - they are not per-user secrets, so any party who runs or reverse-engineers the app can obtain them. On that basis PR:N is more defensible, raising the real score to roughly 5.3. Impact is confined to confidentiality (C:L): confirming whether an email is registered and, if so, retrieving the backend account ID. There is no EPSS score, no CISA KEV listing, and no public exploit code identified at time of analysis, so this is not a widespread-exploitation priority. Its real significance is as a reconnaissance primitive: it directly feeds the account-takeover sibling CVE-2026-86553, which uses the same /account/verify.serv email→accountID mapping to reset a victim's password. Treat the two together - alone this is low priority; chained it enables targeted takeover. |
| Exploit ScenarioDerived | An attacker extracts the app-level SmartLife authentication parameters from the app at runtime, then directly calls the backend /account/verify.serv endpoint with a target email address to confirm registration and retrieve the real backend account ID. No public exploit code is available, but the mechanism is straightforward and pairs with CVE-2026-86553 to escalate from enumeration to full account takeover. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 20, 2026
Information disclosure in ZTE SmartLife allows an attacker who can extract the app's runtime-generated application authentication parameters to query the backend /account/verify.serv endpoint, confirm whether a target email address is registered, and retrieve the corresponding real backend account ID. The independent assessment treats the issue as network-reachable and unauthenticated from the backend's perspective because those parameters are obtainable by running or reverse-engineering the SmartLife client, though the practical impact is limited to email enumeration and account-ID leakage in ZTE's SmartLife ecosystem, not a full privilege escalation. No CISA KEV entry and no public exploit were identified at time of analysis.
RemediationAI
No vendor-released patch is identified in the provided input; consult the ZTE advisory at https://support.zte.com.cn/zte-iccp-isupport-webui/bulletin/detail/2171542593031840113 and apply any patched SmartLife/ZTESW version once ZTE publishes it. Until a patch is available, the most direct mitigation is to stop treating client-generated application authentication parameters as sufficient authorization for /account/verify.serv: require a server-side, per-user authenticated session or a properly bound token before returning account-existence or account-ID data. As compensating controls, rate-limit and monitor /account/verify.serv for enumeration patterns, add CAPTCHA or challenge-response for repeated lookups, and consider blocking or restricting unauthenticated access to that endpoint at the network edge; these reduce automated harvesting but can affect legitimate app registration checks and may break older clients that rely on the endpoint. If the backend supports it, disable the account-ID return field and reduce the response to a generic registration status, accepting that this may degrade app features that depend on backend account IDs.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected component is ZTE SmartLife's client/backend authentication flow. The SmartLife app generates fresh application-level authentication parameters inside its runtime process and uses them to authorize backend calls; because these values are produced client-side, they can be recovered by anyone who runs or reverse-engineers the app rather than being tied to a specific user's credentials. An attacker can then send requests to the ZTE backend interface /account/verify.serv over the network to test email registration and, for registered accounts, obtain the real backend account ID. The CPE cpe:2.3:a:zte:ztesw:*:*:*:*:*:*:*:* identifies ZTE ZTESW with a wildcard version, so the supplied data does not provide a precise affected version range. The CVE is tagged CWE-269 (Improper Privilege Management), but the independent assessment clarifies that the behavior is better characterized as an authentication/authorization boundary weakness leading to information disclosure, not a true privilege escalation.
Know when Ztesw gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
App-level auth params are not per-user secrets, so PR:N; network endpoint, low complexity; impact is limited to confidentiality disclosure (email-registration + account ID), no integrity or availability effect.
Primary rating from Vendor (zte).
CVSS VectorVendor: zte
DescriptionCVE.org
SmartLife app dynamically generates brand‑new SmartLife application authentication parameters within its runtime process. With the obtained SmartLife application authentication parameters, attackers can directly invoke the backend interface /account/verify.serv to determine whether a target email address is registered for a SmartLife account. If the account exists, the real backend account ID can also be retrieved.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Account takeover is possible in the ZTE SmartLife (ZTESW) app on builds ZTE_SL_V2.8.2_ABROAD and earlier, where an attac
ZTE SmartLife's backend signup interface (/account/person/signup.serv) creates accounts for arbitrary email addresses wi
Exploit-DB