Summary: A Local File Inclusion (LFI) vulnerability (CVE-2026-28120) was disclosed in the Dr.Patterson WordPress theme affecting versions up to and including 1.3.2. The vulnerability is unauthenticated, high-risk (CVSS ~8.1), and can expose local files (including wp-config.php), potentially leading to credential disclosure and full site compromise. This advisory explains the vulnerability at a technical level (without providing exploit code), the real-world risks, how to detect exploitation, immediate mitigations, long-term fixes, and recommended configuration and forensic steps for WordPress site owners and administrators.

What happened

A Local File Inclusion (LFI) vulnerability has been reported in the Dr.Patterson WordPress theme version 1.3.2 and earlier. The issue permits unauthenticated attackers to request local files on the server and have the contents included in a PHP context and returned to the attacker. In practical terms, attackers may be able to read files containing secrets — for example, the WordPress configuration file (wp-config.php), backup files, or other data that can be used to move from information disclosure to complete site takeover.

Why this matters:

• LFI vulnerabilities can expose database credentials and authentication keys.
• With disclosed credentials an attacker can access the database, create admin users, modify content, or move laterally on the server.
• LFI is often used as a precursor to remote code execution (RCE), especially when combined with upload functionality or when log files can be poisoned.

The vulnerability is tracked as CVE-2026-28120. It allows unauthenticated access and has been given a high priority severity rating due to the potential for immediate credential disclosure and rapid exploitation.

The risk in plain terms

An LFI vulnerability allows an attacker to instruct the web application to read files from the local filesystem and display them to the attacker. On WordPress, important files that should never be publicly accessible include:

• wp-config.php (database credentials, salts)
• .env (if used)
• backup archives (.sql, .zip)
• logs and tmp files
• plugin or theme configuration files that may contain API keys
• any files within uploads that have been mistakenly allowed to contain executable PHP

An attacker who obtains database credentials can:

• Access and dump the database,
• Create or modify administrator accounts,
• Inject malicious content,
• Steal user data, and
• In many hosting scenarios, pivot to other sites on the same server.

Because the vulnerability is unauthenticated, every site using the vulnerable theme needs attention immediately, regardless of user roles or activity.

How LFI is commonly exploited (high-level, non-actionable)

To keep this advisory safe for public distribution we do not provide proof-of-concept exploit code. However, it’s important to understand typical exploitation patterns so you can detect and block them:

• Attackers craft requests that include path traversal sequences (../) in parameters used by unsafe include() or require() calls.
• They attempt to include sensitive files (e.g., ../../../../../wp-config.php or /etc/passwd).
• They may try to poison logs (e.g., via user-agent or request parameters) to inject PHP that can later be included.
• They scan sites en-masse for the vulnerable theme and then probe the parameters commonly used by that theme.

If your logs contain multiple requests with path traversal, or repeated attempts to include filenames like wp-config.php or /etc/passwd, treat them as high-risk indicators.

Detecting signs of exploitation on your site

Start investigation immediately if you use Dr.Patterson <=1.3.2.

Check the following:

1. Web server access logs

• Look for requests containing ‘../’, ‘%2e%2e’, or encoded directory traversal sequences.
• Search for requests that include names of sensitive files: wp-config.php, .env, backup.zip, .sql.
• Example grep patterns (adjust paths/names for your environment):

grep -E "(\.\./|\%2e\%2e|wp-config\.php|/etc/passwd|\.env|backups?|dump\.sql)" /var/log/apache2/access.log*

2. Web server error logs

• Look for unusual PHP include errors, warnings about include/require failing, or file not found messages near suspicious requests.

3. File system artifacts

• Modified timestamps on wp-config.php, wp-content directory, or theme files that you didn’t change.
• Newly created PHP files under wp-content/uploads or tmp directories.

4. Database changes

• Unexpected users in the wp_users table.
• Modified options, site_url changes, unknown posts.

5. WordPress admin activity

• Logins from unknown IPs or new admin users.
• Plugins/themes installed or updated without your hand.

6. Backups and external endpoints

• Unexpected external outbound connections from your web server.
• DNS changes or new scheduled jobs (cron entries).

If you find suspicious activity, treat it as potential compromise: isolate the site, preserve logs, and proceed with secure incident response.

Immediate (triage) steps — what to do in the next hour

1. Put the site in maintenance mode or temporarily take it offline if possible.
2. Take a full backup (files + database) and make a copy offline for forensic analysis. Do not assume backups are clean.
3. Apply an emergency WAF mitigation (virtual patch). If you have a managed Web Application Firewall (WAF) or security service, enable emergency rules to block path traversal and inclusion patterns.
4. Audit and secure credentials:
   • Rotate database credentials.
   • Rotate WordPress salts (AUTH_KEY, SECURE_AUTH_KEY, etc.) in wp-config.php.
   • Reset admin passwords and notify site owners.
