Nombre del complemento	Bien hecho
Tipo de vulnerabilidad	Inclusión de archivos locales
Número CVE	CVE-2026-28118
Urgencia	Alto
Fecha de publicación de CVE	2026-02-28
URL de origen	CVE-2026-28118

Urgente: Inclusión de Archivos Locales en el Tema Welldone (<= 2.4) — Lo que los Propietarios de Sitios de WordPress Deben Hacer Ahora

Se ha divulgado una vulnerabilidad de alta gravedad de Inclusión de Archivos Locales (LFI) que afecta al tema de WordPress Welldone (versiones <= 2.4). Rastreada como CVE-2026-28118 y asignada con una puntuación base CVSS de 8.1, esta debilidad permite a atacantes no autenticados incluir archivos locales en un sitio vulnerable y exponer su contenido al atacante. Debido a que la información almacenada en archivos locales (credenciales de base de datos, claves API, detalles de configuración) puede llevar a una compromisión total, se requiere una mitigación inmediata para cualquier sitio que ejecute el tema afectado.

Estoy escribiendo como parte del equipo de seguridad de WP‑Firewall con orientación práctica y directa: por qué esto es peligroso, cómo funciona a nivel técnico, cómo detectar intentos de explotación y una lista de verificación priorizada de acciones inmediatas y a medio plazo que puedes tomar para proteger tu sitio de WordPress. Si administras múltiples sitios o clientes de hosting gestionado, comparte esta publicación con tus equipos — los pasos a continuación están clasificados por urgencia y facilidad de implementación.

Resumen de la divulgación

• Software afectado: Tema de WordPress Welldone
• Versiones vulnerables: <= 2.4
• Tipo de vulnerabilidad: Inclusión de Archivos Locales (LFI)
• CVE: CVE-2026-28118
• CVSS: 8.1 (Alto)
• Privilegios requeridos: Ninguno (no autenticado)
• Impacto: Lectura arbitraria de archivos locales; posible divulgación de credenciales y archivos sensibles; puede llevar a una toma de control total dependiendo de la configuración del servidor
• Reportado por: Tran Nguyen Bao Khanh (reportado el 19 de agosto de 2025; divulgación pública el 26 de febrero de 2026)

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

La Inclusión de Archivos Locales ocurre cuando una aplicación construye una ruta a un archivo local utilizando la entrada proporcionada por el usuario, sin la validación o saneamiento adecuado, y luego incluye o lee esa ruta. En PHP, funciones como incluir(), require(), include_once(), y require_once() son lugares comunes donde aparecen tales errores — particularmente en temas y plugins que cargan partes de plantillas o archivos externos basados en parámetros de URL.

Para los sitios de WordPress, las consecuencias son particularmente graves:

