Urgent: Local File Inclusion (LFI) in “Widget for Google Reviews” plugin (Business Reviews WP) — what site owners must do now

日期： 10 Feb 2026
漏洞： Authenticated (Subscriber+) Directory Traversal → Local File Inclusion
受影響版本： <= 1.0.15
修復於： 1.0.16
CVE： CVE-2025-7327
嚴重性： 高 (CVSS 8.8)

This notice summarises a high-severity Local File Inclusion (LFI) issue affecting the “Widget for Google Reviews” (Business Reviews WP) plugin. An authenticated user with Subscriber privileges (or higher) can trigger directory traversal that leads to inclusion or disclosure of arbitrary local files. In the worst case, exposed files such as wp-config.php may contain credentials and secrets allowing full site compromise.

Executive summary (what you must do now)

1. Update the plugin to version 1.0.16 immediately — this is the upstream fix.
2. If you cannot update right away, disable or remove the plugin until you can deploy the update.
3. Review registered users and revoke or suspend suspicious Subscriber accounts; rotate credentials if you suspect exposure.
4. Inspect logs and file system for signs of exploitation (see detection section below) and follow incident response steps if you find indicators of compromise.

What is this vulnerability (plain language)

This is a directory traversal combined with Local File Inclusion. A low-privilege authenticated user can supply input that is concatenated into a file path and included/read by plugin code without proper validation. By using traversal vectors (../ and encoded equivalents), an attacker can cause the plugin to return contents of arbitrary local files to the HTTP response.

Consequences include disclosure of configuration files (db credentials, salts), discovery of writable locations, and possible pivoting to remote code execution depending on server configuration and available PHP wrappers.

How directory traversal + LFI works (high-level, safe explanation)

LFI occurs when code builds a local file path from user input and then includes or reads it without whitelisting or strict validation. Directory traversal uses sequences like “../” to escape intended directories. A safe, high-level example of the problematic pattern:

• Plugin accepts a parameter (e.g., file or template) from an authenticated user.
• The parameter is concatenated into a path (for example: include(PLUGIN_DIR . ‘/templates/’ . $param);).
• Without whitelisting or sanitisation, traversal input can reference files outside the templates folder.

We do not provide exploit code here. This explanation is to help administrators understand the risk and respond.

Why this is especially dangerous

