- CVE Identifier: CVE-2023-54335
- Name: eXtplorer authentication bypass leading to arbitrary file upload and remote code execution
- CVSS Score: 9.8 (Critical)
- Severity: Critical
- What it Allows: An unauthenticated attacker can become “logged in,” upload malicious files, and execute code on the server.
What eXtplorer Is
eXtplorer is a web-based file manager written in PHP. It lets users browse directories, upload and download files, manipulate files and folders, and perform administrative tasks through a browser.
The application relies on a login page and a session to control who has access to what. Normally, attackers should not be able to do anything sensitive without valid credentials.
Vulnerability Overview
In certain versions of eXtplorer (up to and including 2.1.14), there is a flaw in how authentication is checked. This flaw allows an attacker to trick the application into thinking they are already logged in — even if they are not.
Once the attacker bypasses the login, they can open up the file upload feature that normally should only work for authenticated users. Because the upload section lets users send files to the server, the attacker can upload a malicious PHP script (commonly called a webshell).
After uploading the malicious file, the attacker can simply visit it in a browser. When the server executes that file, the attacker obtains remote code execution (RCE) — meaning they can run arbitrary commands on the server with the same privileges as the web server process.
This chain — authentication bypass → arbitrary upload → remote code execution — is what makes this vulnerability extremely dangerous. No credentials are needed. No complex cryptographic weakness is required. It can be done with simple HTTP requests.
How the Exploit Works
I won’t show exploit code, but here is the logical flow.
- Authentication Bypass
- The attacker sends a crafted HTTP request to the login endpoint.
- Because the login check is flawed, the server mistakenly treats the request as successful.
- The server sets or accepts a session that the attacker can use as if they were logged in.
- File Upload
- With this fake “authenticated” session, the attacker navigates to the upload page.
- They upload a file with PHP code inside — typically a simple webshell that executes commands.
- Execute Remote Code
- Once the malicious upload completes, the attacker accesses that file in a browser.
- The server parses and runs the PHP code, giving the attacker an interactive command interface or the ability to execute scripts.
- Persistence and Lateral Movement
- After RCE, the attacker can do anything the PHP process can do: drop shells, escalate privileges, pivot to other parts of the network.
This attack requires only that the application is reachable via HTTP/HTTPS and that the vulnerable version of eXtplorer is in use.
Why This Is Critical
- No credentials needed: Anyone with network access to the application can attempt this.
- Arbitrary file upload: The flaw doesn’t just expose information — it lets you put code onto the server.
- Web shells are powerful: Once code runs on the server, the attacker essentially owns it.
- Many installations are publicly accessible: eXtplorer is often used for sharing/browsing files, making it easy to find exposed targets.
Detecting Exploitation Attempts
Here’s how defenders can find if someone has tried or succeeded at exploiting this in their environment.
1. Web Access Logs (Apache / NGINX / IIS)
Look for unusual sequences of HTTP requests:
- Login attempts that don’t make sense
- Repeated POSTs to login pages with unusual parameters
- Login responses that return 200 OK even though no valid credentials were supplied
- Follow-up uploads right after a login attempt
- POSTs to upload endpoints without a corresponding legitimate user flow
- Uploads with multipart form data containing executable extensions
- Newly uploaded PHP files
- Requests for
.phpfiles immediately after successful uploads
- Requests for
Examples of things to search for:
POST /extplorer/index.php?action=login
POST /extplorer/index.php?action=upload
Then follow those by:
GET /uploads/<randomname>.php
2. Unexpected File Changes
Regular file integrity checks are your friend:
- Look for
.php,.phtml,.phar,.plin directories that normally only hold images or documents. - Compare recent file creation times against expected change windows.
Commands you might use internally:
find /var/www/html/extplorer -type f -mtime -3
This finds files modified in the last 3 days.
3. IDS / IPS Alerts
If you have a network IDS (Snort, Suricata) or WAF:
- Watch for upload attempts with file types that should be prohibited
- Look for authentication bypass patterns
- Correlate login attempts with upload attempts from the same IP
4. Session Behavior
A normal login should have:
- Valid credentials
- Session cookies set with known patterns
Abnormal sessions:
- Sessions that skip credential checks
- Sessions created without a POST to the login form
These are worth investigating.
What a PoC or Exploitation Attempt Looks Like
Again, I’m not providing code or payloads, but this is what you would see in traffic if someone is probing or exploiting:
- Series of crafted POSTs to the login page
- Attackers often try random or malformed parameter orders
- They check if the app responds with something that looks like a successful login page
- Followed immediately by file upload
- Uploads with multipart content
- Filenames that look like webshells (
cmd.php,shell.php,upload.php)
- Access to that uploaded file
- GET or HEAD requests to the uploaded file immediately after upload
- Often with user agents that look scripted (curl, python-requests)
- Command scripting
- Once a shell page exists, you might see query parameters like
?cmd=whoamior?cmd=uname -a
- Once a shell page exists, you might see query parameters like
Those are classic indicators of exploitation.
How to Defend and Respond
Before Patch
Until the patch is applied:
- Block access to eXtplorer entirely if possible
- Firewall rules to allow only trusted IPs
- VPN access only
- Disable file uploads
If possible, turn off the upload feature until you patch. - Limit file types
Restrict uploads to approved safe types (images only), and enforce server-side MIME type checking. - Run file integrity checks
Monitor for new files in web directories.
After Patch
- Upgrade to the fixed version immediately
- Restart web server and clear sessions
Remove all old sessions so attackers can’t reuse bypassed states.
How to Tell if You’ve Been Compromised
- Presence of unexpected
.phpfiles in upload directories - Unusual server processes started by the web user
- Web logs showing GETs to unusual PHP endpoints
- Evidence of command execution via web (e.g., strange process names)
If any of these are present, treat the server as compromised, isolate it, and conduct a full incident response.
Patch / Upgrade
You should upgrade your eXtplorer installation to the vendor’s fixed release. Get the updated package only from the official eXtplorer download page:
🔗 Official patch/upgrade link (vendor):
https://extplorer.net/projects/extplorer/files
