CVE-2023-54335: One-Click Login Bypass in eXtplorer That Leads Straight to Full Server Takeover (Unauthenticated RCE)

  • 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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 .php files immediately after successful uploads

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, .pl in 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:

  1. 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
  2. Followed immediately by file upload
    • Uploads with multipart content
    • Filenames that look like webshells (cmd.php, shell.php, upload.php)
  3. 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)
  4. Command scripting
    • Once a shell page exists, you might see query parameters like ?cmd=whoami or ?cmd=uname -a

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 .php files 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


Aegiron

Backed by 11+ years in cybersecurity and incident response, we decode the latest threats shaping today’s digital battlefield. This blog cuts through the noise with clear insights on vulnerabilities, emerging exploits, and the cyber news defenders can’t afford to miss.