Summary
hosp_order is a rolling-release application from sfturing whose password recovery flow fails to authenticate account identity before a password change. An anonymous recovery request, reachable without credentials, looks up an account by a submitted email and writes the resulting account identifier into the session as userMSG. A separate password-modification handler then consumes that session attribute as the target identity without re-verifying a verification code, old password, or authenticated user. Lab testing on one build confirmed that an attacker knowing only a victim’s email can set that account’s password to a chosen value and log in — a full account takeover without credentials. The advisory attributes the issue to the rolling release including the tested commit and prior historical versions.
Vulnerability mechanism
Intended recovery boundary
Password recovery is expected to verify the requester’s identity before allowing any password change — typically by validating a verification code and/or confirming old credentials — so that the account being modified is bound to an authenticated recovery session rather than to an anonymous lookup result.
Controlled input and session seeding
CommonUserController‘s recovery endpoint accepts an email supplied by the requester. Because the endpoint is reachable anonymously, that email is attacker-controlled input. Per the report’s source-level description, the server uses the email to look up the matching account and writes the resulting account identifier into the session under the attribute userMSG. This occurs during the anonymous request phase with no identity proof required, so the session carries an account identifier chosen by whoever supplied the email.
Password modification without an authentication bridge
The password-modification handler calls CommonUserService.modifyPassWord, which reads the target identity from session.userMSG. Per the source-level description, it trusts this attribute as authoritative without re-verifying the verification code, the old password, or the current session user’s identity. No authentication bridge links the anonymous seeding phase to the privileged modification phase: the same session attribute set by an unauthenticated request is consumed as a trusted account reference.
Resulting effect
Because the modification handler acts on the session-bound identifier and accepts an attacker-supplied new password, an attacker who seeds userMSG with a victim’s account identifier can replace that account’s stored credential. Subsequent authentication with the new password succeeds, completing account takeover. The flaw is an improper authentication gap — the absence of a verified link between the recovery requester and the account being modified — not a cryptographic failure.
Prerequisites and attack logic
No administrator or setup privileges are required; the attack needs only the privileges of an anonymous network caller. The sole victim-specific information needed is the target’s email address, which seeds the session account identifier. No victim password, verification code, or old password is required, and no victim interaction is needed. The deployment must run an affected build with the recovery endpoint reachable anonymously. Conceptually, the anonymous recovery request binds the victim’s account identity to the attacker’s session, and the subsequent modification request consumes that binding to overwrite the password; the two unauthenticated requests together complete the takeover.
Core pseudocode
function recover(email): |
The decisive missing check is in modifyPassWord: it consumes session.userMSG as the target identity without verifying the verification code, old password, or an authenticated session user. The first function seeds that attribute during an anonymous recovery request; the second consumes it to overwrite the password — no authenticated bridge links the two phases.
Affected scope
Reported affected range: the rolling release, including commit 627f426331da8086ce8fff2017d65b1ddef384f8 and prior historical versions; this is a reported range, and only the single tested commit was runtime-verified — not all historical versions were individually checked. No fixed version is confirmed; the advisory does not identify a patched release. The mechanism rests on the report’s source-level description (recovery writes the email lookup into an anonymous session; modifyPassWord skips verification code, old-password, and identity checks), with no independent full source audit. Runtime-observed impact on the tested build: password modification succeeded and login with the new password confirmed account takeover. Conditional or inferred: if the target account holds administrative privileges, the effect extends to functions accessible to that account — inferred from the takeover, not specifically tested. Not verified: no specific business permissions were determined, and no code execution or host takeover was observed.
Remediation and detection
Treat the two phases as separate trust boundaries and require a verified bridge between them. Before any password modification, validate the verification code and/or re-verify the old password or the current authenticated session user; do not accept a session attribute set during an anonymous request as an authoritative account identifier. Bind account identity for security-sensitive operations to an authenticated session, not to a lookup result seeded by an unauthenticated email submission. These are mechanism-based recommendations, not vendor-verified guidance; the source provides no confirmed fix. For detection, password modifications occurring in sessions where no verification code was validated and no prior authentication exists are a lead worth correlating with recovery-endpoint activity. This is an investigative observation inferred from the mechanism, not proof of misuse; legitimate password changes by authenticated users are a plausible explanation, so correlation across requests is needed.