Pheditor: Unauthenticated Password Reset via Missing Current Password Verification

Vulnerability Description

This is a broken authentication/access control vulnerability (OWASP A01:2021) stemming from incomplete validation logic in the forced password-change handler. The application correctly detects when the stored password is still the SHA-512 hash of 'admin', triggering a mandatory password-change flow. However, the implementation fails to validate that the submitted current password actually matches the stored value before allowing the password reset. The root cause is a missing authentication check: the code only verifies the stored password state but never validates the client-submitted password against it. This creates a direct path from unauthenticated request to authenticated admin session.

PoC Significance

The provided PoC demonstrates unconditional reachability of the password-change endpoint on default installations. The test payload shows that any non-empty string in the current password field bypasses authentication, and submitting new password fields in the same request triggers an immediate session establishment. This is highly reliable across all affected instances because it exploits a logical flaw, not a race condition or timing issue. The precondition is minimal: the server must still have the default password configured—a common state in development, test, and hastily deployed instances. The PoC proves both unauthenticated access and privilege escalation to admin in a single request.

Detection Guidance

Web server/WAF logs: Monitor for POST requests to /pheditor.php containing both pheditor_password and pheditor_new_password parameters originating from non-local IPs. Successful exploitation will be followed by authenticated requests using the newly set password. Application-level indicators: Check for sudden password hash changes in the Pheditor configuration without corresponding legitimate admin login logs immediately prior. Behavioral detection: Anomalous password change events (multiple failed attempts, resets from unusual locations, followed by unauthorized configuration changes) should trigger alerts. Log signatures: Look for POST requests with pattern pheditor_password=.*&pheditor_new_password= in access logs, especially on instances where login frequency is otherwise low.

Mitigation Steps

Immediate patching: Apply the fix to validate that the submitted pheditor_password parameter matches the SHA-512 hash of the current stored password before accepting a password change. The corrected logic must compute hash('sha512', $_POST['pheditor_password']) and compare it against the stored PASSWORD constant. Forced password change on first login: Implement authentication before any password-change flow; require valid login credentials first, then prompt for password update. Audit and respond: On all instances with unchanged default credentials, immediately force a password reset, audit logs for unauthorized access, and revoke/rotate any exposed credentials. Configuration hardening: Pre-deployment, enforce non-default passwords via environment variables or setup wizards that block deployment with default credentials.

Risk Assessment

Likelihood of exploitation in the wild is very high because: (1) Pheditor is a web-based tool commonly used by developers and system administrators; (2) default passwords are frequently left unchanged in test/staging deployments that are then exposed or forgotten; (3) the exploit requires no special tools or knowledge—a single HTTP request suffices; (4) automated vulnerability scanners will quickly identify affected instances. Threat actors have strong incentive to exploit this, as it provides immediate admin-level access to edit PHP files, leading to remote code execution. The vulnerability is particularly dangerous in CI/CD environments, shared hosting, and educational deployments where security posture is often lax.