5. Scan for webshells and unauthorized PHP files:
   • Search wp-content/uploads and other writeable directories for PHP files.
   • Look for suspiciously named files (often one-line obfuscated PHP).
6. Examine logs for IOCs and preserve them.
7. If you suspect compromise, do not restore from a recent backup until you’ve confirmed it’s clean.

These are containment actions. They reduce blast radius while you plan investigation and recovery.

Recommended mitigations (short term until an official theme patch is available)

If the theme developer has not yet published a fixed release, take these steps to reduce risk:

1. Virtual patching (WAF rule)
   • Block requests containing path traversal patterns (../ or encoded equivalents).
   • Block requests attempting to access wp-config.php, .env, /etc/passwd, or other sensitive filenames.
   • Block or rate-limit unauthenticated requests to theme-specific endpoints that do not require public access.
2. Remove or disable the vulnerable theme
   • If you do not actively use Dr.Patterson, remove it from wp-content/themes and do not just leave it deactivated.
   • If you must keep it (e.g., for customizations), isolate it by using a staging environment and ensure it isn’t serving public requests.
3. Isolate file inclusion paths
   • Use open_basedir to restrict PHP include/require to known directories.
   • On shared hosts where you don’t control php.ini, ask your host to set strong open_basedir values.
4. Harden file permissions
   • Ensure wp-config.php is not world-readable: chmod 600 (where appropriate).
   • WordPress core files and theme files should be owned by the correct user and not writable by the webserver unless needed.
5. Disable PHP file execution in uploads
   • Add a webserver rule (nginx/apache) or place an .htaccess file to prevent PHP execution in wp-content/uploads.
6. Disable theme/plugin editors
   • In wp-config.php set define('DISALLOW_FILE_EDIT', true);
7. Review and tighten server-level rules
   • Block direct access to non-public files via webserver rules (deny access to .ini, .git, .env, .svn, etc.).

Virtual patching with a WAF should be considered mandatory if you cannot immediately remove or update the theme.

Indicators of Compromise (IoCs) and log queries

Search logs for these high-level indicators. Replace log paths and hostnames with your environment’s details.

• Directory traversal and sensitive file access patterns:

  grep -E "(%2e%2e|\.\./|wp-config\.php|/etc/passwd|\.env|dump\.sql|backup\.zip)" /var/log/nginx/access.log*

• Requests to theme-specific scripts with suspicious parameters:

  grep -i "drpatterson" /var/log/nginx/access.log* | grep -E "(\.\./|%2e%2e|wp-config|etc/passwd)"

• Suspicious user-agent or POST payloads:

  grep -iE "(curl|wget|python-requests|sqlmap|nikto|libwww-perl)" /var/log/apache2/access.log*

• File uploads where content-type is mismatched:

  find wp-content/uploads -type f -name "*.php" -print

• Newly created admin accounts in database:

  SELECT ID, user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 20;

If you find evidence of exploitation, collect and preserve logs and file system images before making changes that would destroy evidence.

Incident response checklist (recommended sequence)

1. Contain
   • Activate virtual patching (WAF)
   • Disable public access to site if possible
2. Preserve
   • Snapshot files and database
   • Export webserver logs
3. Investigate
   • Search for the IoCs described above
   • Check for new admin users and code changes
4. Eradicate
   • Remove malicious files and backdoors
   • Replace compromised files from known good backups or fresh WordPress core/theme/plugin packages
5. Recover
   • Rebuild the site if needed on a clean host or clean instance
   • Change all passwords and rotate keys
6. Post-incident
   • Conduct root cause analysis
   • Improve monitoring and WAF signatures
   • Schedule regular audits and threat scans

Engage a qualified incident responder for suspected compromise; small mistakes during cleanup can leave persistent backdoors.

Recommended server and WordPress hardening checklist

• Apply principle of least privilege: file system accounts, database accounts with minimal permissions.
• Use secure hosting with isolated containers or hardened shared hosts.
• Keep WordPress core, themes, and plugins updated. If a vendor does not publish fixes promptly, avoid that theme/plugin.
• Disable file editing: set DISALLOW_FILE_EDIT to true.
• Prevent PHP execution in uploads and cache directories.
• Use security headers: Content Security Policy (CSP), X-Content-Type-Options, X-Frame-Options.
• Limit admin login by IP where possible.
• Enforce strong authentication: 2FA for admin accounts.
• Backups: keep multiple offsite, versioned backups and test restores.
• Monitor logs and configure alerting for suspicious behavior (sudden 404 spikes, large POST requests, repeated traversal attempts).

