Local File Inclusion (LFI) in the “Police Department” WordPress Theme (<= 2.17) — What Site Owners Must Do Now

Author: Hong Kong Security Expert

Published: 2026-03-01

TL;DR

A critical Local File Inclusion (LFI) vulnerability (CVE-2026-28049) affects the “Police Department” WordPress theme version 2.17 and earlier. Unauthenticated attackers can include and read local files on your web server, exposing wp-config.php, environment files, backups, logs, and other sensitive data. The issue is high severity (CVSS 8.1). If you run this theme and have not updated or mitigated, act immediately.

This post explains:

• How the vulnerability works at a high level
• Who and what is at risk
• How to detect exploitation attempts
• Immediate containment and manual mitigations
• Recovery and long-term prevention

What is a Local File Inclusion (LFI) vulnerability?

Local File Inclusion occurs when an application uses unvalidated user input to determine a filesystem path to include or display. In WordPress themes, that often means parameters that accept filenames or templates are used without proper sanitisation. Successful LFI lets an attacker read arbitrary files from the server, and in some chains it can lead to remote code execution.

Key facts for this vulnerability:

• Affects theme versions ≤ 2.17
• Type: Local File Inclusion (LFI)
• CVE: CVE-2026-28049
• CVSS: 8.1 (High)
• Privilege required: none (unauthenticated)

Why this LFI is especially dangerous for WordPress sites

WordPress stores critical secrets in files. The canonical example is wp-config.php, which contains database credentials and authentication keys. If an attacker reads that file they can:

• Access or modify the database (if remote DB access is allowed)
• Create administrative accounts
• Inject content or backdoors
• Exfiltrate user data, payment records, or PII

Even without direct exposure of wp-config.php, LFI can reveal logs, backups, or temporary files containing secrets. In many hosting setups, local read access is sufficient to escalate further.

How attackers find and exploit this vulnerability

Attackers and automated scanners look for parameters that appear to accept filenames, for example file=, template=, path=, page=, include=, tpl=. They then try directory traversal payloads such as ../ or URL-encoded variants like %2e%2e/.

Typical exploitation flow:

1. Discover a parameter that accepts filenames or templates.
2. Send payloads like ../../wp-config.php (URL-encoded if necessary).
3. If the response contains file contents, exfiltration succeeded.

Because the vulnerability is unauthenticated, mass scanning and rapid exploitation are likely after public disclosure. Treat exposure as urgent.

Indicators of compromise (IoC) — what to look for now

• Requests with %2e%2e or ../ in query parameters.
• Requests that include filenames such as wp-config.php, .env, config.php, backup.zip, dump.sql.
• Responses suddenly including raw PHP source, credentials, or long base64 blobs.
• Unexpected new admin users, changed content, or suspicious scheduled tasks.
• Spikes in 200 responses for a specific endpoint or repeated POST requests to the same URL.
• Webserver error logs showing PHP warnings about file includes triggered by user input.
• External IPs repeatedly requesting the same unusual URLs (scanning behavior).

If you find evidence of scanning or file reads, assume sensitive data may have been exposed and follow recovery steps immediately.

Immediate containment — actions to take right now (priority order)

If you use the vulnerable theme (<= 2.17) on any production site, perform these steps now:

1. Put the site into maintenance mode — prevents further automated exploitation and gives you time to investigate safely.
2. Replace or deactivate the vulnerable theme — switch to a trusted default theme (e.g., a Twenty* theme) or another secure theme you control. If you cannot switch immediately, remove or rename the theme directory on the server (for example, rename /wp-content/themes/police-department to /wp-content/themes/police-department.disabled) to prevent the vulnerable code from being served.
3. Block the vulnerable endpoints at the webserver or CDN layer — create rules to block requests that include suspicious parameters or patterns like ../ in query strings. See the “Temporary manual mitigations” section for sample rules.
4. Apply virtual patching via a WAF if available — a WAF can block exploit attempts while you investigate and test an official patch. Use rules that block directory traversal, sensitive filenames, and known LFI payloads.
5. Review access and rotate credentials if exposure is suspected — if logs show attempts to read wp-config.php or other secrets, rotate the database password immediately and update wp-config.php. Rotate authentication salts and any API keys stored on the site.
6. Create a forensic snapshot — save copies of webserver logs, access logs, error logs, and a filesystem snapshot (if possible) for later investigation.
7. Scan for web shells and other indicators — use malware scanners and manual inspection to find unexpected PHP files in uploads, theme, or plugin directories.

