Local File Inclusion in “Extensive VC Addons for WPBakery page builder” (<= 1.9.1) — What Site Owners Must Do Now

Author: Hong Kong Security Expert — Date: 2026-02-10

On 10 February 2026 a serious vulnerability (CVE-2025-14475) was published affecting the “Extensive VC Addons for WPBakery page builder” WordPress plugin in versions up to and including 1.9.1. The issue is an unauthenticated Local File Inclusion (LFI), rated high severity (CVSS 8.1). Because this can be exploited remotely without authentication in many configurations, site owners running this plugin must take immediate action to protect their websites and visitors.

This article, written by a Hong Kong-based security practitioner, explains plainly what the risk is, how attackers might attempt to exploit it, how to detect attempts or compromise, and the urgent mitigations to keep your site safe while you apply longer-term fixes. Exploit payloads and step-by-step attack instructions are intentionally omitted.

Resumen ejecutivo

• Vulnerability: Unauthenticated Local File Inclusion (LFI) via the plugin’s parameter handling (commonly reported as the shortcode_name parameter).
• Affected versions: Extensive VC Addons for WPBakery page builder ≤ 1.9.1.
• CVE: CVE-2025-14475
• Severity: High (CVSS 8.1)
• Risk: Exposure of local server files (including wp-config.php), credential leaks, potential escalation to remote code execution (RCE) in some server setups, and full site takeover.
• Immediate priorities: Inventory affected sites, disable or remove the plugin where possible, apply targeted blocking (e.g., WAF rules), rotate secrets if compromise is suspected, and monitor logs for indicators of compromise.

¿Qué es la Inclusión de Archivos Locales (LFI) y por qué es importante?

Local File Inclusion (LFI) is an injection vulnerability that allows an attacker to force a web application to read and sometimes execute files from the local filesystem. Harmful outcomes include:

• Disclosure of sensitive files such as wp-config.php, .env, private keys, or logs containing credentials.
• Chaining with other weaknesses (insecure uploads, deserialization flaws) to achieve code execution.
• Using the compromised host to pivot to internal networks or other hosted services.

An unauthenticated LFI is particularly dangerous: it can be triggered by anyone on the internet and can expose sensitive data very quickly.

How this plugin vulnerability works (high level)

The reported issue stems from the plugin using a parameter (publicly disclosed as shortcode_name) in a file inclusion operation without adequate validation. Secure code never directly includes files based on unsanitised user input; instead it should map allowed keys to safe file paths. When input validation is missing, an attacker can craft requests to read local files.

Key points for defenders:

• The vulnerability is unauthenticated and may be triggered remotely.
• An attacker can potentially make the plugin read arbitrary files accessible to the PHP process.
• The actual impact depends on file permissions, server configuration, and other installed software or plugins.

¿Qué sitios están afectados?

• Any WordPress installation with the “Extensive VC Addons for WPBakery page builder” plugin installed and running version 1.9.1 or earlier.
• If the plugin is deactivated or removed, the immediate risk is reduced — but confirm that no copies, backups or custom integrations retain the vulnerable code path.
• In certain WordPress configurations, plugin files left on disk can be invoked indirectly; best practice is to remove the vulnerable plugin entirely if it is not required.

How attackers might exploit this (overview)

Attackers will typically scan for websites using the plugin and send HTTP requests containing parameters that control file inclusion. If the plugin processes a shortcode_name parameter without sanitisation, the attacker may use directory traversal or attempt to reference sensitive files.

Because the vulnerability requires no authentication, automated scanning and exploitation attempts are likely to increase after public disclosure. The speed of successful exploitation depends on the site’s configuration and how the plugin handles paths.

Mitigación inmediata — qué hacer ahora mismo

Perform these steps immediately, prioritised by risk and operational impact.

1. Audit and inventory

• Identify every site using the plugin. Search plugin folders on disk (e.g., wp-content/plugins/extensive-vc-addon) or use your site management tools.
• If you manage many sites, automate inventorying to avoid missed instances.

2. Disable or remove the plugin (highest priority)

