HotGo Let the Client Choose the SMS Login Verification Code
HotGo Let the Client Choose the SMS Login Verification Code An SMS verification code is useful only when the server controls its value and ties it to one login attempt. The GitHub Advisory Database describes CVE-2026-1
HotGo Let the Client Choose the SMS Login Verification Code
An SMS verification code is useful only when the server controls its value and ties it to one login attempt. The GitHub Advisory Database describes CVE-2026-120447 as a HotGo authentication bypass where the client can choose that code.
The affected versions are HotGo 2.8.4 through 2.15.1. The advisory rates the issue Critical with a CVSS score of 9.2.
The request flow
The advisory says an unauthenticated attacker can supply the Code field to /admin/sms/send. The server accepts the client's value instead of generating a secret. The attacker then submits that known value through /admin/site/mobileLogin.
If the attacker knows a user's mobile number, the two requests can complete a login as that user. The affected accounts can include administrators, so the result may be control over the HotGo administration surface and whatever systems it manages.
This is not a weakness in SMS transport. The message can be delivered normally while the verification value is predictable because the client selected it. The trust boundary is broken before the message leaves the server.
Conditions for exploitation
The attacker needs network access to the affected endpoints and a target mobile number. The advisory also says user interaction is not required. An organization may reduce risk by requiring a second factor or network-level authentication in front of the login flow, but those controls are not part of the vulnerable code.
Public administration portals and reseller portals are the obvious exposure points. Internal management portals remain relevant when an attacker has a foothold on a user workstation or a less-trusted network segment.
Account takeover evidence
Review authentication logs for SMS login attempts where the request began and completed within an unusually short interval. Compare the source IP, device fingerprint and mobile number with the account's normal history. Look for new administrator sessions, changed passwords, new API keys and audit log gaps.
The code-generation path may appear as a normal successful SMS login because the server receives the code it expected. Application logs that record only success or failure will not show that the client chose the value. Request-body logging, if enabled with appropriate privacy controls, may be necessary to distinguish the path.
Remediation
The upstream commit referenced by the advisory is cb57056c746650e6ff86dec1e97d404b63dcfd30. Administrators should determine which supported HotGo release contains that fix and upgrade to it. The advisory does not state a patched version, so a release tag alone is not enough evidence.
Until the upgrade, disable SMS login for privileged accounts, require a second authentication method and restrict the administration endpoints to trusted networks. Rotate sessions and credentials for accounts that may have been taken over. Review the ability of HotGo administrators to run commands or change connected services.
Test after the fix
Send a login request with a caller-supplied code and confirm that the server ignores it. Then verify that a server-generated code is bound to the intended mobile number, expires after the configured interval and cannot be reused. Test failures should not reveal whether the phone number exists.
The procedural checks matter because a patch may fix one endpoint while leaving another login flow with the same client-controlled field. Search the code and configuration for alternate mobile login routes before closing the incident.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.