Urgent: Local File Inclusion (LFI) in R&F WordPress Theme (<= 1.5) — What Site Owners and Developers Must Do Now

Published 11 February 2026. Research credited to Tran Nguyen Bao Khanh (VCI – VNPT Cyber Immunity). This advisory is written by Hong Kong security practitioners to provide plain-language, practical steps for site owners, administrators and developers.

Quick summary (TL;DR)

• Vulnerability: Local File Inclusion (LFI).
• Affected software: R&F WordPress theme — versions ≤ 1.5.
• Authentication required: None (unauthenticated).
• Risk: High (CVSS 8.1) — attackers can read sensitive files (for example, wp-config.php), and may chain to remote code execution depending on server configuration and available wrappers or log poisoning.
• Published: 11 Feb 2026. Research credit: Tran Nguyen Bao Khanh (VCI – VNPT Cyber Immunity).
• Official fix: Not available at publication time — immediate mitigation required.

If your site runs the R&F theme and you cannot immediately remove or update it, take defensive action now.

What is a Local File Inclusion (LFI) vulnerability?

Local File Inclusion occurs when application code loads files from the local filesystem using user-supplied input without strict validation. When an attacker controls the path used in include/require or other read/output operations, they can cause the application to return arbitrary local file contents.

Why LFI is dangerous