• If feasible, deactivate the plugin immediately. If the plugin is non-essential, delete it from the filesystem.
• If taking the plugin offline breaks critical functionality, follow step 3 and harden the exposed interfaces until you can remove or patch it.

3. Apply targeted blocking / virtual patching

• If you cannot remove the plugin immediately, implement targeted blocking rules at the application layer to stop exploitation attempts that manipulate the vulnerable parameter.
• Block requests that include directory traversal sequences, references to wp-config.php or .env, or suspicious encoded payloads in parameters related to the plugin.

4. Harden file access

• Prevent PHP execution under wp-content/uploads and other writable directories.
• Set restrictive file permissions so the PHP process has only the minimum read/write access required.

5. Monitor logs and scan for compromise

• Review web server and application logs for suspicious requests containing the plugin parameter (see Detecting attempts, below).
• Run a full malware scan and a file integrity check to detect webshells or unexpected changes.

6. Rotate secrets if compromise suspected

• If you find evidence of file disclosure (for example, contents of wp-config.php), rotate database credentials, WordPress salts, any API keys, and reset administrator passwords immediately.

7. Apply vendor patch when available

• When the plugin author releases a verified patch, test it on staging and deploy to production promptly.
• Until the patch is applied, keep mitigations (blocking rules, monitoring) in place.

Detección de intentos e indicadores de compromiso

Monitoring and detection are essential to block exploit attempts and to identify successful compromises.

Dónde buscar

• Web server access logs (Apache, Nginx) — search for suspicious query strings and abnormal responses.
• Application logs (WordPress debug logs) — inclusion attempts may produce warnings, errors, or unexpected output.
• File system — newly added PHP files under writable directories, modified theme or plugin files, and unknown scheduled tasks are red flags.

Search patterns and examples

Look for requests referencing shortcode_name, directory traversal sequences, or attempts to read common configuration files. Example searches (use them in your log analysis tools):

grep -i "shortcode_name" /var/log/nginx/access.log*

awk '{print $7}' /var/log/apache2/access.log | grep -iE "%2e%2e|../|wp-config.php|.env"

Also search for:

• Directory traversal patterns: ../ or URL-encoded equivalents (%2e%2e%2f).
• Requests containing filenames like wp-config.php or .env.
• Unexpectedly large responses or responses that include raw file contents.

File-scan indicators

• Nuevos archivos PHP en wp-content/uploads or other writable locations.
• Unknown admin users or modified user roles.
• Unexpected cron jobs or scheduled tasks.

Immediate incident response checklist

• Isolate the site (maintenance mode or IP-restriction).
• Preserve logs and take a forensic backup (disk image, database dump).
• Rotate database credentials, salts, and reset administrator passwords.
• Fully scan and clean the filesystem; restore from a known-good backup if compromise is confirmed.
• Coordinate with your hosting provider for deeper forensic analysis if needed.

Recommended WAF/defensive rules (practical guidance)

Application-layer blocking is often the fastest way to reduce risk. The following defensive patterns are for configuration guidance only — they do not contain exploit information.

1. Parameter blocking: block requests containing a shortcode_name parameter whose value includes directory traversal (../), encoded traversal, references to sensitive filenames (wp-config.php, .env), null bytes, or PHP file extensions.
2. Whitelist approach: if the shortcode parameter should only accept a small set of values, implement a whitelist allowing only those known values.
3. HTTP method restrictions: limit allowed methods for the plugin endpoints if applicable.
4. Rate limit suspicious requests and apply IP reputation controls where available.
5. Virtual patching: target blocking on the presence of shortcode_name combined with traversal patterns or references to sensitive files.

Example conceptual rule logic (adapt to your WAF syntax):

IF request contains parameter "shortcode_name" AND parameter value matches regex "(\.\./|%2e%2e|wp-config\.php|\.env|%00|\.php)" THEN block

Always test rules in detection mode first to reduce false positives, and tune using a staging environment where possible.

Illustrative mod_security-style rule (conceptual)

The following is an illustrative defensive signature for a ModSecurity-style WAF. Adapt and test before use.

