Description

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 Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-09-20T04:17:06.240Z",
  "pubdate": "2026-09-20T04:17:06.240Z",
  "executiveSummary": "The SmartLife application suffers from a critical authentication and authorization bypass vulnerability affecting the password reset mechanism.\nThe vulnerability originates from the insecure handling and dynamic generation of application authentication parameters within the runtime process.\nBy manipulating these runtime-generated tokens, an attacker can bypass identity verification protocols to interact directly with the backend interface /account/verify.serv.\nThis flaw enables unauthorized enumeration of account identifiers (UIDs) associated with specific email addresses, subsequently facilitating unauthorized password resets for arbitrary target accounts.\nThe impact is severe, allowing an attacker to perform full account takeover (ATO) without legitimate user interaction or prior knowledge of existing credentials.\nThis represents a significant failure in the application's authentication architecture and cryptographic signature validation processes, as the backend incorrectly trusts client-side generated authentication artifacts.",
  "technicalDetails": "The root cause of the vulnerability lies in the reliance on client-side dynamic generation of authentication parameters. The SmartLife application generates these parameters within the runtime environment rather than deriving them from a secure, server-side established session state or a cryptographically signed challenge-response mechanism.\nBecause the logic for generating these parameters is encapsulated within the mobile application's executable code, it is susceptible to reverse engineering and runtime manipulation.\nAn attacker can hook the relevant functions within the SmartLife runtime to intercept or forge these authentication parameters, effectively gaining the ability to craft valid requests that the backend perceives as legitimate and authorized.\nThe exploitation flow begins with the attacker extracting the logic used to generate the application authentication parameters. Using this logic, the attacker initiates a request to the /account/verify.serv backend endpoint.\nBy submitting a target email address alongside the forged authentication parameters, the attacker successfully queries the backend to resolve the victim's unique account ID.\nFollowing the retrieval of the account ID, the attacker proceeds to the password reset workflow. By spoofing the application authentication information in conjunction with the discovered account ID, the attacker bypasses the integrity checks that should prevent unauthorized requests to the account recovery infrastructure.\nThe /account/verify.serv interface fails to enforce adequate server-side validation of the authenticity of the client's request, trusting the parameters provided by the client rather than verifying them against a server-maintained session registry.\nConsequently, the attacker can submit a fraudulent password reset request, which the backend processes as a legitimate request from the owner of the target account. This results in the attacker being able to update the account password, fully compromising the user's account and gaining unauthorized access to all linked smart home devices and historical data."
}