• Exposure of secrets: database credentials, API keys, configuration files (e.g., wp-config.php).
• Access to files outside the webroot if server or PHP is misconfigured.
• Potential to escalate to Remote Code Execution (RCE) via log poisoning or PHP stream wrappers (for example, php://filter, php://input).
• Often easy to automate: scanning tools routinely check for traversal patterns once a vulnerable endpoint is known.

Why this R&F theme LFI is urgent

• Unauthenticated exploitation: no login required.
• High impact: reading wp-config.php frequently provides everything an attacker needs to take over a site.
• No vendor patch available at time of disclosure: unpatched sites are rapidly targeted.
• High CVSS score (8.1) reflecting severity and likely chaining opportunities.

How an attacker might exploit this (technical overview)

Below are typical LFI exploitation patterns to help detection and mitigation; the exact parameter for this R&F theme LFI was disclosed by the researcher.

1. Locate an endpoint that performs include/require or file read operations based on user input — theme controller files, AJAX endpoints, template loaders are common.
2. Submit path-traversal payloads such as ../../../../ (or URL-encoded forms like %2e%2e%2f) to escape the intended directory.
3. Attempt to read sensitive files: wp-config.php, .env, files under /etc/, logs and temporary uploads.
4. If PHP wrappers are permitted, combine traversal with wrappers to reveal source or execute code (configuration-dependent).
5. To escalate to RCE, attackers may try log poisoning: inject PHP into access logs or other writable files and then include that file.

Important: allow_url_include, enabled wrappers, or misconfigured permissions increase risk substantially. Even without immediate RCE, disclosure of database credentials often leads to full compromise.

Indicators of compromise (IoCs) and detection

If you suspect probing or compromise, review the following signals.

Network and webserver logs

• Requests containing ../ sequences or URL-encoded traversal (%2e%2e%2f, %2e%2e%5c) targeting theme or template loader files.
• Requests that include php://, data:, expect:, or zip://.
• Large or unusual GET requests referencing WP config files.
• Bursts of requests from single IPs or suspicious user-agents.

WordPress and filesystem indicators

• Injected PHP or unexpected content in log files.
• Unknown admin accounts or privilege escalations.
• Modified theme/plugin files or unknown files in wp-content/uploads, wp-includes, or theme directories.
• Suspicious PHP files in uploads or cache folders.
• Database anomalies (new users, altered options).

When investigating, preserve logs and take forensic copies before making destructive changes.

Immediate actions for site owners (incident response checklist)

If your site uses R&F theme ≤ 1.5, follow this prioritized checklist now:

1. Put the site into maintenance mode (if practical) to reduce the attack surface.
2. Take a complete backup (files and database) and store it offline. Preserve logs for investigation.
3. If possible, disable the R&F theme immediately:
   • Switch to a known safe default theme via wp-admin.
   • Or rename the R&F theme folder via SFTP/SSH to force WordPress to fall back to a default theme.
4. If you cannot replace the theme immediately:
   • Apply virtual patching via your hosting WAF or control panel to block common LFI patterns (see rule examples below).
   • Restrict access to theme PHP endpoints with webserver rules (deny external access except from trusted IPs where appropriate).
5. Rotate credentials that could be exposed:
   • Database username/password.
   • WordPress administrative accounts and other privileged accounts.
   • API keys and third-party service secrets stored in WordPress.
6. Update WordPress salts and keys in wp-config.php.
7. Scan the site thoroughly for backdoors and web shells (filesystem and code scan).
8. Audit admin and user accounts for unauthorised additions or privilege changes.
9. Review webserver logs to determine scope and timeline of potential exploitation.
10. If compromise is confirmed, restore from a clean pre-compromise backup and re-apply only trusted updates and security controls.
11. Notify stakeholders and comply with legal/regulatory reporting where required.

Coordinate with your hosting provider where necessary. If you lack forensic expertise, engage a qualified incident responder promptly.

Virtual patching / WAF rule examples (how to block exploitation attempts)

While waiting for an official patch, virtual patching using a WAF or hosting control panel rules is an effective short-term mitigation. Test rules in staging before applying to production to avoid breaking legitimate functionality.

Block path traversal attempts (simple regex):

(\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)

Block PHP wrapper usage (prevent php://, data:, expect:, zip://):

(?:php://|data:|expect:|zip://|php%3A%2F%2F)

Block suspicious include/file parameter values:

• If a theme uses parameters like file=, page=, or tpl=, block requests where values contain traversal or wrapper patterns.

Example pseudo-rule:

IF REQUEST URI contains '?file=' OR '?path=' OR '?template=' AND REQUEST VALUE MATCHES '(\.\./|php://|data:|%2e%2e)' THEN BLOCK

Rate-limit and throttle suspicious endpoints to disrupt automated scanning. Deploy rules in monitor-only mode first, review false positives, then enforce.

Securing the code — guidance for theme and plugin developers

Developers maintaining R&F or any component that performs file inclusion must fix the code to remove user control from include paths and strictly whitelist allowed templates.

1. Remove direct use of user input in include/require calls. Never do include($input) where $input is user-controlled.
2. Use a whitelist of allowed templates/files. Example mapping:

$allowed = ['home' => 'templates/home.php', 'about' => 'templates/about.php'];
$key = $_GET['page'] ?? 'home';
if (!array_key_exists($key, $allowed)) { show_404(); }
include $allowed[$key];

3. Validate and sanitize paths using realpath() and ensure resolved paths remain inside the intended directory:

$base = realpath(__DIR__ . '/templates') . DIRECTORY_SEPARATOR;
$path = realpath($base . $userFile);
if ($path === false || strpos($path, $base) !== 0) { die('Invalid file'); }
include $path;

4. Avoid enabling risky stream wrappers and keep allow_url_include = Off in php.ini where possible.
5. Minimize file privileges; treat uploads as untrusted and do not store them with executable permissions inside theme directories.
6. Use proper error handling and do not expose stack traces or filesystem paths to end users.
7. Add unit and integration tests targeting path traversal and LFI scenarios to prevent regressions.
8. If dynamic loading is necessary, accept only predefined identifiers (not file paths) and map them to safe files.

Hardening the WordPress environment (defense-in-depth)

Apply these controls across the hosting environment to reduce impact and likelihood of LFI exploitation:

• Keep WordPress core, themes and plugins updated. Remove unused themes/plugins by deleting their code, not merely deactivating.
• Restrict file permissions (for example, wp-config.php at 600 or 640 depending on host; directories 755; files 644 as a baseline).
• Disable PHP execution in upload directories — use webserver rules (.htaccess or Nginx) to prevent *.php execution in /wp-content/uploads.
• Protect wp-config.php with webserver access rules.
• Enforce principle of least privilege for database and file access.
• Disable file editing from the WordPress admin: define DISALLOW_FILE_EDIT in wp-config.php.
• Retain centralized logs (webserver and application) for at least 90 days to aid forensics.
• Use strong passwords and multi-factor authentication for admin accounts.
• Maintain regular, verified backups kept offline or off-server.
• Monitor file integrity and alert on unexpected changes.
• Limit management interfaces to trusted IPs and use network segmentation where possible.

If your site has been compromised — cleanup and recovery

1. Isolate the site: disable public access or enable maintenance mode.
2. Preserve evidence: take copies of the current filesystem and logs for analysis.
3. Identify the attack vector and scope of compromise.
4. Restore from a clean backup made before the compromise.
5. Replace all credentials and secrets (database, API keys, WordPress salts).
6. Reinstall WordPress core, themes and plugins from trusted sources; do not reuse possibly infected copies.
7. Harden the environment as described above.
8. Monitor closely for reappearance; attackers often re-establish persistence.
9. Inform affected parties and meet legal/regulatory obligations where required.

If you do not have in-house incident response capability, engage a reputable incident response specialist immediately. Speed matters — attackers frequently revisit unremediated sites.

Practical checklist (one-page summary)

For site owners / administrators:

• Identify all WordPress sites using the R&F theme (<= 1.5).
• Place affected sites into maintenance mode if necessary.
• Switch to a safe theme or rename the vulnerable theme directory.
• Apply virtual patch/WAF rules to block LFI patterns.
• Take a full backup and preserve logs.
• Rotate DB and admin credentials; change WordPress salts.
• Scan filesystem for web shells and unauthorized changes.
• If compromised, restore from a clean backup and harden the environment.
• Monitor logs for repeated LFI probe attempts; consider IP blocking or rate limiting.

For developers and theme authors:

• Locate include/require calls that use external input.
• Implement whitelist and realpath validation checks.
• Test endpoints for traversal and path sanitization.
• Release a patch and notify users of versions needing update.
• Add automated tests to prevent regression.

Final words — why acting now matters

LFI vulnerabilities are attractive targets because they can be automated and scaled. With unauthenticated access, the critical window for exploitation is immediate once the vulnerability is known — attackers scan widely and quickly.

If your organisation operates sites using the R&F theme, do not delay: apply mitigations now — virtual patching via a WAF, disable or remove the vulnerable theme, rotate secrets, and perform a careful integrity check. If you require assistance implementing technical controls (WAF rule tuning, incident response, forensic analysis, or hardening), engage qualified security professionals without delay.