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:

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

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...