Why you can’t rely only on updates and why virtual patching matters

Even though the correct long-term fix is an update from the theme developer, real-world experience shows updates can be delayed, incomplete, or may break custom sites. In the meantime:

• Attackers scan quickly for known vulnerable versions and exploit unpatched sites.
• Many WordPress sites run outdated themes or have customizations preventing straightforward upgrades.
• Virtual patching at the WAF layer buys time: it blocks exploitation attempts before they reach vulnerable code.

A combined approach — immediate virtual patching + planned, tested update — is the safest path.

What to do if your site is already compromised

1. Assume the worst: attacker may have access to database and filesystem.
2. Take the site offline and preserve forensic evidence.
3. Rotate secrets: database credentials, SSH keys, API tokens, WordPress salts.
4. Restore from a confirmed clean backup or rebuild from clean source files and known good content exports.
5. Scan and remove all backdoors and webshells. Backdoors are often placed in innocuous-looking theme or plugin files.
6. Audit other sites hosted on the same server and change shared credentials.
7. Notify stakeholders and follow any applicable breach notification laws.

Professional incident response support is strongly recommended. Cleanups can be complex; a partial cleanup often leaves a persistence mechanism.

Technical patterns to block in your WAF (examples)

Below are conceptual WAF signatures and patterns you should block or inspect. These are expressed clearly so you can implement them in your own ruleset or provide them to your hosting/security team. Test thoroughly to avoid false positives.

• Block any query parameter that contains “../” or the encoded “%2e%2e”.
• Block URIs or parameters that reference wp-config.php, .env, /etc/passwd, /proc/self/environ, and similar sensitive paths.
• Block suspicious attempts to include files with extensions .php,.inc,.tpl,.phtml when passed as parameter values to endpoints that should not accept file names.
• Rate-limit requests with repeated traversal attempts from the same IP within short timespans.
• Block user-agents known to be used by automated scanners if they are unnecessary for your site.

If you operate your own ModSecurity ruleset, translate these concepts into appropriate rules and test them in monitoring mode before blocking.

Communication guidance for site owners and administrators

• If you host client sites: notify affected clients immediately. Explain the vulnerability, risk, and steps being taken.
• If you run multiple WordPress sites on the same server: treat other sites as potentially at risk and audit them.
• Maintain readable incident logs and a list of actions taken — this helps both technical and non-technical stakeholders.
• Document a rollback plan before applying changes to production so you can recover if a mitigation causes site issues.

Timeline and expected actions from theme developers

• Immediately: theme author should assess and publish an advisory containing the vulnerability details, which parameters are affected, and guidance for administrators.
• Short-term: a patched theme release should be made available. Administrators should test the patch on staging environments before applying to production.
• Long-term: theme authors should adopt secure coding practices (validate inputs, avoid dynamic includes, whitelist include paths) and secure release management.

Until the vendor provides a verified patch, follow the mitigations listed above.

Frequently asked questions (FAQ)

Q: Can an LFI alone allow code execution?
A: Not usually by itself. LFI gives the attacker the ability to read local files, which can lead to credential disclosure. Combined with writable log files, file uploads, or misconfigurations, it can lead to RCE. Treat LFI as a stepping stone to more severe compromise.

Q: Is disabling the theme enough?
A: Deactivating the theme through WordPress can help, but leftover files in the theme directory may still be reachable. The safest approach is to remove the vulnerable theme directory from the server if it’s not in active use.

Q: Should I rebuild the site after an LFI exploitation?
A: If you confirm a compromise, rebuilding from clean sources and restoring content from a known-good backup is strongly recommended. Partial cleanups often miss persistence mechanisms.

Q: How quickly are attackers likely to find this vulnerability?
A: LFI vulnerabilities are frequently scanned for automatically. Once public disclosure appears, scans and exploitation attempts can ramp up within hours.

Closing notes — prioritize, but act carefully

This LFI vulnerability in Dr.Patterson <= 1.3.2 is serious: unauthenticated access to local files is a direct route to credential theft and site takeover. If your site uses this theme, do not wait for a long window. Implement containment (WAF rules), rotate credentials, scan for signs of compromise, and plan for a robust remediation including a verified theme update or theme removal.

If you have already found suspicious indicators, preserve evidence, isolate the site, and proceed with a full incident response. If you need help implementing virtual patching rules, scanning for webshells, or performing a forensic review, engage a qualified security professional.

Stay vigilant — timely containment and layered defenses are the most reliable way to prevent disclosure from becoming a full compromise.