# Block suspicious shortcode_name usage that may indicate LFI attempts
SecRule REQUEST_URI|ARGS_NAMES|ARGS "shortcode_name" "phase:2,chain,deny,status:403,msg:'Blocked suspicious shortcode_name LFI attempt'"
    SecRule ARGS:shortcode_name "@rx (\.\./|%2e%2e|wp-config\.php|\.env|%00|\.php)" "t:none,t:urlDecode,t:lowercase"

Notes: use detection mode initially and validate against your legitimate traffic to avoid blocking valid requests.

Patching and long-term remediation

• Apply an official plugin update as soon as the developer releases a verified patch. Test it in staging before production deployment.
• If no patch is yet available, retain virtual patches and consider removing the plugin until a safe update is released.
• If the plugin is unmaintained or the vendor response is insufficient, replace it with a maintained alternative that follows secure coding practices.

If you were compromised: incident response expanded

Confirm signs of compromise (file disclosures, modified files, unknown admin accounts, unusual outbound connections) and follow containment/eradication steps:

1. Isolate the host and preserve forensic evidence (logs, file hashes, database dump).
2. Restore from a known-good backup if possible.
3. Replace credentials and keys for database, admin accounts, and third-party services.
4. Reinstale el núcleo de WordPress, temas y plugins de fuentes confiables.
5. Harden the environment: restrictive file permissions, disable PHP execution in upload directories, remove unused plugins and themes.
6. Monitor for re-infection for at least 90 days; attackers often leave secondary access mechanisms.

For severe incidents, consider engaging professional forensic assistance to ensure a complete investigation and remediation.

Developer guidance (how to fix this class of vulnerability)

Developers should follow secure coding patterns to prevent LFI:

• Never use incluir/requerir with raw user input. Map user-supplied keys to a predefined whitelist of file paths.
• Uso ruta real and verify resolved paths are within expected directories.
• Reject any input containing directory traversal (..) or NUL bytes.
• Implement unit tests and fuzzing for input handling, and include security code review in release processes.

General WordPress hardening tips (beyond immediate mitigation)

• Mantener el núcleo de WordPress, los temas y los plugins actualizados.
• Minimiza los plugins instalados y elimina los que no se usan.
• Use principle of least privilege for database and system accounts.
• Desactive la edición de archivos en el panel de control (define('DISALLOW_FILE_EDIT', true);).
• Install file integrity monitoring to detect unexpected changes.
• Disable PHP execution in upload directories via server rules.
• Use strong, unique passwords and enable two-factor authentication for admin accounts.
• Maintain offline backups and test restore procedures regularly.

Si necesitas asistencia

If you require help with immediate containment, log analysis, or remediation, engage a trusted security consultant or incident response provider. Prioritise providers with experience in WordPress incident response and forensic investigation. Ensure any external party follows non-disclosure and evidence-preservation best practices.

Preguntas frecuentes

Q: My site uses the affected plugin but everything looks fine. Do I still need to act?
A: Yes. An unauthenticated LFI can be triggered without obvious signs. If the plugin version is ≤ 1.9.1, follow the mitigation steps: disable or remove the plugin if possible, apply targeted blocking, and monitor logs.

P: ¿Puede un WAF protegerme completamente?
A: A properly tuned application-layer firewall can significantly reduce risk and block many exploitation attempts, but it is not a permanent substitute for a vendor-supplied patch. Treat WAF protections as temporary mitigation until you can apply the official fix and perform a full security review.

Q: What if I can’t take the plugin offline because it breaks the site?
A: Implement targeted blocking rules to restrict suspicious parameter values, apply IP throttling, and restrict access to the affected endpoints where possible. Plan for removal or replacement as soon as operationally feasible.

Cierre

This LFI is a high-severity vulnerability that risks confidentiality and integrity of hosted sites. If you run the affected plugin version (≤ 1.9.1), act now: identify affected sites, remove or disable the plugin where possible, apply targeted blocking and monitoring, rotate secrets if you suspect disclosure, and apply the vendor patch when it becomes available. Prompt mitigations often prevent an incident from becoming a costly breach.

— Experto en Seguridad de Hong Kong