• Subscriber accounts are common on many sites (public registration, comment authors, contest entrants).
• Disclosed configuration files can reveal DB credentials and salts, enabling account takeover and persistence.
• LFI can be an initial step to locate or load webshells or to leverage wrappers (php://, data://) depending on host configuration.
• Server-side disclosure often leaves minimal admin-visible traces; forensic analysis is required.

Who should be worried right now

Any WordPress site running the Business Reviews WP plugin at version 1.0.15 or earlier should treat this as urgent. Also be concerned if your site allows user registration or you maintain multiple client sites where this plugin may be installed.

Immediate remediation steps (0–48 hours)

1. Update to plugin version 1.0.16. This is the definitive fix from the maintainer.
2. If update is not possible immediately, disable or remove the plugin until you can update.
3. Temporarily disable new user registration if your site supports it, and audit existing Subscriber accounts for recent or suspicious creations.
4. Rotate credentials and API keys if you have reason to believe they were exposed (database password, third‑party API keys). Note rotating salts and DB passwords requires planning.
5. Increase monitoring: inspect access logs and webserver error logs for suspicious requests; archive logs for forensic analysis.
6. If compromise is suspected, isolate the site (maintenance/offline mode or network isolation) while you investigate.

Detection: what to look for in logs and scans

Search access logs and request logs for:

• Requests to plugin-related endpoints containing “../” or percent-encoded equivalents (%2e%2e, %2f, %5c).
• Parameter names such as file, template, path, include with suspicious values.
• Responses that contain content from files that should not be publicly served (headers/content from wp-config.php, .env, etc.).
• Authenticated requests from Subscriber accounts hitting widget or AJAX endpoints repeatedly.
• Sudden increases in requests from the same account or IP.

On the filesystem and database, look for:

• Unexpected files (webshells), recently modified plugin/theme files.
• New administrator accounts or unexpected changes to wp_options and plugin settings.

Run a trusted malware scanner and file integrity checks on a clean workstation or staging environment. Preserve logs for any investigation.

Practical mitigations you can apply immediately (safe for production)

• Disable the affected plugin until the update is applied.
• Harden server configuration: deny HTTP access to wp-config.php and other configuration/backups via webserver rules.
• Prevent execution of PHP in upload directories (webserver-level deny for .php execution in /wp-content/uploads).
• Block obvious traversal indicators and wrapper schemes at the edge (../, %2e%2e, php://, data:, expect:) if you can do so safely via server or edge rules.
• Restrict admin-area access by IP where practical and enforce strong admin passwords and 2FA for privileged accounts.
• Disable new user registration or introduce verification checks if registration is required.

為什麼虛擬修補（WAF）在這裡很重要

Virtual patching—blocking exploit attempts at the HTTP layer—provides temporary containment while you schedule and test the plugin update. It is useful when you cannot update immediately or when an active exploit is observed. Virtual patching should be considered a mitigation, not a substitute for applying the fixed plugin release.

How managed security services or an edge WAF can help (vendor-neutral)

A managed security service or properly configured edge WAF can quickly deploy rules to detect traversal and LFI payloads, rate-limit abuse, and log attempted exploitation. Such services can reduce the attack window across many sites; however, you must still update the plugin and perform a full incident review if you see indicators of compromise.

Responsible disclosure and safe testing

• Do not test live production sites without explicit permission from the site owner.
• Do not publish exploit code or automated PoCs; these enable abuse.
• Test vulnerability checks and fixes in a staging environment before applying to production.

事件響應檢查清單（如果您懷疑已被攻擊）

1. Contain: disable the plugin or take the site offline; force password resets for administrative accounts.
2. Preserve: collect and securely store logs and create a snapshot of the environment for analysis.
3. Investigate: scan for unknown files, webshells, and modified code; check the database for new admin users or changed options.
4. Clean: remove backdoors and malicious files; restore from a verified clean backup if necessary.
5. Remediate: apply the plugin update (1.0.16), update other components, and harden file permissions and server rules.
6. Monitor: continue watching logs and edge alerts for follow-up activity and re‑scans for persistence indicators.
7. Learn: document the incident, root cause, and improvements to prevent recurrence.

Detection signatures and WAF rules (examples you can implement safely)

These are high-level rule ideas. Test in staging and tune to avoid false positives.

1. Block requests where parameters contain “../” or encoded equivalents such as “%2e%2e” combined with “/” or “\”.
2. Deny requests that reference specific sensitive filenames in parameters (wp-config.php, .env, config.php).
3. Block parameters containing PHP wrapper schemes: “php://”, “data:”, “expect:”.
4. Implement endpoint-specific whitelists where possible: accept only known template names rather than arbitrary filenames.
5. Rate-limit or block IPs/accounts that repeatedly target sensitive endpoints.
6. Log blocked attempts with IP, authenticated user ID (if present), user-agent, and matched rule for triage.

Hardening checklist (recommended long-term actions)

• 保持 WordPress 核心、主題和插件更新，並在測試環境中測試更新。.
• 移除未使用的插件和主題以減少攻擊面。.
• Enforce least privilege: restrict user registrations, remove inactive users, and minimise administrative accounts.
• 為所有特權帳戶啟用雙因素身份驗證。.
• Disable file editing in wp-admin: define(‘DISALLOW_FILE_EDIT’, true); in wp-config.php.
• Set secure file permissions (typically 644 for files, 755 for directories) and protect wp-config.php.
• Consider moving wp-config.php above webroot if hosting allows.
• Deny web access to backups and configuration files via webserver rules.
• Restrict PHP execution in upload and other writable directories.
• Maintain frequent, tested offsite backups and a documented recovery plan.

If you’re running many sites: automation and oversight

• Maintain an inventory of plugins and versions for each site to quickly identify affected installs.
• Automate updates where safe; use staging for bulk updates and compatibility testing.
• Deploy centralised rulesets or edge protections that can be applied rapidly across multiple sites.
• Schedule regular security reporting and audits for client or hosted sites.

Real-world scenarios and attacker behaviour

After successful file disclosure, common attacker steps include:

• Extracting DB credentials and accessing the database to create admin users.
• Uploading webshells or modifying plugin/theme files for persistent access.
• Exfiltrating user data or using credentials to pivot to other systems.
• Deploying ransomware, cryptominers, or other malware if the environment permits.

Early detection and containment reduce the likelihood of escalation. If sensitive files were disclosed, assume the attacker may attempt further actions and proceed with a full incident response.

Frequently asked questions (short answers)

Q: I’m a small site owner — how likely am I to be targeted?
A: If your site allows public registration or has Subscriber accounts, automated opportunistic scans make you a non-trivial target. Update promptly.

Q: My site is behind a firewall/CDN — am I protected?
A: It depends on whether that edge protection inspects and blocks traversal/LFI patterns. Ensure edge rules include detection for directory traversal and LFI indicators.

Q: Can I just block Subscriber accounts entirely?
A: Disabling registrations reduces the attack surface, but may not be practical for all sites. If you must allow Subscribers, add verification, restrict capabilities, and monitor closely.

Checklist: step-by-step for administrators (actionable)

1. Immediately update the “Widget for Google Reviews” plugin to version 1.0.16.
2. If update is not possible now, disable or remove the plugin.
3. Audit Subscriber accounts and remove or suspend suspicious ones.
4. Review access logs for traversal patterns and unexpected file disclosures.
5. Rotate credentials that may have been exposed (DB password, API keys).
6. Apply edge/server rules that block directory traversal, LFI patterns, and sensitive file references.
7. Run malware scans and file integrity checks; search for webshells.
8. Restore from a verified clean backup if evidence of compromise is found.
9. Harden the site (DISALLOW_FILE_EDIT, restrict PHP execution in uploads, secure wp-config.php).
10. Monitor for follow-up activity and document findings for post-incident review.

最後的想法

From a Hong Kong security expert perspective: act quickly and deliberately. The low privilege required for this vulnerability makes it attractive to automated attackers. Prioritise the upstream plugin update, audit user accounts, and perform targeted forensic checks if you see suspicious activity. Use layered defences—patching, configuration hardening, monitoring, and edge protections—to reduce risk. If you manage multiple sites, centralise inventory and response capabilities so you can act across all affected installations promptly.

— 香港安全專家