GHSA-f25v-x6vr-962g

## Summary The forced password-change flow, triggered when the stored password is still the default (`admin`), does not verify that the password submitted by the client actually matches the current password. Any non-empty value in `pheditor_password` is enough to reach the password-change form, and submitting `pheditor_new_password` / `pheditor_confirm_password` in the same request is enough to set an arbitrary new password and obtain an authenticated session — without ever proving knowledge of the current password. ## Root Cause `pheditor.php` line 163: ```php if (PASSWORD == hash('sha512', 'admin')) { // still default — force change prompt ``` This checks whether the **stored** `PASSWORD` constant is still the default value. It does not check whether the **submitted** `pheditor_password` matches it. As a result, on any instance that hasn't changed the default password, the check passes regardless of what the client actually sends, and the subsequent password-change branch is reachable without authentication. ## PoC ```bash TARGET="https://victim.com/pheditor.php" # Any non-empty value works here — password is never actually verified curl -c /tmp/j.txt \ -d 'pheditor_password=anything' \ -d 'pheditor_new_password=attacker123' \ -d 'pheditor_confirm_password=attacker123' \ "$TARGET" -L -s -o /dev/null # Session is now authenticated as admin, with the password changed to attacker123 ``` ## Impact On any instance where the default password has not yet been changed, an unauthenticated attacker can set an arbitrary new admin password and obtain a fully authenticated session, without knowing the current password. This is a complete authentication bypass, not merely "default credentials in use" — it holds even if the operator believes the instance is protected because the login form is present. ## Remediation Verify the submitted password against the stored `PASSWORD` constant *before* entering the forced password-change branch, so the flow is reachab