Pheditor: Hardcoded Default Credentials with No Forced Change Policy

Vulnerability Description

Pheditor contains a hardcoded default credential vulnerability in its authentication layer. The SHA-512 hash of the password 'admin' is statically defined in pheditor.php:11 and is never invalidated or forced to change on first login. This is a credential-based authentication bypass combined with missing security initialization — the application fails to enforce a secure-by-default posture. The vulnerability impacts confidentiality, integrity, and availability: attackers gain direct access to file editing, file upload, and terminal features, enabling arbitrary code execution.

Proof-of-Concept Significance

The PoC is deterministic and universally reliable: any Pheditor instance using the default configuration is compromised. The hash c7ad44cbad762a5da0a452f9e854fdc1e0e7a52a38015f23f3eab1d80b931dd472634dfac71cd34ebc35d16ab7fb8a90c81f975113d6c7538dc69dd8de9077ec is verifiable via offline computation. No preconditions exist beyond network access to the Pheditor interface; the vulnerability requires zero user interaction, zero exploit complexity, and zero knowledge of application internals beyond knowing the password 'admin' is standard practice for uninitialized deployments.

Detection Guidance

Log Indicators:

• Successful authentication attempts using username 'admin' without prior failed attempts (anomalous)
• Access to /pheditor.php with session tokens immediately following application deployment
• File modification or RCE activity originating from the application process shortly after startup

Network Signatures:

• HTTP POST requests to the authentication endpoint with default credentials in the request body or form data
• Presence of pheditor.php in web server access logs combined with terminal or file-upload operations

Source Code Inspection:

• Scan deployed pheditor.php for the hardcoded hash at line 11; verify it matches the known default
• Check if password change operations modify the PHP source file directly (indicating unsalted storage)

Mitigation Steps

1. Immediate (Temporary): Block pheditor.php at the firewall or web application firewall (WAF) layer; restrict access by IP to trusted administrators only; disable the terminal and file upload features if the UI permits
2. Short-term (Patch): Upgrade to a patched Pheditor version when available; if unavailable, manually edit pheditor.php:11 to replace the hardcoded hash with a strong, unique password and restart the service
3. Long-term (Architecture): Require all deployments to generate a unique password hash during installation (forced initialization); implement password salting and modern hashing (bcrypt/Argon2); enforce mandatory password change on first login; implement multi-factor authentication; containerize Pheditor with read-only file systems where password changes are prohibited

Risk Assessment

Likelihood of exploitation in the wild is very high because: (1) default credentials are routinely exploited by both script-based scanners and opportunistic threat actors, (2) Pheditor is likely deployed in development/staging environments where security posture is often relaxed, (3) the vulnerability requires no skill or reconnaissance. Threat actors actively scan for web-accessible file editors and terminal access points for persistence and lateral movement. This vulnerability is trivial to exploit at scale via automated credential testing. Organizations should assume any unpatched Pheditor instance exposed to the internet or untrusted networks has been compromised.