Summary
Ghost versions before 6.62.0 contain an authorization bypass in the self-service password reset flow. A user with suspended staff credentials may reset a password, reactivate the account, and regain the privileges associated with the original staff account.
Affected context
The issue occurs in Ghost deployments where suspended staff accounts remain eligible for self-service password reset. It becomes risky when the reset workflow restores or permits authenticated access without preserving the account's suspended status and authorization state.
Exploit preconditions
- Attack surface: Self-service password reset functionality
- Required access: Existing credentials or account knowledge associated with a suspended staff account
- Trigger point: Password reset and subsequent account authentication
- Why exploitation is possible: The reset workflow does not consistently enforce the suspended account state before restoring access
Why this happens
The underlying bug is an authorization-state validation failure. The password reset process treats successful credential recovery as sufficient to restore account access, without separately enforcing whether the staff account is suspended.
This maps to CWE-862: Missing Authorization, because the application permits a state-changing operation or access restoration without checking the account's current authorization status.
Potential impact
- A suspended staff user could regain access to the Ghost administration area
- An attacker could restore the privileges associated with the affected staff account
- Unauthorized users may modify content, settings, or other administrative data
- The compromised account could be used for persistence or further attacks
General mitigation guidance
Mitigation generally focuses on enforcing account-state and authorization checks throughout password recovery and authentication workflows.
Common defensive patterns include:
- Denying password reset completion for suspended or disabled accounts unless an approved administrative process is used
- Rechecking account status after credential recovery and before issuing sessions or tokens
- Separating identity verification from authorization decisions
- Applying least privilege to staff roles and limiting administrative capabilities
- Recording and alerting on password resets involving suspended, disabled, or privileged accounts
- Reducing trust in user-controlled recovery factors through strong identity verification and policy enforcement
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review checks for password reset flows that omit disabled or suspended-state validation
- Tests confirming that suspended accounts cannot obtain authenticated sessions through recovery paths
- Review of authorization checks performed before session, token, or privilege restoration
- Monitoring for password resets followed by successful login or administrative activity from previously suspended accounts
- Policy enforcement requiring consistent account-status checks across login, recovery, and session issuance workflows
Automated security review tools may help identify missing authorization checks, but workflow-specific testing remains important.