Do not delete evidence before investigators can review it — copy logs and files first.

Temporary manual mitigations (examples)

Test any rule in staging before deploying to production. These are blunt but effective mitigations to reduce immediate risk.

Apache (.htaccess) — deny requests containing directory traversal sequences

# Block requests with directory traversal attempts in query string
RewriteEngine On
RewriteCond %{QUERY_STRING} (%2e%2e|%2f|%5c) [NC]
RewriteRule .* - [F,L]

This blocks queries with common URL-encoded traversal patterns. It may affect legitimate requests that use encoded characters.

Nginx — drop requests containing ../ or encoded equivalents in the query

# Block basic directory traversal attempts
if ($request_uri ~* "(%2e%2e|%2f\.\.|../|%5c)") {
    return 444;
}

Note: return 444 closes the connection without a response and is effective at stopping scanners.

Restrict direct access to the theme files

If you prefer to block the theme directory entirely until you update:

Apache:

<Directory "/var/www/html/wp-content/themes/police-department">
    Require all denied
</Directory>

Nginx:

location ~* /wp-content/themes/police-department/ {
    deny all;
    return 403;
}

This prevents the webserver from serving files inside the theme directory and is safe if an alternative theme is active.

PHP settings (server-wide) to reduce risk

• Ensure allow_url_include = Off.
• Use open_basedir to restrict PHP file access to the site root and required directories.
• Disable dangerous functions if not needed, for example exec, shell_exec, system, proc_open.

These do not fix the theme bug but raise the cost for attackers.

Detection and response — deeper steps

1. Preserve logs and evidence — copy access logs, error logs, PHP-FPM logs, and webserver configuration files with timestamps preserved.
2. Identify the attack timeline — search logs for ../, %2e%2e, wp-config.php, .env, and other sensitive filenames. Note source IPs and User-Agents.
3. Search for web shells or newly added files — inspect recently modified PHP files in:
   • wp-content/uploads/
   • wp-content/themes/
   • wp-content/plugins/

   Common indicators: obfuscated code, long base64 strings, use of eval(), preg_replace with /e, or compressed payloads decoded at runtime.

4. Check WordPress users and authentication — audit wp_users and wp_usermeta for unexpected admin accounts or privilege changes.
5. Rotate secrets as needed — if wp-config.php exposure is suspected, change database credentials, update wp-config.php, and rotate authentication salts and any API keys stored on the server.
6. Reinstall clean copies — after containment, replace the theme with a clean copy from the official source once a safe version is available.
7. Engage forensic analysis for sensitive exposures — if customer data or financial records were leaked, involve incident response or a forensic specialist.
8. Notify hosting provider or authorities if required — some hosts can assist with network-level indicators and remediation.

Why a WAF and layered protection matter for LFI

A Web Application Firewall (WAF) helps by blocking malicious requests before vulnerable code is reached. Effective protections for LFI include:

• Blocking directory traversal sequences in query strings and parameter values
• Blocking access attempts to known sensitive filenames (e.g., wp-config.php, .env)
• Inspecting request bodies for suspicious payloads
• Rate-limiting and IP reputation checks to slow mass scanning
• Virtual patching — temporary rules to prevent exploitation until an official fix is deployed

Virtual patching is especially valuable when no immediate patch is available or when updates must be tested in staging before production rollout.

If you cannot patch immediately: prioritized actions

