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 un puntaje base CVSS de 8.1, esta debilidad permite a atacantes no autenticados incluir archivos locales en un sitio vulnerable y exponer su contenido. La información en archivos locales (credenciales de base de datos, claves API, detalles de configuración) puede llevar a una compromisión total — se requiere acción inmediata para cualquier sitio que utilice el tema afectado.

Este aviso está escrito con un tono práctico, de un profesional de seguridad de Hong Kong: conciso, priorizado y enfocado en la contención rápida seguida de verificación y recuperación. Comparte esto con tus equipos de operaciones o alojamiento y prioriza los pasos de “Mitigación inmediata” si administras múltiples sitios.

Resumen de la divulgación

• Software afectado: Tema Welldone de WordPress
• 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 el código construye una ruta a un archivo local utilizando la entrada proporcionada por el usuario sin la validación adecuada, y luego incluye o lee ese archivo. En PHP, funciones como include(), require(), include_once() y require_once() son puntos de fallo comunes — especialmente en temas y plugins que cargan partes de plantillas o archivos basados en parámetros de consulta.

Para WordPress, las consecuencias son graves:

• wp-config.php a menudo contiene 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.
• Los envoltorios de flujo de PHP (php://filter, data://) o ubicaciones de carga accesibles pueden ayudar a un atacante a escalar de leer archivos a ejecutar código.
• La falla es no autenticada, por lo que es probable que se realicen escaneos y explotaciones automatizadas masivas; se espera un escaneo rápido por parte de atacantes oportunistas.

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

Un atacante encuentra un parámetro utilizado en una llamada include() (por ejemplo: include( $template_path . $_GET[‘page’] . ‘.php’ ); ). Sin validación, el atacante puede enviar cargas útiles de recorrido de directorios (../../../../wp-config.php) o usar envoltorios de flujo de PHP (php://filter) para leer archivos locales arbitrarios. LFI a menudo se puede encadenar para lograr ejecución remota de código (RCE) al exponer áreas de carga escribibles o archivos de registro.

No proporcionamos cargas útiles de explotación funcionales aquí; los defensores deben centrarse en reconocer los patrones e indicadores que se enumeran a continuación.

Indicadores de ataque y compromiso: qué buscar

Monitorear los registros de acceso del servidor web, los registros de errores de PHP y cualquier registro de WordPress en busca de estas señales:

1. Solicitudes que contienen patrones de recorrido de directorios en cadenas de consulta:
   • Secuencias “../” no codificadas o codificadas (por ejemplo, ..%2F, %2e%2e%2f)
   • Intentos de recorrido repetidos como ../../../../
2. Solicitudes que hacen referencia a nombres de archivos sensibles:
   • wp-config.php, wp-config.php.bak, .env, /etc/passwd, .htpasswd
3. Solicitudes que utilizan nombres de parámetros LFI comunes:
   • Parámetros nombrados archivo, página, plantilla, inc, ruta, módulo
   • Explosiones de cargas útiles de recorrido variadas a los puntos finales del tema
4. Uso de patrones de envoltura de flujo de PHP:
   • php://filter, expect://, data:// en parámetros de consulta
5. Archivos anormales o modificaciones en directorios escribibles:
   • Nuevos archivos PHP/JS sospechosos en wp-content/uploads, wp-content/themes//
   • Archivos de plantilla o plugin modificados inesperadamente
6. Actividad inusual en la base de datos: creación inesperada de usuarios administradores, consultas extrañas o inyecciones de contenido.

Si encuentra alguno de estos indicadores, trate la situación como de alta prioridad y siga la lista de verificación de respuesta a incidentes a continuación.

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

Estos pasos están ordenados por velocidad e impacto probable. Realízalos de inmediato si utilizas el tema afectado o si no estás seguro.

1. Desactiva temporalmente el tema vulnerable
   • Cambia a un tema predeterminado estándar y mantenido para eliminar rápidamente la superficie de ataque.
   • Si no es posible cambiar, coloca el sitio en modo de mantenimiento mientras aplicas otras mitigaciones.
2. Elimina o pone en cuarentena el tema vulnerable del sistema de archivos
   • Usando SFTP/SSH, renombra o elimina el directorio del tema vulnerable en wp-content/themes/ para evitar que el código del tema se ejecute.
   • Mantén una copia fuera del servidor para análisis si estás investigando.
3. Bloquea solicitudes sospechosas en el servidor web
   • Bloquea solicitudes que contengan secuencias de recorrido de directorios y envolturas de flujo PHP a nivel del servidor web (nginx o Apache). Prueba cualquier regla en staging primero para evitar romper el tráfico legítimo.
   • Ejemplo nginx (conceptual):

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

   • Ejemplo Apache (.htaccess) — denegar acceso directo a wp-config y bloquear cadenas de consulta sospechosas:

   <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. Endurece los permisos y la propiedad de los archivos (verificaciones rápidas)
   • Asegurar wp-config.php no es legible por el mundo: usa 400 or 440 donde sea adecuado.
   • Configuraciones estándar: directorios 755, archivos 644 (ajusta aún más los archivos sensibles).
   • Asegúrate de la propiedad adecuada y evita ejecutar procesos del servidor web como el mismo usuario que puede modificar los archivos del sitio si tu host admite separación.
5. Desactiva envolturas y funciones PHP peligrosas donde sea posible
   • En php.ini, establece allow_url_fopen = Apagar and allow_url_include = Apagar.
   • Considere deshabilitar funciones riesgosas si no son necesarias: exec, shell_exec, system, passthru, proc_open, popen. Ejemplo:

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

6. Bloquee los parámetros proporcionados por el usuario utilizados para cargas de archivos
   • Si los puntos finales del tema aceptan archivo or plantilla parámetros, agregue reglas temporales del lado del servidor para bloquear o validar esos parámetros hasta que pueda aplicar un parche.

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

1. Reemplace o actualice el tema
   • Verifique si hay una versión oficial parcheada de Welldone que aborde CVE-2026-28118. Cuando esté disponible, pruebe en staging y luego despliegue en producción.
   • Si no existe un parche, considere reemplazar el tema con una alternativa mantenida o crear un hijo personalizado de un tema base mantenido.
2. Audite su sistema de archivos en busca de webshells y archivos sospechosos
   • Escanear wp-content/uploads, directorios de temas y plugins en busca de archivos PHP inesperados, modificaciones recientes o patrones IOC conocidos.
3. Rota credenciales y secretos
   • Rote todas las contraseñas de administrador de WordPress, credenciales de base de datos, claves API y cualquier token que pueda haber sido expuesto.
   • Después de restaurar desde una copia de seguridad, siempre rote las credenciales.
4. Revisar los registros del servidor y de la aplicación
   • Busque en los registros antes y después de la fecha de divulgación signos de explotación. Exporte los registros relevantes a un lugar seguro para forenses si es necesario.
5. Escaneo completo del sitio en busca de malware y verificación de integridad
   • Ejecute escáneres de malware y verificaciones de integridad de archivos para encontrar webshells, puertas traseras y archivos centrales modificados. Compare el código con fuentes conocidas como buenas.
6. Restaure desde copias de seguridad limpias si se confirma la compromisión
   • Si no puede limpiar con confianza un sitio comprometido, restaure desde una copia de seguridad conocida como buena tomada antes de los primeros signos de compromisión. Después de la restauración, aplique endurecimiento y rote las credenciales.

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

• Principio de menor privilegio: Asegúrese de que los usuarios de archivos y bases de datos tengan solo los permisos requeridos.
• Aislar entornos: Utilice credenciales separadas y aislamiento entre staging y producción.
• Monitoreo y alertas continuas: Centralice los registros y agregue alertas para intentos de recorrido de directorios, referencias a wp-config.php, y picos inusuales en errores.
• Escaneo regular de vulnerabilidades y revisiones de código: Escaneos automatizados más revisiones manuales periódicas del código de temas y plugins.
• Copias de seguridad regulares y restauraciones probadas: Copias de seguridad versionadas fuera del sitio y pruebas de restauración regulares.
• Fortalecimiento de WordPress: Mantenga el núcleo, plugins y temas actualizados; elimine componentes no utilizados; desactive editores de archivos; implemente encabezados de seguridad y haga cumplir HTTPS.

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

Adapte estos patrones a su WAF o conjunto de reglas del servidor y pruebe a fondo para evitar falsos positivos. Estos son fragmentos de regex conceptuales para la creación de reglas:

• Bloquear recorrido de directorios: (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)
• Bloquear envolturas de flujo PHP: (php://|data://|expect://|zip://|phar://)
• Bloquear referencias a archivos sensibles: (wp-config\.php|/etc/passwd|/proc/self/environ|\.env|\.htpasswd)
• Bloquear secuencias largas codificadas a menudo utilizadas para ofuscación: (%[0-9A-Fa-f]{2}){6,}

Ejemplo de pseudo-regla (agnóstico a WAF): Si una cadena de consulta de solicitud coincide con cualquiera de:

• (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c) OR
• (php://|data://|expect://) OR
• (wp-config\.php|/etc/passwd|\.env)

Luego bloquee la solicitud (HTTP 403) y registre los detalles. Aplique reglas de alcance a los puntos finales probables para reducir los falsos positivos.

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

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 las claves API y los tokens que pueden haber sido almacenados en el servidor.
5. Escanee y elimine archivos maliciosos y webshells; si no está seguro, restaure desde una copia de seguridad limpia.
6. Verifique la integridad de la base de datos y elimine usuarios administradores no autorizados o contenido inyectado.
7. Realice una auditoría completa para determinar la ruta del ataque y cualquier movimiento lateral.
8. Reconstruya el entorno a partir de fuentes conocidas y buenas si es necesario; no confíe únicamente en “limpiar” si pueden persistir puertas traseras.

Nota técnica para desarrolladores y administradores de sistemas

Esta clase de vulnerabilidad generalmente proviene de la concatenación insegura de la entrada del usuario en rutas del sistema de archivos. Siga estas prácticas seguras:

• Nunca use la entrada del usuario sin procesar para construir nombres de archivos sin permitir valores en una lista blanca.
• Use mapeos: asocie claves cortas a nombres de archivos permitidos en lugar de aceptar rutas completas.
• 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 presente en su base de código.

Ejemplo de patrón seguro (pseudo-código):

$allowed_templates = ['home', 'archive', 'single'];

Fragmentos prácticos del servidor (resumen)

Pruebe estos en un host de staging antes de implementar en producción:

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

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

Regla de Nginx para bloquear intentos de envoltura php (conceptual):

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

Dureza de PHP ini (ejemplo):

allow_url_fopen = Off

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

1. Inventario: Identificar todos los sitios que ejecutan el tema Welldone ≤ 2.4.
2. Aplicar al menos una mitigación inmediata:
   • Desactivar o renombrar la carpeta del tema, o
   • Bloquear patrones de explotación a nivel de servidor, y
   • Asegurar wp-config.php acceso.
3. Habilitar escaneo y monitoreo continuo para indicadores descritos anteriormente.
4. Si hospeda clientes, informe a las partes interesadas y aplique mitigaciones en los inquilinos afectados de inmediato.

¿Necesita asistencia profesional?

Si gestiona muchas instalaciones de WordPress o carece de capacidad interna de respuesta a incidentes, contrate a un proveedor de respuesta a incidentes de buena reputación o al equipo de seguridad de su proveedor de hosting. Priorice la contención, la captura de registros y la forense antes de cualquier limpieza agresiva que pueda destruir evidencia.