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. Information in local files (database credentials, API keys, configuration details) can lead to full compromise — immediate action is required for any site using the affected theme.

This advisory is written with a practical, Hong Kong security practitioner tone: concise, prioritised, and focused on rapid containment followed by verification and recovery. Share this with your operations or hosting teams and prioritise the “Immediate mitigation” steps if you administer multiple sites.

Summary of the disclosure

• Affected software: Welldone WordPress theme
• Vulnerable versions: ≤ 2.4
• Tipo de vulnerabilidad: Inclusión de Archivos Locales (LFI)
• CVE: CVE-2026-28118
• CVSS: 8.1 (Alto)
• Privilegios requeridos: Ninguno (no autenticado)
• 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)

Por qué LFI es tan peligroso para los sitios de WordPress

Local File Inclusion occurs when code builds a path to a local file using user-supplied input without proper validation, then includes or reads that file. In PHP, functions such as include(), require(), include_once(), and require_once() are common failure points — especially in themes and plugins that load template parts or files based on query parameters.

For WordPress the consequences are severe:

• wp-config.php often contains database credentials and salts; reading it can give an attacker full database access.
• Other files may contain API keys, SMTP credentials, or proprietary data.
• PHP stream wrappers (php://filter, data://) or accessible upload locations can help an attacker escalate from reading files to executing code.
• The flaw is unauthenticated, so mass automated scanning and exploitation are likely; rapid scanning by opportunistic attackers is expected.

How attackers typically exploit LFI (high level)

An attacker finds a parameter used in an include() call (for example: include( $template_path . $_GET[‘page’] . ‘.php’ ); ). Without validation, the attacker can send directory traversal payloads (../../../../wp-config.php) or use PHP stream wrappers (php://filter) to read arbitrary local files. LFI can often be chained to achieve remote code execution (RCE) by exposing writable upload areas or log files.

We do not provide working exploit payloads here; defenders should focus on recognizing the patterns and indicators listed below.

Indicadores de ataque y compromiso: qué buscar

Monitor web server access logs, PHP error logs, and any WordPress logging 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
3. Requests using common LFI parameter names:
   • Parámetros nombrados archivo, página, plantilla, inc, ruta, module
   • Bursts of varied traversal payloads to theme endpoints
4. Use of PHP stream wrapper patterns:
   • php://filter, expect://, data:// in query parameters
5. Abnormal files or modifications under writable directories:
   • New or suspicious PHP/JS files in wp-content/uploads, wp-content/themes//
   • Unexpectedly modified template or plugin files
6. Unusual database activity: unexpected admin user creation, odd queries, or content injections.

If you find any of these indicators, treat the situation as high priority and follow the incident response checklist below.

Immediate (hours) mitigation — triaged and practical actions

These steps are ordered by speed and likely impact. Perform them immediately if you run the affected theme or are unsure.

1. Temporarily disable the vulnerable theme
   • Switch to a standard, maintained default theme to remove the attack surface quickly.
   • If switching is not possible, place the site into maintenance mode while applying other mitigations.
2. Remove or quarantine the vulnerable theme from the filesystem
   • Using SFTP/SSH, rename or remove the vulnerable theme directory in wp-content/themes/ to prevent the theme code from running.
   • Keep an off-server copy for analysis if you are investigating.
3. Block suspicious requests at the web server
   • Block requests containing directory traversal sequences and PHP stream wrappers at the web server level (nginx or Apache). Test any rules on staging first to avoid breaking legitimate traffic.
   • Example nginx (conceptual):

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

   • Example Apache (.htaccess) — deny direct access to wp-config and block suspicious query strings:

   <Files "wp-config.php">
     Order allow,deny
     Deny from all
   </Files>
   
   <IfModule mod_rewrite.c>
     RewriteEngine On
     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)
   • Asegurar wp-config.php is not world-readable: use 400 or 440 donde sea adecuado.
   • Standard settings: directories 755, files 644 (tighten sensitive files further).
   • Ensure proper ownership and avoid running web server processes as the same user able to modify site files if your host supports separation.
5. Disable dangerous PHP wrappers and functions where possible
   • En php.ini, set allow_url_fopen = Apagar and allow_url_include = Apagar.
   • Consider disabling risky functions if not required: exec, shell_exec, system, passthru, proc_open, popen. Ejemplo:

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

6. Block user-supplied parameters used for file loads
   • If theme endpoints accept archivo or plantilla parameters, add temporary server-side rules to block or validate those parameters until you can patch.

Medium-term (days) remediation and verification

1. Replace or update the theme
   • Check for an official patched Welldone release that addresses CVE-2026-28118. When available, test on staging and then deploy to production.
   • If no patch exists, consider replacing the theme with a maintained alternative or create a custom child of a maintained base theme.
2. Audit your filesystem for webshells and suspicious files
   • Escanear wp-content/uploads, theme and plugin directories for unexpected PHP files, recent modifications, or known IOC patterns.
3. Rota credenciales y secretos
   • Rotate all WordPress admin passwords, database credentials, API keys, and any tokens that may have been exposed.
   • After restoring from backup, always rotate credentials.
4. Revisar los registros del servidor y de la aplicación
   • Search logs before and after the disclosure date for signs of exploitation. Export relevant logs to a secure location for forensics if needed.
5. Full site malware scan and integrity check
   • Run malware scanners and file-integrity checks to find webshells, backdoors, and modified core files. Compare code to known-good sources.
6. Restore from clean backups if compromise is confirmed
   • If you cannot confidently clean a compromised site, restore from a known-good backup taken before the earliest signs of compromise. After restoration, apply hardening and rotate credentials.

Long-term prevention and hardening (weeks / ongoing)

• Principle of least privilege: Ensure file and database users have only required permissions.
• Isolate environments: Use separate credentials and isolation between staging and production.
• Continuous monitoring and alerting: Centralise logs and add alerts for directory traversal attempts, references to wp-config.php, and unusual spikes in errors.
• Regular vulnerability scanning and code reviews: Automated scans plus periodic manual reviews of theme and plugin code.
• Regular backups and tested restores: Off-site, versioned backups and regular restore tests.
• WordPress hardening: Keep core, plugins, and themes updated; remove unused components; disable file editors; implement security headers and enforce HTTPS.

Suggested detection and prevention rules (conceptual)

Adapt these patterns into your WAF or server ruleset and test thoroughly to avoid false positives. These are conceptual regex snippets for rule creation:

• Block directory traversal: (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)
• Block PHP stream wrappers: (php://|data://|expect://|zip://|phar://)
• Block references to sensitive files: (wp-config\.php|/etc/passwd|/proc/self/environ|\.env|\.htpasswd)
• Block long encoded sequences often used for obfuscation: (%[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. Scope rules to likely endpoints to reduce false positives.

If your site has been compromised — incident response checklist

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 API keys and tokens that may have been stored on the server.
5. Scan and remove malicious files and webshells; if unsure, restore from a clean backup.
6. Verify database integrity and remove unauthorized admin users or injected content.
7. Conduct a full audit to determine the attack path and any lateral movement.
8. Rebuild the environment from known-good sources if necessary; do not rely solely on “cleaning” if backdoors may persist.

Developer and sysadmin technical note

This class of vulnerability typically stems from unsafe concatenation of user input into filesystem paths. Follow these secure practices:

• Never use raw user input to build filenames without whitelisting allowed values.
• Use mappings: map short keys to allowed filenames instead of accepting full paths.
• Normalize and validate any path before passing it to include/require.
• If user content determines template selection, restrict choices to a trusted set present in your codebase.

Example safe pattern (pseudo-code):

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

if (!in_array($template_name, $allowed_templates, true)) {
    $template_name = 'home';
}

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

Practical server snippets (summary)

Test these on a staging host before deploying to production:

Protege wp-config.php (Apache .htaccess):

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

Nginx rule to block php wrapper attempts (conceptual):

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

PHP ini hardening (example):

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

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

1. Inventory: Identify all sites running Welldone theme ≤ 2.4.
2. Apply at least one immediate mitigation:
   • Disable or rename the theme folder, or
   • Block exploit patterns at the server level, and
   • Lock down wp-config.php access.
3. Enable continuous scanning and monitoring for indicators described above.
4. If you host customers, inform stakeholders and apply mitigations across affected tenants promptly.

Need professional assistance?

If you manage many WordPress installations or lack in-house incident response capability, engage a reputable incident response provider or your hosting provider’s security team. Prioritise containment, log capture, and forensics before any aggressive cleanup that could destroy evidence.