Urgent: Local File Inclusion (LFI) in Miller WordPress Theme (<= 1.3.3) — What site owners must do now

Summary: A critical Local File Inclusion (LFI) vulnerability (CVE-2026-28053) has been disclosed affecting the Miller WordPress theme up to and including version 1.3.3. The issue allows unauthenticated attackers to include local files from a vulnerable site and render their contents. This can result in credential exposure, full database compromise, or remote code execution depending on the environment. CVSS 3.1 base score: 8.1 (High). If you run the Miller theme (or manage sites that do), treat this as an immediate priority.

This advisory is prepared by Hong Kong-based WordPress security experts. It explains what the vulnerability is, why it is dangerous, how to detect exploitation, and the practical steps you must take now. The guidance is direct and action-oriented — no vendor promotions, only technical advice.

Table of contents

• What is Local File Inclusion (LFI)?
• What we know about CVE-2026-28053 in the Miller theme
• Why this vulnerability matters for WordPress sites
• Indicators of compromise (IoCs) you should look for
• Immediate mitigation steps (next 60–120 minutes)
• Recommended hardening and configuration changes
• Detecting and responding to a compromise
• Example WAF / server rules you can deploy
• Long-term recommendations and post-incident checklist
• Appendix: Useful commands, sample logs, and checklist

What is Local File Inclusion (LFI)?

Local File Inclusion (LFI) is a vulnerability where an application includes files from the local filesystem based on user-controlled input. An attacker can manipulate URL parameters or form inputs so the application reads and returns files such as:

• wp-config.php (database credentials and salts)
• .htaccess
• PHP source files (exposing code and secrets)
• System files like /etc/passwd

While LFI does not always directly produce remote code execution (RCE), it commonly enables further escalation: reading wp-config.php to obtain DB credentials, including log files that contain injected PHP, or exploiting writable upload directories to achieve RCE. In WordPress contexts, unauthenticated LFI in theme code is especially dangerous because the theme runs in public request space and is frequently targeted by automated scanners.

What we know about CVE-2026-28053 (Miller theme ≤ 1.3.3)

• Vulnerability type: Local File Inclusion (LFI)
• Affected versions: Miller theme ≤ 1.3.3
• CVE: CVE-2026-28053
• Authentication: None required (unauthenticated)
• CVSS base score: 8.1 (High)
• OWASP classification: Injection
• Exploitability: Remote, by supplying crafted requests that manipulate an include path in the theme

At the time of writing there may be no official patch from the theme author. Confirm the vendor page for updates; until an official patch is released, sites remain at risk and must rely on mitigations and hardening.

Why this is dangerous for WordPress site owners

There are three primary impacts of LFI in a theme:

1. Credential exposure — wp-config.php often contains database credentials and keys. Disclosure permits database access and administrative takeover.
2. Remote code execution or site control — combining LFI with writable directories or log poisoning can lead to RCE, allowing backdoors, defacements, or malware hosting.
3. Privilege escalation and pivoting — with DB credentials or shell access an attacker can create admin users, exfiltrate data, or use the hosting environment for further attacks.

Because the vulnerability is unauthenticated and affects theme code, automated exploits and mass scanning are likely. Treat containment and mitigation as urgent.

Indicators of compromise (what to look for right now)

• HTTP access logs with requests containing directory traversal sequences (../ or ..\) or parameters like ?file=, ?template=, ?inc=, etc.
• Suspicious requests referencing /wp-content/themes/miller/ or encoded traversal such as %2e%2e%2f or %252e%252e%252f.
• Requests containing /etc/passwd, wp-config.php, or php://filter/ in arguments.
• Unexpected file creation or modification in wp-content/uploads, theme directories, or other writable paths.
• New administrator users, unusual cronjobs, or unexpected outgoing network connections.
• Alerts from file-integrity monitoring or unexpected checksum changes in theme files.

If you observe these signs, move to incident response immediately (see below).

Immediate mitigation steps — what to do in the next 60–120 minutes

1. Disable or remove the Miller theme if present
   Switch to a default, known-good theme (for example Twenty Twenty-Three) temporarily. If switching is not possible on a high-traffic production site, prioritize web-layer blocking (see below).