1. Apply WAF virtual patching to block exploit payloads and scanning attempts.
2. Disable or remove the vulnerable theme from production sites.
3. Block suspicious query strings and filenames at the CDN or webserver layer.
4. Tighten PHP settings (open_basedir, allow_url_include).
5. Audit logs frequently until a permanent fix is in place.
6. Rotate any secrets suspected to be exposed.

Hardening checklist — long-term prevention

• Keep WordPress core, themes, and plugins updated; use staging to test updates.
• Subscribe to vulnerability feeds and patch notifications for themes/plugins you use.
• Enforce least privilege on file permissions; avoid world-writable PHP files.
• Use open_basedir and keep allow_url_include disabled.
• Run regular automated malware scans and file integrity checks.
• Use secure secrets management; avoid storing credentials in public-accessible files when possible.
• Restrict admin dashboards by IP or require two-factor authentication for all admin accounts.
• Maintain a disaster recovery plan with encrypted offsite backups.
• Implement layered defenses: network controls, WAF, host-level hardening, and application security.

Recovery: after containment and cleanup

Before reopening your site to the public, ensure the following:

1. Confirm the vulnerable theme is removed or updated to a safe version.
2. Restore from a known-good backup if persistent compromise is detected.
3. Change database credentials and API keys if they may have been exposed.
4. Update WordPress salts (AUTH_KEY, SECURE_AUTH_KEY, etc.) in wp-config.php.
5. Reinstall plugins and themes from trusted sources; do not reintroduce modified files.
6. Re-run malware scans and verify file checksums.
7. Monitor logs for unusual activity for at least 30 days after remediation.
8. Document remediation steps for compliance and forensic records.

Detection playbook — queries and tools

Use these search patterns on logs and repositories to detect attempts:

• Search access logs for \.\./, %2e%2e, or %252e%252e (double-encoded).
• Search for requests containing wp-config.php, .env, config.php, dump.sql, backup.
• Inspect error logs for messages referencing include() or failing to open streams.
• Use malware scanners to identify new PHP files or suspicious strings (eval, base64_decode, etc.).
• Use version control diffs or file-modification timestamps to find recent changes.
• If you have a SIEM or log aggregation, create alerts for these patterns to catch exploitation early.

Frequently asked questions (FAQ)

Q: The theme page says no patch is available — what should I do?

A: Immediately remove or disable the vulnerable theme and apply WAF virtual patching where possible. Replace the theme with a secure alternative or keep layered protections in place until a vendor patch is released and verified.

Q: My site is on managed hosting — will the host protect me?

A: Hosting protections vary. Do not assume full protection — verify with your host and apply additional WAF and hardening controls if needed.

Q: Can I just rename the theme folder to stop the exploit?

A: Yes. Renaming the theme directory is an effective temporary measure because PHP code under that folder will no longer be served in the same predictable path. Ensure your site’s active theme is safe before renaming to avoid breaking the front-end.

Q: Should I restore from backups?

A: If you find active compromise (web shells, unexpected admin accounts), restoring from a known-good backup and then applying patches and hardening is typically safer than in-place remediation.

Final notes and immediate summary

If your WordPress site uses the “Police Department” theme (<= 2.17), treat this as urgent:

1. Immediately remove or disable the vulnerable theme, or apply WAF rules blocking LFI patterns.
2. Check logs for scanning or file-read indicators and preserve them.
3. Rotate credentials and keys if you see evidence of file reads.
4. Run a full malware and integrity scan of the site.
5. Monitor closely for weeks after remediation.

Speed and layered controls matter. Contain quickly to reduce the chance of data theft or site takeover. If you handle regulated or sensitive data and suspect compromise, engage a professional incident response or forensic team.

References and further reading

• OWASP: Local File Inclusion (LFI) overview
• CVE-2026-28049 advisory and tracking (see CVE record linked above)
• WordPress hardening guides and PHP/FPM configuration best practices

Note: This post provides technical guidance. For active compromises or regulated data exposures, engage incident response specialists.