CVE-2026-54176: XSS
Summary
MyAccountController::postAccountInfoForm allows an authenticated user to update the authentication column (default: email) without verifying their current password. Because email is the account-recovery anchor, this enables account takeover after the attacker's session ends: the new email address can be used to request a password reset from outside the system.
The password-change endpoint in the same controller correctly requires oldpassword verification, so the gap is asymmetric.
Details
The postAccountInfoForm action passes $request->validated() directly to $user->update(). The AccountInfoRequest whitelists the authentication column (email by default) with no ownership challenge. Contrast this with ChangePasswordRequest, which uses Hash::check against the stored password before allowing any change.
Scenarios where this is exploitable include: - A brief unauthorized session (e.g. unattended workstation, XSS in the admin panel) - An insider/offboarding case where a departing admin sets a personal email address before access is revoked, then resets the password after leaving
Patch
Fixed in #5990 — the authentication column is now protected by a currentpassword check (mirroring ChangePasswordRequest) whenever its value changes.
A stronger mitigation — sending a verification link to the new address before persisting the change — can be layered on top using Laravel's MustVerifyEmail flow.
Affected versions
All versions prior to 6.8.14 / 7.0.38.
Fixed versions
- 6.x: 6.8.14 - 7.x: 7.0.38
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
composer/backpack/crudto a version that resolves this vulnerability.Fixed in 7.0.38 - Upgrade
Upgrade
composer/backpack/crudto a version that resolves this vulnerability.Fixed in 6.8.14 - Upgrade
Upgrade
Laravel-Backpack/CRUDto a version that resolves this vulnerability.Fixed in 6.8.14 - Upgrade
Upgrade
Laravel-Backpack/CRUDto a version that resolves this vulnerability.Fixed in 7.0.38 - Configuration
Apply the mitigation described: when the account-recovery anchor (default: `email`) is changed, send a verification link to the new address and require verification before the new address can be used for password recovery/account takeover (layer on top of Laravel's `MustVerifyEmail` flow if needed).
AccountInfo / account-recovery email update flow verification of changed email before allowing recovery/account takeover = require verification link to new address before change is usable
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
The attacker needs an authenticated session for the target account, but does not need to know the account's current password. A brief unauthorized session, such as access to an unattended workstation or an XSS-compromised admin session, can be sufficient.
How can this lead to account takeover after the attacker loses session access?
The attacker can change the account's authentication email address to one they control. They can then use that address as the account-recovery destination to request a password reset from outside the system.
Are default deployments affected?
Yes. The authentication column is email by default, and it is accepted by the account-information update flow without a current-password verification.
What should teams do if they cannot immediately apply the fix?
Restrict access to account-information updates or prevent changes to the authentication column until the fix can be deployed. Review account email changes, particularly for privileged or recently offboarded users, and investigate unexpected changes.
How can administrators identify possible prior exploitation?
Review records or audit logs for authentication-email changes that were not accompanied by a current-password verification. Pay particular attention to privileged accounts, offboarding events, and email addresses changed to personal or unfamiliar domains.