{"uuid": "c1b9dde8-38a6-4a5e-a1bf-c82b0974c894", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-86553", "type": "published-proof-of-concept", "source": "https://t.me/hacking_Attack/195304", "content": "I found this while tracing the ZTE SmartLife Android app into its cloud account API. The attack path was fairly short once I had reproduced the app authentication used by the official client. The account verification endpoint accepted an email and, for registered accounts, returned the backend account ID. The password reset endpoint then accepted that account ID and a new password without requiring the reset code. I tested the chain on accounts I created for the research: verify email -> get accountId -> reset password -> old password rejected -> new password accepted The final login returned a valid SmartLife session. ZTE patched the findings and assigned four CVEs. CVE-2026-86553 covers the password reset issue and was scored CVSS 8.8 High. I also mapped what sits behind that authenticated account session in the SmartLife/Homecare SDK, including home, device, sharing, camera and other cloud routes. Those routes were mapped through static analysis and are clearly separated from what I directly exercised during the account takeover testing. Full write-up with the PoC flow, Android analysis, Frida validation and disclosure timeline:    submitted by    /u/TheReedemer69  (https://www.reddit.com/user/TheReedemer69) \n [link] (https://minanagehsalalma.github.io/zte-smartlife-app-pwned)   [comments] (https://www.reddit.com/r/Pentesting/comments/1wmihwo/i_found_a_password_reset_that_could_take_over_any/)", "creation_timestamp": "2026-09-23T00:00:09.632238Z"}