2. Block exploit vectors at the web layer
   Deploy WAF or server rules to block requests with path traversal, php:// patterns, and references to wp-config.php or /etc/passwd.
3. Restrict direct access to sensitive files
   Ensure wp-config.php is not publicly readable. Apply restrictive file permissions (e.g., 400/440 where possible). Add webserver rules (.htaccess or nginx) to deny direct access to PHP files in theme subfolders not intended for public execution.
4. Harden PHP
   Verify allow_url_include is disabled, implement open_basedir to restrict reachable paths, and consider disabling dangerous functions (exec, shell_exec, system, passthru, proc_open, popen) if feasible for your environment.
5. Rotate credentials
   If logs indicate wp-config.php or other secrets were read, rotate database credentials, API keys, and WordPress salts. Force password reset for administrator accounts.
6. Isolate the host if compromise is confirmed
   Put the site into maintenance mode, restrict access by IP, or take the host offline while investigating.
7. Deploy a temporary virtual patch
   If you control a reverse proxy or WAF, add rules that block the exploit patterns. Virtual patching reduces immediate risk while you wait for an official theme update.

Recommended hardening and configuration changes (longer-term)

• Keep WordPress core, themes, and plugins updated. Maintain an inventory so you can quickly identify affected sites.
• Remove unused themes and plugins. Inactive code can still be discovered and abused.
• Set conservative file permissions: directories 755 (or 750), files 644, and wp-config.php 440 or 400 if permitted by your hosting user model.
• Use open_basedir to restrict PHP to only the necessary directories for your site.
• Implement file integrity monitoring to detect unauthorized changes and alert on modifications.
• Disable PHP execution in uploads and other non-code directories. Example Apache/Nginx rules are below.
• Adopt least-privilege for the database user — only grant permissions required for normal operation.
• Maintain secure, versioned backups stored off-server and test restores regularly.

Detecting exploitation attempts — practical queries and checks

1. Search HTTP logs for traversal patterns:

   grep -i -E "(\.\./|\%2e\%2e|\%2e\%2e%2f|php://filter|wp-config.php|/etc/passwd)" /var/log/apache2/access.log

2. Check error logs for include/open stream errors:

   grep -i "failed to open stream" /var/log/apache2/error.log

3. Find recently modified files in content directories:

   find /var/www/html/wp-content -type f -mtime -7

4. Look for recently created admin users in the database:

   SELECT ID, user_login, user_email, user_registered FROM wp_users WHERE user_registered >= NOW() - INTERVAL 7 DAY;

5. Compare theme file checksums with a fresh copy from the vendor to detect tampering.

Incident response procedure (if you suspect compromise)

1. Contain — Block attack traffic at the firewall/WAF and put the site into maintenance mode or restrict access by IP.
2. Preserve evidence — Snapshot disks, collect logs, and make forensic copies before making destructive changes.
3. Eradicate — Remove backdoors, restore WordPress core/theme/plugins from clean sources, and replace compromised credentials (DB, WP admin, SSH, FTP). Rotate API keys.
4. Restore and validate — Restore from a known-clean backup, validate file integrity, and re-scan for malware.
5. Communicate — Notify stakeholders and users according to your policies or legal requirements if personal data may have been exposed.
6. Post-incident analysis — Document root cause and update patching/monitoring processes to reduce recurrence.

If you are not comfortable performing incident response yourself, engage an experienced security professional with WordPress forensics capability.

Example WAF / server rules to block common LFI attempts

Below are example patterns and rules you can adapt for mod_security, Nginx, or other WAFs. Test in a non-blocking/logging mode first to avoid false positives.

Generic patterns to detect traversal and include attempts

• Block requests containing: ../ or ..\ (raw or encoded), %2e%2e%2f, php://filter, wp-config.php, /etc/passwd.
• Watch for query parameters like: file=, include=, inc=, template=, page=, path=.

Conceptual mod_security rule:

SecRule REQUEST_URI|ARGS|ARGS_NAMES "@rx (\.\./|\%2e\%2e|\%252e\%252e|php://filter|wp-config\.php|/etc/passwd)" \
 "id:100001,phase:2,deny,status:403,log,msg:'Potential LFI attempt blocked'"