• wp-config.php a menudo incluye credenciales de base de datos y sales; leerlo puede dar a un atacante acceso completo a la base de datos.
• Otros archivos pueden contener claves API, credenciales SMTP o datos propietarios.
• Si los envoltorios de PHP (por ejemplo, php://filter) o ubicaciones de carga son accesibles, un atacante puede escalar de leer archivos a ejecutar código (por ejemplo, localizando y extrayendo una carga escribible que se utilizará más tarde para almacenar una puerta trasera).
• Debido a que la falla es accesible sin autenticación, es probable que se realicen intentos de escaneo y explotación automatizados masivos — y esperamos que atacantes oportunistas apunten rápidamente a instalaciones expuestas.

Cómo los atacantes suelen explotar LFI (nivel alto)

Un atacante descubre un parámetro que se utiliza en una llamada de inclusión de archivos (por ejemplo, algo como include( $template_path . $_GET['page'] . '.php' ); ). Si ese parámetro no se valida, el atacante puede enviar solicitudes que hagan referencia a otros archivos locales a través de la exploración de directorios (../../../../wp-config.php) o a través de envolturas de flujo PHP (php://filter, datos://). Incluso cuando la inclusión directa está bloqueada, muchas cadenas LFI pueden convertirse en ejecución remota de código (RCE) al exponer primero archivos, registros o incluir otros recursos accesibles.

No compartiremos cargas útiles de explotación funcionales aquí, pero es importante que los defensores reconozcan los patrones e indicadores descritos en la sección de detección a continuación.

Indicadores de ataque y compromiso: qué buscar

Monitorea tus registros (registros de acceso del servidor web, registros de errores de PHP, registros de WordPress) en busca de estas señales:

1. Solicitudes que contienen patrones de exploración de directorios en cadenas de consulta:
   • No codificados o codificados "../" secuencias (por ejemplo, .., %2e%2e%2f)
   • Intentos de exploración repetidos como ../../../../
2. Solicitudes que hacen referencia a nombres de archivos sensibles:
   • wp-config.php, wp-config.php.bak, .env, /etc/passwd, .htpasswd, etc.
3. Solicitudes que utilizan nombres de parámetros LFI comunes:
   • Parámetros de consulta llamados archivo, página, plantilla, inc, ruta, módulo, u otros
   • Aumentos repentinos de solicitudes a los puntos finales del tema con cargas útiles de exploración variadas
4. Uso de patrones de envoltura de flujo PHP:
   • php://filter, expect://, datos:// apareciendo en parámetros de consulta
5. Entradas de registro anormales o nuevos archivos PHP/JS en wp-content/uploads, wp-content/themes//, o en otros directorios escribibles:
   • Archivos con nombres sospechosos
   • Plantillas o archivos de plugins modificados recientemente que no cambiaste
6. Consultas de base de datos inusuales repentinas, creación inesperada de usuarios administradores o cambios en archivos de temas/plugins principales.

Si encuentras alguno de los anteriores, trátalos como alta prioridad y sigue los pasos de incidente a continuación.

Mitigación inmediata (horas) — acciones prácticas y clasificadas

Si tienes una de las versiones afectadas o no estás seguro, aplica una o más de estas mitigaciones inmediatas. Están ordenadas por velocidad e impacto:

1. Desactiva temporalmente el tema vulnerable:
   • Cambia a un tema predeterminado (por ejemplo, un tema estándar limpio y mantenido). Esta es la forma más rápida de eliminar la superficie de ataque si puedes permitirte un breve cambio visual.
   • Si eso no es posible, coloca el sitio en modo de mantenimiento mientras aplicas otras mitigaciones.
2. Elimina o pone en cuarentena el tema vulnerable del sistema de archivos:
   • Si tienes acceso al servidor (SFTP/SSH), renombra o elimina el directorio del tema vulnerable de wp-content/themes/. Esto evita que el código del tema se ejecute.
   • Importante: Mantén una copia (fuera del servidor) para análisis si estás investigando.
3. Bloquea solicitudes sospechosas en el servidor web o en el firewall de la aplicación web:
   • Bloquea solicitudes con secuencias de recorrido de directorios e intentos de acceder a archivos principales:
   • Ejemplo (nginx, simplificado): denegar solicitudes con .. secuencias codificadas o php://:

   if ($request_uri ~* "(||\.\./|\.\.\\)") {
   

   • Nota: Utilice pruebas cautelosas antes de aplicar reglas a nivel de servidor para evitar romper URLs legítimas; pruebe en un sitio de staging cuando sea posible.
   • Ejemplo (Apache .htaccess) — denegar el acceso directo a wp-config y bloquear cadenas de consulta con patrones sospechosos:

   <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. Endurecer permisos y propiedad de archivos (verificaciones rápidas):
   • Asegúrate wp-config.php no es legible por el mundo. Permisos recomendados:
     • wp-config.php → 400 o 440 dependiendo de la configuración del servidor
     • Directorios → 755
     • Archivos → 644 (excepto archivos de configuración sensibles que deben ser más estrictos)
   • Asegúrese de que los archivos sean propiedad del usuario correcto (el usuario del servidor web no debe ser propietario de los archivos si su host admite una separación más segura).
5. Desactive envolturas y funciones PHP peligrosas donde sea posible:
   • En php.ini, asegúrese allow_url_fopen = Apagar y allow_url_include = Apagar. Esto reduce el riesgo de inclusión de archivos remotos o abuso de envolturas de flujo.
   • Considere desactivar funciones arriesgadas (solo si su aplicación no las necesita): exec, shell_exec, sistema, passthru, proc_open, popen. Ejemplo:

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

6. Bloquear parámetros proporcionados por el usuario utilizados para cargas de archivos:
   • Si identifica puntos finales de tema específicos que aceptan archivo o plantilla parámetros, agregue reglas de bloqueo rápidas del lado del servidor para solicitudes que incluyan esos nombres de parámetros hasta que el tema sea corregido.
7. Active un WAF/parche virtual
   • Si ejecuta un firewall de aplicación web gestionado (WAF) o un plugin de seguridad que puede implementar parches virtuales, habilite o agregue reglas que:
     • Detecten secuencias de recorrido de directorios
     • Detectar php:// y datos:// envolturas
     • Bloquear solicitudes que intentan acceder wp-config.php o otros archivos sensibles
   • El parcheo virtual previene la explotación incluso si el código subyacente sigue siendo vulnerable, dándote tiempo hasta que un parche oficial esté disponible.

Remediación y verificación a medio plazo (días)

1. Reemplazar o actualizar el tema
   • Verificar si hay un parche oficial o una nueva versión del tema que aborde CVE-2026-28118. Si se dispone de un lanzamiento parcheado oficial, pruébalo a fondo en staging y luego actualiza producción.
   • Si no existe un parche oficial, considera reemplazar el tema por una alternativa mantenida o un hijo codificado a medida de un tema base mantenido.
2. Audita tu sistema de archivos en busca de webshells y archivos sospechosos
   • Escanear wp-content/uploads, directorios de temas y directorios de plugins para:
     • Archivos con PHP ejecutable donde no debería haber
     • Archivos con marcas de tiempo recientemente cambiadas que no reconoces
     • Indicadores conocidos de tus sistemas de detección de intrusiones
3. Rotar credenciales y secretos
   • Cambia todas las contraseñas de administrador de WordPress, contraseñas de base de datos, claves API y cualquier otra credencial que pueda estar almacenada en el servidor o expuesta.
   • Si restauras desde una copia de seguridad, rota las credenciales después.
4. Revisa los registros del servidor y de la aplicación
   • Revisa los registros del período antes y después de la fecha de divulgación en busca de actividad sospechosa que indique una explotación exitosa (por ejemplo, códigos de respuesta que incluyan salida de archivos sensibles, o intentos de explotación repetidos).
   • Exporta los registros relevantes a un lugar seguro para cualquier trabajo forense necesario.
5. Escaneo completo de malware del sitio y verificación de integridad
   • Ejecuta un escaneo completo de malware; muchos escáneres detectarán webshells, puertas traseras y archivos centrales modificados.
   • Utilice herramientas de integridad de archivos para comparar su base de código con fuentes conocidas como buenas.
6. Restaure desde copias de seguridad limpias si se confirma el compromiso
   • Si encuentra evidencia de compromiso que no puede limpiar completamente, restaure desde una copia de seguridad tomada antes de los primeros signos de compromiso. Asegúrese de realizar los otros pasos de remediación (permisos rígidos, rotación de credenciales) después de la restauración.

Prevención y endurecimiento a largo plazo (semanas / en curso)

1. Principio de mínimo privilegio
   • Asegúrese de que los usuarios de archivos y bases de datos tengan solo los permisos que necesitan.
   • Evite ejecutar procesos del servidor web como el mismo usuario que puede modificar archivos.
2. Aislar entornos
   • Mantenga los entornos de staging y producción aislados.
   • Use diferentes credenciales para diferentes entornos.
3. Monitoreo y alertas continuas
   • Centralice los registros (acceso, error, PHP) y agregue alertas para:
     • Intentos de recorrido de directorios
     • Solicitudes que hacen referencia wp-config.php y otros archivos sensibles
     • Picos inusuales en respuestas 4xx/5xx
4. Escaneo regular de vulnerabilidades
   • Realice escaneos automatizados y revisiones manuales programadas regularmente del código de temas y plugins.
   • Suscríbase a fuentes de inteligencia sobre vulnerabilidades y configure sus procedimientos de gestión de parches para que sean receptivos.
5. Copias de seguridad regulares y restauraciones probadas
   • Mantén copias de seguridad versionadas fuera del sitio y prueba los procedimientos de restauración regularmente.
6. Endurecimiento de WordPress en sí
   • Mantén actualizado el núcleo de WordPress, los plugins y los temas.
   • Elimine los plugins y temas que no utilice.
   • Desactive o proteja los editores de temas y plugins.
   • Implemente encabezados de seguridad y HTTPS en todas partes.

Reglas de detección y prevención de WAF sugeridas (conceptuales)

A continuación se presentan patrones defensivos que puede adaptar a su WAF o conjunto de reglas del servidor. Estas son firmas regex conceptuales y deben ser probadas antes de la implementación para evitar falsos positivos.

• Bloquear solicitudes con intentos de recorrido de directorios (básico):
  • Expresión regular: (\.\./|\.\.\\||)
• Bloquear envolturas php://, data://, expect://:
  • Expresión regular: (php://|data://|expect://|zip://|phar://)
• Bloquear intentos de referencia a archivos sensibles en cadenas de consulta:
  • Expresión regular: (wp-config\.php|/etc/passwd|/proc/self/environ|\.env|\.htpasswd)
• Bloquear largas secuencias de caracteres codificados que indican ofuscación:
  • Expresión regular: (%[0-9A-Fa-f]{2}){6,}

Ejemplo de pseudo-regla (agnóstico de WAF):

• Si una cadena de consulta de solicitud coincide con cualquiera de:
  • (\.\./|\.\.\\||) O
  • (php://|data://|expect://) O
  • (wp-config\.php|/etc/passwd|\.env)

  → entonces bloquear la solicitud (HTTP 403) y registrar detalles para revisión.

Notas sobre falsos positivos: Muchos CMS y bibliotecas legítimas pueden incluir tokens que se asemejan a patrones de riesgo. Pruebe cuidadosamente cualquier patrón, limite las reglas a los puntos finales probables (archivos de tema, puntos finales de inclusión) y ajuste gradualmente la cobertura.

Si su sitio ha sido comprometido — lista de verificación de respuesta a incidentes

Si confirma un compromiso, siga estos pasos de inmediato:

1. Ponga el sitio fuera de línea (modo de mantenimiento) o aísle el host.
2. Tome una instantánea completa del sitio y los registros para análisis forense.
3. Cambie todas las contraseñas (usuarios administradores, base de datos, FTP/SFTP, panel de control).
4. Rote todas las claves y tokens que puedan haber sido almacenados en el servidor.
5. Escanee y elimine archivos maliciosos y webshells. Si no está seguro de la limpieza manual, restaure desde una copia de seguridad limpia.
6. Verifique la integridad de la base de datos y elimine usuarios administradores no autorizados o inyecciones de contenido.
7. Realice una auditoría completa para identificar cómo el atacante obtuvo acceso y qué movimientos laterales pudo haber ejecutado.
8. Reconstruya el entorno a partir de fuentes conocidas y buenas si es necesario; no confíe en “solo limpiar” si las puertas traseras son complejas.

Cómo WP‑Firewall ayuda (lo que un WAF administrado hace por usted)

Desde la perspectiva de un servicio de seguridad de WordPress administrado, endurecemos y protegemos sitios combinando varias capas:

• Parches virtuales (reglas de WAF): Cuando aparece una vulnerabilidad como este LFI, podemos implementar reglas específicas que detectan y bloquean patrones de explotación en sus sitios hasta que un parche del proveedor esté disponible.
• Cortafuegos administrado e inspección de solicitudes: Análisis en tiempo real de los parámetros de solicitud para bloquear secuencias de recorrido, uso de envolturas PHP y otras firmas de explotación.
• Escaneo de malware y limpieza automatizada: Escaneos continuos para encontrar archivos maliciosos y eliminación automatizada para muchos webshells y puertas traseras conocidos.
• Mitigación de OWASP Top 10: Protecciones sistémicas diseñadas para reducir riesgos de las clases de amenazas más comunes (Inyección, Autenticación Rota, LFI/RFI, etc.).
• Monitoreo, alertas e informes: Monitoreamos anomalías de tráfico y emitimos alertas oportunas si detectamos intentos de explotación o evidencia de compromiso.

Recomendamos una estrategia en capas: combine parches virtuales y protección WAF con configuración segura, actualizaciones rápidas y monitoreo. Los parches virtuales brindan protección inmediata mientras realiza las pruebas cuidadosas requeridas para actualizaciones oficiales o reemplazos de temas.

Una breve nota técnica para desarrolladores y administradores de sistemas

Esta clase de vulnerabilidad casi siempre se origina de la concatenación insegura de la entrada del usuario en rutas del sistema de archivos. Su lista de verificación para archivos seguros incluye:

• Nunca use directamente la entrada del usuario para construir nombres de archivos sin blanquear los valores permitidos.
• Use mapeos seguros (por ejemplo, mapee claves cortas y conocidas a nombres de archivos permitidos) en lugar de aceptar la entrada de ruta completa.
• Normalice y valide cualquier ruta antes de pasarla a include/require.
• Si el contenido del usuario determina la selección de la plantilla, restrinja las opciones a un conjunto de confianza que exista en su base de código.

Ejemplo de enfoque más seguro (pseudo-código):

<?php;

Este patrón asigna la entrada del usuario a una lista controlada y previene la inclusión arbitraria de archivos.

Nuevo recurso para propietarios de sitios: Comienza con protección inmediata y gratuita

Protege tu sitio ahora con nuestro plan Básico Gratuito: firewall gestionado, WAF, escaneo de malware y cobertura para los riesgos del OWASP Top 10. Está diseñado para proteger sitios de inmediato mientras planificas cualquier actualización o reemplazo de tema necesario.

Asegura tu sitio ahora mismo: Comienza con WP‑Firewall Básico (Gratis)

• Lo que obtienes al instante:
  • Firewall gestionado y WAF con capacidad de parcheo virtual
  • Ancho de banda ilimitado para tráfico de seguridad
  • Escaneo de malware para encontrar archivos y cambios sospechosos
  • Protecciones contra las amenazas del OWASP Top 10 (incluidos patrones LFI)
• Por qué ayuda:
  • Obtienes bloqueo inmediato de patrones de explotación conocidos para vulnerabilidades recién divulgadas
  • El parcheo virtual reduce la ventana de ataque mientras pruebas actualizaciones oficiales o migras
• Comienza: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(También ofrecemos niveles de pago si necesitas eliminación automática de malware, controles de bloqueo de IP, informes mensuales o servicios de seguridad gestionados.)

Ejemplos prácticos: reglas rápidas que puedes pegar y probar (resumen)

• Protege wp-config.php (coloca en .htaccess):

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

• Regla de Nginx para bloquear intentos con envoltura php:

if ($query_string ~* "php://|data://||(\.\./)") {

• Endurecimiento de PHP ini:

allow_url_fopen = Off

Importante: Prueba estas reglas en staging para asegurarte de que no bloqueen tráfico legítimo para el comportamiento específico de tu tema o plugin.

Recomendaciones finales — qué hacer en las próximas 24–72 horas

1. Inventario: Identifica cualquier sitio que ejecute el tema Welldone ≤ 2.4.
2. Aplique al menos una mitigación inmediata:
   • Desactive/cambie el nombre de la carpeta del tema, o
   • Bloquee patrones de explotación a nivel de servidor/WAF, y
   • Restringa el acceso a wp-config.php.
3. Habilite escaneo y monitoreo continuos.
4. Si puede, inscríbase en un plan de protección gestionado (disponible nivel gratuito) para aplicar parches virtuales de inmediato mientras planea una solución permanente.
5. Comuníquese con las partes interesadas si aloja sitios de clientes: la transparencia y la mitigación rápida son importantes.

Si necesita asistencia técnica

Si ejecuta múltiples instalaciones de WordPress o gestiona sitios de clientes y desea ayuda para clasificar o aplicar mitigaciones, nuestro equipo de operaciones de seguridad puede ayudar a analizar registros, implementar parches virtuales en su flota y asistir con la respuesta a incidentes y limpieza. También proporcionamos orientación paso a paso para actualizaciones seguras y reemplazos de temas vulnerables.

Conclusión

Esta vulnerabilidad Welldone LFI (CVE-2026-28118) es una vulnerabilidad seria y no autenticada que puede exponer archivos locales y llevar a la divulgación de credenciales y compromiso total. El camino más rápido hacia la seguridad es eliminar o poner en cuarentena el tema vulnerable e implementar reglas de parcheo virtual en el perímetro mientras planea una actualización o reemplazo controlado. Endurecer el servidor (desactivar envolturas arriesgadas, corregir permisos, restringir el acceso a archivos) y monitorear registros en busca de los indicadores anteriores reducirá la exposición drásticamente.

Si desea protección inmediata sin cambios complejos en el servidor, pruebe nuestro plan gratuito de protección básica que proporciona reglas de firewall gestionadas, protecciones WAF y escaneo de malware para bloquear patrones de explotación como los utilizados en ataques LFI. Comience a asegurar su sitio ahora: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

- El equipo de seguridad de WP-Firewall

Referencias y notas

• Vulnerabilidad rastreada como CVE-2026-28118 (Inclusión de Archivos Locales en el tema Welldone, reportada el 19 de agosto de 2025; publicada el 26 de febrero de 2026).
• Este aviso está destinado a ayudar a los defensores. No publicamos código de explotación aquí. Si usted es un administrador que sospecha de una violación y necesita asistencia directa, escale a sus respondedores de seguridad o comuníquese con un proveedor de seguridad de WordPress de confianza.