CVE-2026-48030: Authenticated Command Injection in Pheditor
TL;DR - Pheditor 2.0.1 through 2.0.3 contains an authenticated OS command injection bug in the terminal handler. - Any authenticated user may achieve RCE via the
dirPOST parameter; upgrade to 2.0.4. - No confirmed in-the-wild exploitation is cited here, but a public PoC appears available.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-48030 |
| CVSS | 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) |
| Attack vector | Network |
| Privileges required | Low, authenticated user |
| Patch available | Yes, fixed in 2.0.4 |
This is a critical OS command injection vulnerability in Pheditor, a lightweight PHP-based file editor and manager. The issue resides in the application’s terminal action handler and allows an authenticated user to supply attacker-controlled shell metacharacters through the dir POST parameter. That input can then alter command execution and bypass the application’s intended TERMINAL_COMMANDS restrictions.
For defenders, the practical significance is straightforward: this is not merely a constrained feature bypass. It is an authenticated remote code execution path with web-server-level command execution. In multi-user deployments, shared admin panels, internal tooling, or environments where lower-trust accounts exist, this should be treated as a priority patch because exploitation requires only valid authentication, not administrator privileges.
What Is This Vulnerability?
CVE-2026-48030 is a command injection flaw, mapped to CWE-78, caused by improper neutralization of special characters in an OS command. According to the vulnerability description, the application incorporates the dir POST parameter into terminal-related shell execution logic without adequately escaping shell metacharacters. As a result, an attacker can craft a malicious dir value that changes the meaning of the underlying command.
The important technical point is that the application’s TERMINAL_COMMANDS whitelist does not provide effective protection against this bug. The weakness is not simply that dangerous commands are allowed; it is that the attacker can manipulate command construction itself through a separate parameter. That means an allowlist of intended terminal commands can be bypassed if the shell invocation includes unsafe, user-controlled data before or alongside the whitelisted command.
In practice, successful exploitation can let the attacker run arbitrary operating system commands as the web server user. Depending on how Pheditor is deployed, that may allow reading application secrets, modifying hosted content, dropping PHP webshells, deleting files, pivoting into adjacent applications on the same host, or abusing locally accessible services. If the web server account has broad filesystem permissions, impact can extend well beyond the Pheditor directory.
Technical Notes
A commonly cited remediation pattern for this issue is replacing unsafe shell interpolation with proper argument escaping, such as:
// vulnerable pattern
$cmd = "cd $dir && some_terminal_command";
// safer pattern
$cmd = "cd " . escapeshellarg($dir) . " && some_terminal_command";
That does not by itself validate business logic, but it does address the core command-injection primitive described for this CVE.
Who Is Affected?
The affected product is Pheditor. Based on the CVE and associated advisory references, the vulnerable range is Pheditor 2.0.1 through 2.0.3, and the issue is fixed in 2.0.4. If you are running version 2.0.1, 2.0.2, or 2.0.3, you should assume exposure if the terminal functionality is present and reachable by authenticated users.
The fixed version explicitly cited for remediation is Pheditor 2.0.4. If your deployment is older than 2.0.1, the research note provided here does not establish whether those versions are affected. Do not guess based on code similarity alone. If version data is incomplete in your asset inventory, defenders should assume any unverified Pheditor instance requires immediate validation and should prioritize locating exact package or release versions before deciding risk is low.
This issue is especially important for environments where Pheditor is exposed to more than one user account, including internal admin tools, development servers, shared hosting management contexts, labs, and SMB web administration environments. Because the requirement is authentication rather than administrator-level authorization, a compromised low-privilege account may be enough to trigger exploitation.
CVSS Score Breakdown
The reported CVSS v3.1 score is 9.9, with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. That score reflects a vulnerability that is remotely reachable over the network, requires low attack complexity, and does not depend on user interaction. In operational terms, an authenticated attacker can execute the attack directly without persuading a victim to click, open, or approve anything.
The PR:L component matters here. Some teams incorrectly downgrade authenticated bugs because “login is required.” In this case, low privileges are enough, so any valid account, including a less-trusted or compromised user account, may be sufficient. That keeps exploitability high in real deployments, particularly if internet-facing or accessible to many internal users.
The S:C scope change indicates the impact crosses a security boundary. That is consistent with a web application bug leading to command execution on the underlying host. The C:H/I:H/A:H ratings also fit the likely consequences: attackers may read sensitive data, alter or destroy files, and disrupt service availability through arbitrary command execution.
From a prioritization standpoint, the 9.9 score should be taken seriously, but defenders should still anchor decisions in exposure and role. A Pheditor instance used only by one highly trusted administrator on an isolated management network presents less practical risk than a public or shared deployment. Even so, the patch urgency remains high because the exploit path is conceptually simple and impact is severe.
Exploitation Status
At the time reflected by the research note, there is no CISA KEV listing for CVE-2026-48030. That means there is no CISA-confirmed exploited-in-the-wild designation attached to this CVE in the Known Exploited Vulnerabilities catalog based on the provided data. Defenders should not misread that as evidence of safety; it only means there is no cited KEV confirmation here.
A public PoC or research repository appears to exist, specifically a GitHub repository surfaced as muslimbek-0x/CVE-2026-48030. The provided notes indicate that the repository documents affected versions, the fixed version, and exploitation logic involving the vulnerable dir parameter. That materially raises operational risk because even when broad in-the-wild activity is unconfirmed, public exploit guidance lowers the barrier to opportunistic abuse.
So the current status, based strictly on the supplied sources, is: public PoC appears available; active exploitation in the wild is not confirmed here; KEV status is negative at this time. In the absence of stronger telemetry, defenders should assume exploit development is feasible and patch accordingly rather than waiting for exploitation reports.
How to Detect It
Detection should focus on three areas: suspicious POST requests to the terminal handler, process execution or shell activity originating from the web server account, and unauthorized file changes consistent with webshell deployment. Because the vulnerable input is the dir POST parameter, requests that include shell metacharacters in that field are high-value indicators.
Useful hunting pivots include characters and constructs such as ;, &&, ||, backticks, $(, redirection operators, or encoded forms of those payload elements inside POST bodies. You should also correlate suspicious requests with subsequent child processes from php-fpm, apache2, httpd, or similar web service parents. On Linux hosts, a web server spawning /bin/sh, /bin/bash, nc, curl, wget, or unexpected file utilities deserves immediate investigation.
If Pheditor logs are limited or absent, reverse proxy logs, WAF logs, EDR telemetry, Sysmon for Linux equivalents, and auditd process execution records become more important. Also check for new .php files in writable web directories, especially those with terse names, random names, or recently modified timestamps tied to suspicious sessions.
Technical Notes
Example web log grep for suspicious dir parameter content:
grep -RinE 'dir=.*(%3B|%26%26|%7C%7C|%60|%24%28|;|&&|
||`|
$
()' /var/log/nginx /var/log/apache2 2>/dev/null
Example process hunting with audit or EDR-style logic:
ps -ef | egrep 'php-fpm|apache2|httpd'
Example Sigma-like detection idea for suspicious shell spawned by web server:
title: Web Server Spawning Shell After Pheditor Activity
logsource:
product: linux
category: process_creation
detection:
selection_parent:
ParentImage|contains:
- "php-fpm"
- "apache2"
- "httpd"
selection_child:
Image|endswith:
- "/sh"
- "/bash"
- "/dash"
- "/wget"
- "/curl"
condition: selection_parent and selection_child
level: high
Example HTTP hunting pattern if you capture request bodies:
POST .*dir=.*(;|&&|
||`|
$
()
Because exact endpoint naming is not established in the provided research, defenders should key on Pheditor terminal-related requests and the dir parameter rather than relying on a specific URI path.
Mitigation and Patching
The primary remediation is to upgrade Pheditor to version 2.0.4, which is the fixed release cited in the available references. If you are on 2.0.1, 2.0.2, or 2.0.3, treat the upgrade as urgent. After upgrading, validate that the deployed files actually match the 2.0.4 release and that no local customizations reintroduced unsafe shell invocation patterns.
If immediate patching is not possible, reduce exposure by disabling or restricting terminal functionality, limiting access to trusted administrators only, and placing the application behind network controls so it is not broadly reachable. Since exploitation is authenticated, account hygiene matters: review all valid users, rotate passwords where compromise is possible, enforce MFA if supported externally, and remove unused accounts. Temporary compensating controls should be treated as risk reduction, not a substitute for the vendor fix.
You should also assume that a vulnerable and exposed instance may already have been abused if it was accessible to untrusted users. That means patching should be paired with forensic checks: inspect web roots for webshells, review recent file modifications, analyze process histories if available, and rotate any secrets accessible to the web server process.
Technical Notes
If Pheditor was deployed from a GitHub release archive, a generic upgrade workflow may look like this:
# example only: verify paths and backup first
cd /var/www
cp -a pheditor pheditor.bak-2026-07-27
curl -LO https://github.com/pheditor/pheditor/archive/refs/tags/2.0.4.zip
unzip 2.0.4.zip
rsync -av --delete pheditor-2.0.4/ pheditor/
If you maintain it as a git checkout:
cd /var/www/pheditor
git fetch --tags
git checkout 2.0.4
If you must apply a temporary code-level workaround while scheduling the upgrade, review terminal command construction and ensure the directory argument is safely escaped:
$dir_safe = escapeshellarg($dir);
$cmd = "cd " . $dir_safe . " && " . $allowed_command;
Additional hardening steps:
# restrict write access in the web root where practical
find /var/www/pheditor -type f -name '*.php' -exec ls -l {}
;
# review recently changed files
find /var/www -type f -mtime -7 | sort
Because packaging and deployment methods vary, the exact upgrade command may differ in your environment. If version provenance is unclear, verify the installed code against the upstream 2.0.4 release before declaring remediation complete.
References
Primary reference for the CVE details is the NVD entry for CVE-2026-48030, which describes the flaw as an authenticated OS command injection in Pheditor’s terminal action handler affecting versions 2.0.1 to before 2.0.4. The same source also confirms that the issue is patched in 2.0.4.
For additional information on security practices and vulnerabilities, you can refer to: - What is an Indicator of Compromise? - Multi-Factor Authentication (MFA)
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.