Example Nginx snippets:

# block suspicious traversal sequences
if ($request_uri ~* "\.\./|\%2e\%2e|\%252e%252e") {
    return 403;
}

# block php://filter usages in query string
if ($arg_file ~* "php://filter|wp-config\.php|/etc/passwd") {
    return 403;
}

Targeted rule: deny access to vulnerable include endpoints

If a particular theme file is known to expose an include parameter (e.g., inc.php?file=), restrict access to that endpoint or deny it completely if not required.

<Files "inc.php">
  Require all denied
</Files>

Or restrict by IP for administrative access only:

<Files "inc.php">
  Require ip 203.0.113.0/24
  Require all denied
</Files>

Example safe PHP patterns theme developers should implement

Theme developers must not trust user input in include() calls. Use a whitelist approach and map tokens to fixed paths. Validate and canonicalize inputs and never accept full filesystem paths from users.

<?php
$allowed = [
  'profile' => __DIR__ . '/templates/profile.php',
  'contact' => __DIR__ . '/templates/contact.php',
];

$token = $_GET['tpl'] ?? '';
if (isset($allowed[$token])) {
  include $allowed[$token];
} else {
  include __DIR__ . '/templates/default.php';
}
?>

How to prioritize mitigation across a site fleet

1. Inventory sites and identify those with Miller installed (active or inactive).
2. Prioritize high-traffic and public-facing sites for immediate action.
3. Apply WAF rules network-wide to block known exploit strings while you patch or remove the theme.
4. For non-critical sites, consider removing the theme or disabling PHP execution in theme directories until patched.
5. After remediation, monitor activity for at least 30 days for delayed post-exploitation indicators.

Long-term security posture improvements

Effective WordPress security is layered:

• Patch management: keep core, themes, and plugins updated and maintain an inventory.
• Application shielding: use WAFs, reverse proxies, and harden PHP settings.
• Least privilege: limit DB and file permissions.
• Monitoring & logging: file integrity monitoring, retained logs, and alerts.
• Backups & recovery: versioned backups off-host and tested restores.
• Secure development: theme developers should whitelist include targets and validate inputs.

Practical checklist — Step-by-step for site owners

1. Identify if the site has the Miller theme installed (active or inactive).
2. If Miller is active: switch to a safe theme if possible; otherwise deploy WAF/server rules to block LFI patterns.
3. Add server rules to block path traversal and php:// style requests.
4. Set file permissions: wp-config.php 400/440, other files 644, directories 755.
5. Disable PHP execution in uploads and non-code directories.
6. Ensure allow_url_include = Off and implement open_basedir restrictions.
7. Scan files for changes and run an in-depth malware scan.
8. Check logs for LFI attempts and suspicious admin activity.
9. If compromise is suspected: preserve logs, take the site offline, rotate credentials, restore from a clean backup, and perform a post-incident review.
10. Consider engaging experienced incident response or managed security services for virtual patching and forensic support if needed.

Appendix: Useful commands and example searches

• Find recently modified files inside the Miller theme:

  find /var/www/html/wp-content/themes/miller -type f -mtime -7 -ls

• Search web logs for traversal sequences:

  grep -iE "(\.\./|\%2e\%2e|php://filter|wp-config\.php|/etc/passwd)" /var/log/nginx/access.log

• List WordPress users added in the last 7 days (MySQL):

  SELECT ID, user_login, user_email, user_registered FROM wp_users WHERE user_registered >= NOW() - INTERVAL 7 DAY;

• Check PHP config for dangerous settings:

  php -i | grep -E "allow_url_include|open_basedir|disable_functions"

Final notes from a Hong Kong security expert

This LFI in the Miller theme illustrates how a single unsafe include pattern can expose the entire site. Key actions:

• Treat unauthenticated file inclusion as high priority.
• Use virtual patching (WAF/server rules) and host-level controls immediately rather than waiting for a vendor patch.
• Rotate credentials and perform a careful investigation if you suspect wp-config.php or other secrets were exposed.
• Adopt layered defenses: WAF, host hardening, secure coding, monitoring, and reliable backups.

Act quickly and methodically. If you need external assistance, engage an experienced WordPress incident response team or security consultant with forensic capability.