Plugin Name	Welldone
Type of Vulnerability	Local File Inclusion
CVE Number	CVE-2026-28118
Urgency	High
CVE Publish Date	2026-02-28
Source URL	CVE-2026-28118

Urgent: Local File Inclusion in Welldone Theme (<= 2.4) — What WordPress Site Owners Must Do Right Now

A high-severity Local File Inclusion (LFI) vulnerability has been disclosed affecting the Welldone WordPress theme (versions <= 2.4). Tracked as CVE-2026-28118 and assigned a CVSS base score of 8.1, this weakness allows unauthenticated attackers to include local files on a vulnerable site and expose their contents to the attacker. Because information stored in local files (database credentials, API keys, configuration details) can lead to full compromise, immediate mitigation is required for any site running the affected theme.

I’m writing as part of the WP‑Firewall security team with practical, hands-on guidance: why this is dangerous, how it works at a technical level, how to detect attempted exploitation, and a prioritized checklist of immediate and medium-term actions you can take to protect your WordPress site. If you administer multiple sites or managed-hosting clients, share this post with your teams — the steps below are triaged for urgency and ease of implementation.

Summary of the disclosure

• Affected software: Welldone WordPress theme
• Vulnerable versions: <= 2.4
• Vulnerability type: Local File Inclusion (LFI)
• CVE: CVE-2026-28118
• CVSS: 8.1 (High)
• Privilege required: None (unauthenticated)
• Impact: Arbitrary local file read; possible disclosure of credentials and sensitive files; may lead to full takeover depending on server configuration
• Reported by: Tran Nguyen Bao Khanh (reported 19 Aug 2025; public disclosure 26 Feb 2026)

Why LFI is so dangerous for WordPress sites

Local File Inclusion occurs when an application builds a path to a local file using user-supplied input, without proper validation or sanitization, and then includes or reads that path. In PHP, functions like include(), require(), include_once(), and require_once() are common places where such bugs appear — particularly in themes and plugins that load template parts or external files based on URL parameters.

For WordPress sites the consequences are particularly severe:

