Summary
phpMyFAQ may allow an authenticated session to change an account email address without requiring the current password. If an attacker obtains a valid session and can satisfy the CSRF requirement, they may redirect password-reset messages to an address they control and take over accounts that do not require two-factor authentication.
phpMyFAQ may allow an authenticated session to change an account email address without requiring the current password. If an attacker obtains a valid session and can satisfy the CSRF requirement, they may redirect password-reset messages to an address they control and take over accounts that do not require two-factor authentication.
Affected context
The issue occurs in the phpMyFAQ user control panel and the api/user/data/update endpoint when changing an account email address. It becomes risky where email changes rely on session and CSRF validation alone, without an additional verification step such as the current password or strong reauthentication. The resulting exposure can be especially significant for privileged or non-2FA accounts.
The issue occurs in the phpMyFAQ user control panel and the api/user/data/update endpoint when changing an account email address. It becomes risky where email changes rely on session and CSRF validation alone, without an additional verification step such as the current password or strong reauthentication. The resulting exposure can be especially significant for privileged or non-2FA accounts.
Exploit preconditions
- Attack surface: User account-management functionality, including
UserController::updateDataandapi/user/data/update - Required access: A hijacked or otherwise valid authenticated session for the target account
- Trigger point: An email-address change followed by the password-reset workflow
- Additional condition: The attacker must be able to submit a valid CSRF-protected request
- Why exploitation is possible: The email-change operation does not require proof of the account's current password or equivalent reauthentication
- Attack surface: User account-management functionality, including
UserController::updateDataandapi/user/data/update - Required access: A hijacked or otherwise valid authenticated session for the target account
- Trigger point: An email-address change followed by the password-reset workflow
- Additional condition: The attacker must be able to submit a valid CSRF-protected request
- Why exploitation is possible: The email-change operation does not require proof of the account's current password or equivalent reauthentication
Why this happens
The underlying flaw is a missing reauthentication check for a security-sensitive account change. Session validity and CSRF protection help establish request context and intent, but they do not prove that the current user is still the legitimate account holder when a session has been stolen. This behavior maps to CWE-308: Use of Single-factor Authentication, because a critical function is permitted without requiring an additional authentication factor or renewed proof of identity.
The underlying flaw is a missing reauthentication check for a security-sensitive account change. Session validity and CSRF protection help establish request context and intent, but they do not prove that the current user is still the legitimate account holder when a session has been stolen. This behavior maps to CWE-308: Use of Single-factor Authentication, because a critical function is permitted without requiring an additional authentication factor or renewed proof of identity.
Potential impact
- An attacker may redirect password-reset messages to an email address they control.
- A non-2FA account could be taken over through the password-reset process.
- Administrative or superadmin accounts could be compromised if their sessions are hijacked.
- Attackers may alter account data and use compromised privileges to affect help-desk content or application administration.
- An attacker may redirect password-reset messages to an email address they control.
- A non-2FA account could be taken over through the password-reset process.
- Administrative or superadmin accounts could be compromised if their sessions are hijacked.
- Attackers may alter account data and use compromised privileges to affect help-desk content or application administration.
General mitigation guidance
Mitigation generally focuses on requiring renewed authentication for high-impact account changes and reducing reliance on session possession alone.
Common defensive patterns include:
- Require the current password or an equivalent strong reauthentication step before changing an email address.
- Apply step-up authentication consistently to privileged and security-sensitive account operations.
- Notify the previous and new email addresses about pending and completed changes.
- Use a confirmation workflow that delays activation until ownership of the new address is verified.
- Preserve effective CSRF protections while treating them as complementary to authentication, not a substitute for it.
- Apply least privilege and mandatory multi-factor authentication to administrative accounts.
Mitigation generally focuses on requiring renewed authentication for high-impact account changes and reducing reliance on session possession alone.
Common defensive patterns include:
- Require the current password or an equivalent strong reauthentication step before changing an email address.
- Apply step-up authentication consistently to privileged and security-sensitive account operations.
- Notify the previous and new email addresses about pending and completed changes.
- Use a confirmation workflow that delays activation until ownership of the new address is verified.
- Preserve effective CSRF protections while treating them as complementary to authentication, not a substitute for it.
- Apply least privilege and mandatory multi-factor authentication to administrative accounts.
How teams detect issues like this
Detection approaches can include:
- Static analysis and code review rules that identify sensitive account mutations gated only by session checks and CSRF validation.
- Review of email-change, password-reset, credential-update, and privilege-management flows for reauthentication requirements.
- Policy checks requiring step-up authentication for changes to recovery addresses or other account-recovery factors.
- Integration tests that verify an email change is rejected when the current password or required reauthentication proof is absent.
- Audit monitoring for rapid email changes followed by password resets, especially on privileged accounts.
Detection approaches can include:
- Static analysis and code review rules that identify sensitive account mutations gated only by session checks and CSRF validation.
- Review of email-change, password-reset, credential-update, and privilege-management flows for reauthentication requirements.
- Policy checks requiring step-up authentication for changes to recovery addresses or other account-recovery factors.
- Integration tests that verify an email change is rejected when the current password or required reauthentication proof is absent.
- Audit monitoring for rapid email changes followed by password resets, especially on privileged accounts.
