Conceptual ModSecurity rule (adapt for your ModSecurity version and environment):

SecRule ARGS|ARGS_NAMES|REQUEST_URI "@rx (?i)(\.\./|%2e%2e%2f|wp-config\.php|/etc/passwd)" \
  "id:100001,phase:1,deny,status:403,log,msg:'LFI/path traversal blocked'"

Important: avoid overly broad rules that block legitimate behaviour. Test in detection mode, review false positives, then enforce.

Code-level fixes and hardening for theme developers

The correct remediation is to remove any code that includes files based on raw user input. If inclusion is necessary, use a strict whitelist or canonicalisation checks.

1. Avoid direct inclusion of user input

   Do not use constructs like:

   <?php include( $dir . $_GET['file'] ); ?>

2. Whitelist approach (recommended)

   Only accept known view keys mapped to safe files:

   <?php
   $allowed_views = array(
     'gallery' => 'templates/gallery.php',
     'product' => 'templates/product.php',
     'home'    => 'templates/home.php'
   );
   
   $view_key = isset($_GET['view']) ? $_GET['view'] : 'home';
   if (isset($allowed_views[$view_key])) {
       include get_template_directory() . '/' . $allowed_views[$view_key];
   } else {
       wp_die('Invalid view', 'Error', array('response' => 404));
   }
   ?>

3. Canonicalise and check realpath if whitelist isn't possible

   <?php
   $requested = isset($_GET['partial']) ? $_GET['partial'] : '';
   $theme_dir = realpath(get_template_directory()) . DIRECTORY_SEPARATOR;
   $target = realpath($theme_dir . $requested);
   
   if ($target !== false && strpos($target, $theme_dir) === 0) {
       include $target;
   } else {
       wp_die('Invalid request', 'Error', array('response' => 400));
   }
   ?>

4. Sanitise inputs

   Uso basename() only in limited contexts and validate against strict patterns (alphanumeric and hyphen) where applicable.

5. Reduce filesystem privileges

   Theme files should not be writable by the webserver user unless absolutely necessary.

6. Code review and automated tests

   Add static analysis checks and code review gates to detect include/require usage that references user input.

Forensic checklist: suspect compromise — what to do

1. Take a forensic snapshot: preserve logs, site files and DB dump before making changes.
2. Quarantine affected sites: maintenance mode, block external access, isolate network egress.
3. Search for indicators: new admin users, unknown cron jobs, PHP files in uploads, base64 payloads.
4. Restaure desde copias de seguridad conocidas como buenas: validate integrity before restoring.
5. Rota las credenciales: DB user, API keys, hosting accounts.
6. Reinstall fresh copies: WordPress core, theme and plugins from trusted sources; verify checksums when possible.
7. Vuelva a escanear y monitoree: continuous monitoring after remediation.
8. Notificar a las partes interesadas: follow your incident response and breach-notification obligations.

Hardening beyond immediate mitigation (short- to mid-term)

• Keep WordPress core, themes and plugins updated; test in staging first.
• Maintain an inventory of components and automate vulnerability scanning.
• Apply principle of least privilege for DB users and file permissions.
• Disable PHP execution in wp-content/uploads with server rules.
• Enforce strong admin passwords and multi-factor authentication for admin accounts.
• Implement file integrity monitoring to catch unexpected changes.
• Use per-site WAF rules and monitor WAF logs; virtual patching can be a stop-gap only.
• Limit public exposure of admin endpoints (IP allowlists, VPN, or two-factor firewall gating).

Recovering from credential exposure (wp-config.php leaked)

1. Rotate DB credentials immediately: create a new DB user and update wp-config.php.
2. Rotate API keys and third-party service credentials (mail, cloud storage, payment gateways).
3. Review DB users and privileges; remove unknown or excessive permissions.
4. Reset WordPress salts (AUTH_KEY, SECURE_AUTH_KEY, etc.) in wp-config.php to invalidate existing sessions.
5. If user data may be exposed, follow local data breach notification rules and require password resets where appropriate.

Searching for webshells and suspicious code

Use these commands carefully; they can be noisy but effective.

grep -R --line-number -i -E "eval\(|base64_decode\(|exec\(|shell_exec\(|passthru\(|system\(" /var/www/html
find /var/www/html/wp-content/uploads -type f -name "*.php"
find /var/www/html/wp-content/themes -type f -mtime -30 -print

Quarantine suspicious files and preserve copies for investigation instead of deleting immediately.

Sample incident response commands (for administrators)

# List active theme and version
wp theme list --status=active
wp theme get splendour --field=version

# List admin users
wp user list --role=administrator

# Search logs for traversal patterns
grep -R --line-number -e "%2e%2e" -e "\.\./" /var/log/nginx/

# Find PHP files in uploads
find /var/www/html/wp-content/uploads -type f -name "*.php" -print

Execute these in a controlled environment. If you are unsure, engage a competent security professional or incident response specialist.

Orientación de comunicación para agencias y anfitriones

• Proactively notify affected customers, explain the risk and the immediate mitigations you will apply.
• If you manage updates, schedule emergency maintenance windows to apply WAF rules and theme changes where necessary.
• If compromise is suspected, advise rotation of credentials and provide clear next steps for investigation and recovery.

Preguntas frecuentes

Q: Is my site vulnerable if I don’t use a feature in the theme?

A: Possibly. Vulnerable code paths can be reachable even when a feature is not visibly used. Confirm by checking the theme version and code.

Q: Will removing the theme entirely protect my site?

A: Removing or replacing the vulnerable theme is effective. If theme files remain on disk they may still be a risk; removing the files is safer.

Q: What if I can’t take the site offline?

A: Apply virtual patching via a web application firewall, disallow PHP execution in uploads, rotate credentials and monitor logs closely. Plan a maintenance window for full remediation.

Recomendaciones finales — priorizadas

1. Enable WAF rules to block LFI/path traversal immediately (test then enforce).
2. Identify all sites running Splendour ≤ 1.23 and prioritise remediation.
3. Switch to a safe theme where feasible until a vendor patch is available.
4. Scan and monitor for indicators of compromise; rotate credentials if suspicious activity is detected.
5. When the vendor publishes a patch, test in staging and deploy promptly.

Closing thoughts (from a Hong Kong security expert)

In Hong Kong’s fast-moving hosting and ecommerce environment, exposure windows must be measured in hours, not days. This LFI in Splendour is a high-risk issue because it is unauthenticated and trivially automatable. Apply the mitigations above immediately, prioritise high-value and production sites, and preserve forensic data if you suspect compromise. If you need tailored WAF rules or platform-specific guidance (nginx + ModSecurity, Apache with ModSecurity, or cloud WAF), tell me which platform you run and I will provide targeted rule snippets and deployment notes.