• wp-config.php often includes database credentials and salts; reading it can give an attacker full database access.
• Other files may contain API keys, SMTP credentials, or proprietary data.
• If PHP wrappers (e.g., php://filter) or upload locations are accessible, an attacker can escalate from reading files to executing code (e.g., by locating and pulling a writable upload that will later be used to store a backdoor).
• Because the flaw is accessible without authentication, mass automated scanning and exploitation attempts are likely — and we expect opportunistic attackers to target exposed installations quickly.

How attackers typically exploit LFI (high level)

An attacker discovers a parameter that is used in a file include call (for example, something like include( $template_path . $_GET['page'] . '.php' ); ). If that parameter is not validated, the attacker can send requests that reference other local files via directory traversal (../../../../wp-config.php) or via PHP stream wrappers (php://filter, data://). Even when direct inclusion is blocked, many LFI chains can be turned into remote code execution (RCE) by first exposing files, logs, or including other accessible resources.

We will not share working exploit payloads here, but it is important for defenders to recognize the patterns and indicators described in the detection section below.

Indicators of attack and compromise — what to look for

Monitor your logs (web server access logs, PHP error logs, WordPress logs) for these signs:

1. Requests containing directory traversal patterns in query strings:
   • Unencoded or encoded "../" sequences (e.g., ..%2F, %2e%2e%2f)
   • Repeated traversal attempts like ../../../../
2. Requests referencing sensitive filenames:
   • wp-config.php, wp-config.php.bak, .env, /etc/passwd, .htpasswd, etc.
3. Requests using common LFI parameter names:
   • Query parameters named file, page, template, inc, path, module, or others
   • Sudden bursts of requests to theme endpoint(s) with varied traversal payloads
4. Use of PHP stream wrapper patterns:
   • php://filter, expect://, data:// appearing in query parameters
5. Abnormal log entries or new PHP/JS files under wp-content/uploads, wp-content/themes/<theme>/, or other writable directories:
   • Suspiciously named files
   • Recently modified templates or plugin files you did not change
6. Sudden unusual database queries, unexpected admin user creation, or changes to core theme/plugin files.

If you find any of the above, treat them as high priority and follow the incident steps below.

Immediate (hours) mitigation — triaged and practical actions

If you have one of the affected versions or are not sure, apply one or more of these immediate mitigations. They are ordered by speed and impact:

1. Temporarily disable the vulnerable theme:
   • Switch to a default theme (e.g., a clean, maintained standard theme). This is the fastest way to remove the attack surface if you can afford a short visual change.
   • If that is not possible, place the site into maintenance mode while you apply other mitigations.
2. Remove or quarantine the vulnerable theme from the filesystem:
   • If you have access to the server (SFTP/SSH), rename or remove the vulnerable theme directory from wp-content/themes/. This prevents the theme code from executing.
   • Important: Keep a copy (off-server) for analysis if you are investigating.
3. Block suspicious requests at the web server or web application firewall:
   • Block requests with directory traversal sequences and attempts to access core files:
   • Example (nginx, simplified): deny requests with encoded .. sequences or php://:

   if ($request_uri ~* "(%2e|%2f|\.\./|\.\.\\)") {
       return 403;
   }
   if ($request_uri ~* "php://|data://|expect://|file://") {
       return 403;
   }
   

   • Note: Use cautious testing before applying server-wide rules to avoid breaking legitimate URLs; test on a staging site when possible.
   • Example (Apache .htaccess) — deny direct access to wp-config and block query strings with suspicious patterns:

   <Files "wp-config.php">
     Order allow,deny
     Deny from all
   </Files>
   
   # Block attempts to access common sensitive files
   <IfModule mod_rewrite.c>
     RewriteEngine On
     # Block requests containing ../ or php:// or data:// (basic)
     RewriteCond %{QUERY_STRING} (\.\.|php://|data://) [NC,OR]
     RewriteCond %{REQUEST_URI} (\.\.|php://|data://) [NC]
     RewriteRule ^.* - [F,L]
   </IfModule>
   

4. Harden file permissions and ownership (quick checks):
   • Ensure wp-config.php is not world-readable. Recommended permissions:
     • wp-config.php → 400 or 440 depending on server setup
     • Directories → 755
     • Files → 644 (except sensitive configuration files which should be stricter)
   • Ensure files are owned by the correct user (the web server’s user should not own files if your host supports more secure separation).
5. Disable dangerous PHP wrappers and functions where possible:
   • In php.ini, ensure allow_url_fopen = Off and allow_url_include = Off. This reduces the risk of remote file inclusion or stream wrapper abuse.
   • Consider disabling risky functions (only if your application does not need them): exec, shell_exec, system, passthru, proc_open, popen. Example:

   disable_functions = exec,shell_exec,system,passthru,proc_open,popen
   

6. Block user-supplied parameters used for file loads:
   • If you identify specific theme endpoints that accept file or template parameters, add quick server-side blocking rules for requests including those parameter names until the theme is patched.
7. Activate a WAF/virtual patch
   • If you run a managed web application firewall (WAF) or a security plugin that can deploy virtual patches, enable or add rules that:
     • Detect directory traversal sequences
     • Detect php:// and data:// wrappers
     • Block requests attempting to access wp-config.php or other sensitive files
   • Virtual patching prevents exploitation even if the underlying code remains vulnerable, buying you time until an official patch is available.

Medium-term (days) remediation and verification

1. Replace or update the theme
   • Check for an official patch or a new theme version that addresses CVE-2026-28118. If an official patched release becomes available, test it thoroughly on staging and then update production.
   • If no official patch exists, consider replacing the theme with a maintained alternative or a custom-coded child of a maintained base theme.
2. Audit your filesystem for webshells and suspicious files
   • Scan wp-content/uploads, theme directories, and plugin directories for:
     • Files with executable PHP where there shouldn’t be
     • Files with recently changed timestamps you don’t recognize
     • Known indicators from your intrusion detection systems
3. Rotate credentials and secrets
   • Change all WordPress admin passwords, database passwords, API keys, and any other credentials that may be stored on the server or exposed.
   • If you restore from a backup, rotate credentials afterwards.
4. Review server and application logs
   • Look back at logs for the period before and after the disclosure date for suspicious activity indicating a successful exploit (for example, response codes that include sensitive file output, or repeated exploitation attempts).
   • Export relevant logs to a secure location for any needed forensic work.
5. Full site malware scan and integrity check
   • Run a full malware scan; many scanners will detect webshells, backdoors, and modified core files.
   • Use file integrity tools to compare your codebase to known-good sources.
6. Restore from clean backups if compromise is confirmed
   • If you find evidence of compromise that you cannot fully clean, restore from a backup taken before the earliest signs of compromise. Make sure you perform the other remediation steps (rigid permissions, credential rotation) after restoration.

Long-term prevention and hardening (weeks / ongoing)

1. Principle of least privilege
   • Ensure file and database users have only the permissions they need.
   • Avoid running web server processes as the same user that can modify files.
2. Isolate environments
   • Keep staging and production environments isolated.
   • Use different credentials for different environments.
3. Continuous monitoring and alerting
   • Centralize logs (access, error, PHP) and add alerts for:
     • Directory traversal attempts
     • Requests referencing wp-config.php and other sensitive files
     • Unusual spikes in 4xx/5xx responses
4. Regular vulnerability scanning
   • Perform automated scans and regular scheduled manual reviews of theme and plugin code.
   • Subscribe to vulnerability intelligence feeds and configure your patch-management procedures to be responsive.
5. Regular backups and tested restores
   • Maintain off-site, versioned backups and test restore procedures regularly.
6. Hardening WordPress itself
   • Keep WordPress core, plugins, and themes updated.
   • Remove unused plugins and themes.
   • Disable or protect theme and plugin editors.
   • Implement security headers and HTTPS everywhere.

Suggested WAF detection and prevention rules (conceptual)

Below are defensive patterns you can adapt into your WAF or server rule set. These are conceptual regex signatures and should be tested before deployment to avoid false positives.

• Block requests with directory traversal attempts (basic):
  • Regex: (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)
• Block php://, data://, expect:// wrappers:
  • Regex: (php://|data://|expect://|zip://|phar://)
• Block attempts to reference sensitive files in query strings:
  • Regex: (wp-config\.php|/etc/passwd|/proc/self/environ|\.env|\.htpasswd)
• Block long sequences of encoded characters indicating obfuscation:
  • Regex: (%[0-9A-Fa-f]{2}){6,}

Example pseudo-rule (WAF-agnostic):

• If a request query string matches any of:
  • (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c) OR
  • (php://|data://|expect://) OR
  • (wp-config\.php|/etc/passwd|\.env)

  → then block the request (HTTP 403) and log details for review.

Notes on false positives: Many CMSs and legitimate libraries may include tokens that resemble risky patterns. Carefully test any pattern, scope rules to likely endpoints (theme files, include endpoints), and gradually tighten coverage.

If your site has been compromised — incident response checklist

If you confirm a compromise, follow these steps immediately:

1. Take the site offline (maintenance mode) or isolate the host.
2. Take a complete snapshot of the site and logs for forensic analysis.
3. Change all passwords (admin users, database, FTP/SFTP, control panel).
4. Rotate all keys and tokens that may have been stored on the server.
5. Scan and remove malicious files and webshells. If you’re not confident in manual cleaning, restore from a clean backup.
6. Verify database integrity and remove unauthorized admin users or content injections.
7. Conduct a full audit to identify how the attacker gained access and what lateral movement they may have executed.
8. Rebuild the environment from known-good sources if necessary; do not rely on “just cleaning” if backdoors are complex.

How WP‑Firewall helps (what a managed WAF does for you)

From the perspective of a managed WordPress security service, we harden and protect sites by combining several layers:

• Virtual patching (WAF rules): When a vulnerability like this LFI appears, we can deploy targeted rules that detect and block exploitation patterns across your sites until a vendor patch is available.
• Managed firewall and request inspection: Real-time parsing of request parameters to block traversal sequences, PHP wrapper usage, and other exploit signatures.
• Malware scanning and automated cleanup: Continuous scans to find malicious files and automated removal for many known webshells and backdoors.
• OWASP Top 10 mitigation: Systemic protections designed to reduce risks from the most common threat classes (Injection, Broken Authentication, LFI/RFI, etc.).
• Monitoring, alerts, and reporting: We monitor traffic anomalies and issue timely alerts if we detect exploitation attempts or evidence of compromise.

We recommend a layered strategy: combine virtual patching and WAF protection with secure configuration, fast updates, and monitoring. Virtual patching gives immediate protection while you perform the careful testing required for official updates or theme replacements.

A short technical note for developers and sysadmins

This class of vulnerability almost always originates from unsafe concatenation of user input into filesystem paths. Your checklist for secure file includes:

• Never directly use user input to build filenames without whitelisting allowed values.
• Use safe mappings (e.g., map short, known keys to allowed filenames) rather than accepting full path input.
• Normalize and validate any path before passing to include/require.
• If user content determines template selection, restrict choices to a trusted set that exists in your codebase.

Example safer approach (pseudo-code):

<?php
$allowed_templates = ['home', 'archive', 'single'];
$template_name = $_GET['tpl'] ?? 'home';

if (!in_array($template_name, $allowed_templates, true)) {
    // Invalid template requested — handle safely
    $template_name = 'home';
}

include get_template_part( 'templates/' . $template_name . '.php' );

This pattern maps user input to a controlled list and prevents arbitrary file inclusion.

New resource for site owners: Start with immediate, free protection

Protect your site now with our Basic Free plan — managed firewall, WAF, malware scanning, and coverage for OWASP Top 10 risks. It’s designed to protect sites immediately while you plan any required upgrades or theme replacements.

Secure Your Site Right Now — Start with WP‑Firewall Basic (Free)

• What you get instantly:
  • Managed firewall and WAF with virtual patch capability
  • Unlimited bandwidth for security traffic
  • Malware scanning to find suspicious files and changes
  • Protections against OWASP Top 10 threats (including LFI patterns)
• Why it helps:
  • You get immediate blocking of known exploitation patterns for newly disclosed vulnerabilities
  • Virtual patching reduces the attack window while you test official updates or migrate
• Get started: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(We also offer paid tiers if you need automated malware removal, IP blocking controls, monthly reporting, or managed security services.)

Practical examples — quick rules you can paste and test (summary)

• Protect wp-config.php (place in .htaccess):

<files wp-config.php>
  order allow,deny
  deny from all
</files>

• Nginx rule to block attempt with php wrapper:

if ($query_string ~* "php://|data://|%2e%2e|(\.\./)") {
  return 403;
}

• PHP ini hardening:

allow_url_fopen = Off
allow_url_include = Off
disable_functions = exec,shell_exec,system,passthru,proc_open,popen

Important: test these rules on staging to ensure they don’t block legitimate traffic for your specific theme or plugin behavior.

Final recommendations — what to do in the next 24–72 hours

1. Inventory: Identify any sites running Welldone theme ≤ 2.4.
2. Apply at least one immediate mitigation:
   • Disable/rename the theme folder, or
   • Block exploit patterns at the server/WAF level, and
   • Lock down wp-config.php access.
3. Enable continuous scanning and monitoring.
4. If you can, sign up for a managed protection plan (free tier available) to get virtual patches applied immediately while you plan a permanent fix.
5. Communicate with stakeholders if you host customer sites — transparency and quick mitigation are important.

If you need technical assistance

If you run multiple WordPress installations or manage client sites and want help triaging or applying mitigations, our security operations team can help analyze logs, deploy virtual patches across your fleet, and assist with incident response and cleanup. We also provide step-by-step guidance for safe updates and replacements of vulnerable themes.

Conclusion

This Welldone LFI (CVE-2026-28118) is a serious, unauthenticated vulnerability that can expose local files and lead to credential disclosure and full compromise. The fastest path to safety is to remove or quarantine the vulnerable theme and deploy virtual patching rules at the perimeter while you plan a controlled update or replacement. Hardening the server (disabling risky wrappers, fixing permissions, restricting file access) and monitoring logs for the indicators above will reduce exposure dramatically.

If you want immediate protection without complex server changes, try our Basic protection free plan which provides managed firewall rules, WAF protections, and malware scanning to block exploitation patterns like those used in LFI attacks. Start securing your site now: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

— The WP‑Firewall Security Team

References and notes

• Vulnerability tracked as CVE-2026-28118 (Local File Inclusion in Welldone theme, reported Aug 19, 2025; published Feb 26, 2026).
• This advisory is intended to help defenders. We do not publish exploit code here. If you are an administrator who suspects a breach and you need direct assistance, escalate to your security responders or reach out to a trusted WordPress security provider.