EUVD-2026-83649
GHSA-9f8w-25xq-gfm7
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessInstall and instrument SmartLife app
-
DeliveryExtract runtime app auth parameters
-
ExploitCall /account/verify.serv with victim email
-
ExecutionObtain victim real account ID
-
PersistSpoof app auth + account ID
-
ImpactReset victim password and hijack account
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 the attacker to (1) obtain the SmartLife application authentication parameters by extracting/instrumenting the running SmartLife client (a one-time reverse-engineering step, not per-target), (2) know the target's registered email address, and (3) reach the backend /account/verify.serv interface over the network. Limiting factors: only ZTESW ZTE_SL_V2.8.2_ABROAD and prior versions are affected; the target must be an existing registered SmartLife user; and success depends on the ZTE cloud backend still trusting the spoofed app auth. No victim user interaction is required. |
| Impact | This is a genuine high-priority account-takeover flaw, though signals are thin. The vendor CVSS is 8.8 (AV:N/AC:L/PR:L/UI:N/C:H/I:H/A:H) reflecting full compromise of arbitrary user accounts. I dispute the PR:L: the 'authentication parameters' the attacker uses are SmartLife *application*-level credentials generated in the app's own runtime process, not per-user secrets - any party who runs/reverse-engineers the client obtains them, so this behaves as effectively unauthenticated (PR:N), pushing my own score toward 9.8. There is no EPSS score, no CISA KEV listing, and no confirmed public exploit code (VulDB 407995 is an advisory reference, not a proof-of-concept), so exploitation is not demonstrated in the wild - but the attack requires only a known victim email plus one-time app instrumentation, so weaponization difficulty is low. Net: real, actionable account-takeover risk against a specific consumer product; the missing EPSS/KEV signals indicate no observed mass exploitation rather than low technical severity. |
| Exploit ScenarioDerived | An attacker reverse-engineers the SmartLife client to extract the application authentication parameters it generates at runtime, then calls the backend /account/verify.serv endpoint with a target's registered email to obtain that account's real internal ID. Replaying the spoofed application auth together with the resolved account ID, the attacker triggers a password reset on the victim's account and takes it over. No public exploit code was identified at time of analysis, but the steps require only a known email and app instrumentation. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Sep 20, 2026
Account takeover is possible in the ZTE SmartLife (ZTESW) app on builds ZTE_SL_V2.8.2_ABROAD and earlier, where an attacker can reset the password of any registered user by spoofing the app's dynamically generated authentication parameters against the backend /account/verify.serv interface. After extracting the client-side auth parameters through a one-time reverse-engineering or instrumentation step, an attacker who knows a target's registered email address can resolve the real account ID and then submit a forged password-reset request, giving full control of the victim account without any victim interaction; the independent assessment rates this unauthenticated over the network (AV:N/AC:L/PR:N/UI:N) with high confidentiality, integrity and availability impact. No confirmed active exploitation (CISA KEV) and no publicly available exploit code were identified at time of analysis, but the weak-signal situation does not reduce the severity, and only ZTE_SL_V2.8.2_ABROAD and prior builds are affected.
Earlier versions of this analysis (1)
Password reset of arbitrary accounts in ZTE SmartLife (CPE zte:ztesw, all versions) is achievable because the backend treats application authentication parameters generated inside the mobile client's runtime process as trustworthy; a low-privileged authenticated attacker (CVSS PR:L) who instruments or hooks the app to harvest fresh parameters can call /account/verify.serv to resolve a known registered email address into the victim's real account ID, then spoof those parameters to force a password reset with no victim interaction. ZTE assesses the flaw at CVSS 8.5, and the scope-changing (S:C) classification reflects that the impacted security authority is the backend account service, so confidentiality and integrity losses extend across the user base rather than a single component. No public exploit code and no confirmed active exploitation were identified at time of analysis.
RemediationAI
Patch available per vendor advisory: ZTE has published a security bulletin for this issue at https://support.zte.com.cn/zte-iccp-isupport-webui/bulletin/detail/2171542593031840100, and operators, OEMs and end users of ZTE SmartLife should follow that bulletin to obtain the fixed build rather than any prior 2.8.2-based release; the provided data does not name an exact patched version string, so the patched build number must be confirmed against ZTE's advisory before upgrading. Because the exploitable component is the cloud service, client updates alone are not sufficient: ZTE (and any party operating a compatible backend) must harden /account/verify.serv and the password-reset flow server-side so that account IDs cannot be enumerated from an email address and password resets cannot be completed on the strength of client-supplied application authentication alone. Actionable compensating controls, with trade-offs, are to bind the app authentication parameters to device/platform attestation or a server-issued challenge so captured parameters cannot be replayed (this can break older clients and custom ROMs), to require an out-of-band confirmation such as an email or SMS one-time code or entry of the current password before a reset completes (adds user friction and depends on the email/SMS channel being uncompromised), to apply strict per-account and per-IP rate limiting and anomaly detection on /account/verify.serv and the reset endpoints (reduces automated abuse but does not stop a slow, targeted attacker), and to block or restrict direct API access to those endpoints from anything other than genuine application traffic via certificate pinning, mTLS or signed requests (raises the reverse-engineering bar, though a determined attacker with a rooted device may still extract keying material). Users of affected versions should change their SmartLife account password and enable any available multi-factor or login-notification feature while awaiting the fixed release.
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 root cause is a broken trust boundary classified as CWE-269 (Improper Privilege Management): the SmartLife client generates its application authentication parameters dynamically inside its own runtime process, and the ZTE cloud backend treats those client-derived values as authoritative proof of application identity. Because the security decision is made on material that lives in an attacker-controllable environment, an adversary can extract or instrument the running client, capture the generated parameters, and replay them outside the legitimate app. The first abuse is an information-disclosure primitive: a direct call to /account/verify.serv with the spoofed app authentication returns the real account ID bound to a supplied registered email address, which the attacker must already know. The second is a privilege/identity primitive: combining the spoofed application authentication with the discovered account ID lets the attacker drive the password-reset path for that account, effectively reassigning control of the identity. The affected product is tracked as CPE cpe:2.3:a:zte:ztesw:*:*:*:*:*:*:*:* and corresponds to the ZTE SmartLife application (ZTESW) builds up to and including ZTE_SL_V2.8.2_ABROAD; the flaw is published as EUVD-2026-83649 and detailed in ZTE's security bulletin.
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:H/I:H/A:H
App-level auth params are extractable by anyone running the client, so PR:N not PR:L; remote, no user interaction, and password reset yields full account confidentiality/integrity/availability loss.
Primary rating from Vendor (zte).
CVSS VectorVendor: zte
Lifecycle Timeline
2DescriptionCVE.org
SmartLife app dynamically generates fresh SmartLife application authentication parameters inside its runtime process. Using the acquired SmartLife application authentication parameters, an attacker can directly call the backend interface /account/verify.serv to obtain the real account ID corresponding to a registered email address. By spoofing the application authentication information together with the target account ID, the attacker can reset the password of the target account.
Executive ViewAI
ZTE SmartLife (ZTESW) app builds ZTE_SL_V2.8.2_ABROAD and earlier allow an attacker who knows only a victim's registered email address to take full control of that account through a forged password reset against the /account/verify.serv backend - no credentials and no victim interaction required. Because the flaw is unauthenticated, remotely reachable, and rated high for confidentiality, integrity, and availability impact, every user of the affected builds is a potential victim, along with any smart-home devices, stored credentials, and personal data reachable through those accounts. With no vendor patch available today, leadership should treat this as an open risk requiring interim containment rather than a routine update cycle item.
No vendor-released patch identified at time of analysis. Interim mitigations are server-side and user-side only: rate-limit and monitor the /account/verify.serv endpoint for anomalous reset traffic, require out-of-band one-time verification (email or SMS) before any password reset is honored, invalidate all sessions and tokens upon reset, restrict or block authentication from the affected app builds via version/device attestation, alert users to credential-reuse risk and unusual account activity, and hunt for post-takeover indicators such as new device pairings or profile changes.
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
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
Exploit-DB