Resumen

Se ha divulgado una vulnerabilidad crítica de Inclusión de Archivos Locales (LFI) en el tema de WordPress Learnify que afecta a las versiones ≤ 1.15.0 (CVE-2025-60085). La falla permite a atacantes no autenticados incluir y mostrar archivos locales desde el servidor web. Esta vulnerabilidad tiene una alta severidad (CVSS 8.1) y puede ser explotada ampliamente — exponiendo archivos como wp-config.php, archivos de entorno y otros archivos legibles del lado del servidor. Las consecuencias pueden incluir divulgación de credenciales, compromiso de bases de datos y potencialmente la toma de control total del sitio dependiendo del entorno.

Si su sitio utiliza Learnify, trate esto como urgente. La guía a continuación explica la vulnerabilidad, técnicas de explotación, indicadores de detección, mitigaciones inmediatas y pasos de respuesta a incidentes adaptados para propietarios y administradores de sitios.

¿Qué es la Inclusión de Archivos Locales (LFI)?

La Inclusión de Archivos Locales ocurre cuando la entrada controlada por el usuario determina qué archivo del lado del servidor incluye o lee una aplicación, sin una validación adecuada. En aplicaciones basadas en PHP, esto puede verse así:

• include($_GET['template']);
• require_once($_REQUEST['page']);

Si un atacante controla esa entrada, puede forzar a la aplicación a leer archivos locales arbitrarios. Impactos comunes:

• Divulgación de secretos (credenciales de base de datos, claves API).
• Recolección de información para ataques posteriores.
• Posible Ejecución Remota de Código (RCE) cuando se encadena con otras configuraciones incorrectas o envoltorios vulnerables (por ejemplo, php:// envoltorios).

Por qué este LFI de Learnify es peligroso

Datos clave:

• Impacto: temas de Learnify ≤ 1.15.0.
• CVE: CVE-2025-60085.
• Privilegios requeridos: ninguno (no autenticado).
• CVSS: 8.1 (Alto).
• Al momento de la divulgación: no hay parches garantizados del proveedor disponibles — los propietarios de sitios deben aplicar mitigaciones de inmediato.

Este LFI es de alta prioridad porque es no autenticado, fácilmente escaneado a gran escala, y apunta a archivos que a menudo contienen credenciales (como wp-config.php), y se pueden encadenar para escalar en compromisos más severos.

Detalles técnicos (cómo los atacantes suelen explotar LFI)

Los atacantes siguen pasos comunes al explotar LFI. Comprender el patrón ayuda con la detección y mitigación.

1. Encontrar el punto de entrada
   Busque código de tema que incluya archivos utilizando variables influenciadas por parámetros de solicitud, p. ej.:
   include( $theme_dir . '/' . $_GET['tpl'] );
2. Traversal de ruta
   Las cargas útiles incluyen secuencias de traversal para alcanzar archivos sensibles:
   ../../../../etc/passwd or ../../../../wp-config.php.
3. Usando envoltorios para leer archivos
   Envoltorios como php://filter pueden forzar una salida imprimible:
   ?tpl=php://filter/convert.base64-encode/resource=../../../../wp-config.php.
4. Byte nulo y trucos de codificación
   Older servers might be targeted with null byte (%00) truncation or encoded payloads:
   ?tpl=../../../../wp-config.php%00.
5. Post-explotación
   Las credenciales extraídas pueden usarse para acceder a la base de datos, crear usuarios administradores, instalar puertas traseras o cargar shells PHP si existen áreas escribibles.

La divulgación indica que la lógica de inclusión de Learnify no validó suficientemente las rutas proporcionadas por el usuario, lo que permite los métodos anteriores.

Indicadores y patrones de solicitud maliciosos a buscar

Busque en los registros estos patrones:

• php://filter/convert.base64-encode/resource=
• Repetidos ../ o variantes codificadas como ..%2F..%2F
• Intentos de byte nulo: %00
• Solicitudes a archivos PHP de tema con parámetros de consulta como ?tpl= or ?pagina=
• Cadenas base64 largas en respuestas HTML normales (contenidos de archivos codificados)

Ejemplo de solicitud sospechosa:

GET /wp-content/themes/learnify/somefile.php?template=php://filter/convert.base64-encode/resource=../../../../wp-config.php HTTP/1.1

Si ves este patrón, trátalo como alta prioridad e investiga de inmediato.

Lista de verificación de acción inmediata (primeras horas)

Si tu sitio utiliza Learnify ≤ 1.15.0, realiza estos pasos ahora:

1. Coloca el sitio en modo de mantenimiento o aplica controles de acceso temporales (lista de permitidos de IP) para reducir la exposición.
2. Cambia a un tema limpio (predeterminado de WordPress) o elimina el tema vulnerable de los directorios de cara al público. No dejes el tema vulnerable activo.
3. Si se publica un parche oficial, aplícalo de inmediato. Si no, utiliza las mitigaciones a continuación.
4. Aplica reglas a nivel de servidor para bloquear secuencias de recorrido y php:// intentos de envoltura (parcheo virtual en la capa del servidor web).
5. No cambies las credenciales de la base de datos hasta que tengas copias de seguridad confiables y hayas verificado signos de compromiso; cuando sea seguro, rota las contraseñas y secretos de la base de datos.
6. Rota las claves secretas y sales en wp-config.php después de que hayas remediado y verificado la integridad.
7. Escanea en busca de webshells, archivos sospechosos y marcas de tiempo modificadas.
8. Restaura desde una copia de seguridad limpia verificada si detectas un compromiso.
9. Aumenta la supervisión: habilita verificaciones de integridad de archivos, registros de auditoría y alertas.

Si careces de capacidad interna, contacta a tu proveedor de alojamiento o a un consultor de seguridad de confianza y comparte los indicadores anteriores.

Cómo detectar si su sitio ha sido explotado

Incluso después de eliminar el tema vulnerable o aplicar correcciones, verifique si hay rastros de compromiso:

• Archivos nuevos o modificados bajo wp-content/uploads, wp-content/themes, wp-content/plugins, o ubicaciones inesperadas.
• Nuevos usuarios administradores en WordPress (inspeccione el wp_users tabla).
• Tareas programadas sospechosas o entradas de cron almacenadas en la base de datos.
• Conexiones salientes a IPs desconocidas desde el servidor (verifique los registros del firewall/anfitrión).
• Uso inusual de CPU/IO o picos de tráfico.
• Consultas de base de datos de cuentas no familiares o consultas inesperadas en registros lentos.
• Archivos PHP desconocidos o scripts codificados usando eval, base64_decode, o gzinflate.

Acciones recomendadas: herramientas de integridad de archivos, escaneos de malware e inspección manual de archivos críticos (wp-config.php, .htaccess, puntos de entrada de temas y plugins).

Respuesta a incidentes: manual paso a paso

1. Contener
   • Lleve el sitio fuera de línea o bloquee el tráfico para prevenir más daños.
   • Revocar credenciales y claves API comprometidas.
   • Aislar el servidor de la red si es posible.
2. Preservar Evidencia
   • Hacer copias de seguridad de los registros (servidor web, base de datos, aplicación) y, si es necesario, imágenes de disco.
   • Preservar marcas de tiempo para análisis forense; no sobrescriba los registros.
3. Erradicar
   • Eliminar puertas traseras, shells y scripts maliciosos.
   • Reinstalar el núcleo de WordPress, plugins y temas desde fuentes limpias verificadas.
   • Reconstruir servidores a partir de imágenes limpias si se sospecha de persistencia a nivel de servidor.
4. Recuperar
   • Restaurar desde una copia de seguridad limpia (de antes del compromiso).
   • Aplique parches de seguridad y medidas de endurecimiento.
   • Cambie todas las contraseñas y rote claves y sales.
5. Post-recuperación
   • Fortalezca la supervisión y el registro.
   • Realice un análisis post-mortem para identificar controles fallidos y cerrar las brechas.
   • Actualice los planes de respuesta a incidentes y eduque al equipo.
6. Notificar
   • Notifique a las partes interesadas y a su proveedor de alojamiento. Siga los requisitos de notificación regulatorios o contractuales locales donde sea aplicable.

Recomendaciones de endurecimiento para reducir el riesgo de LFI

1. Principio de menor privilegio
   Asegúrese de que los permisos de archivos y directorios sean mínimos. La mayoría de los archivos de WordPress deben ser legibles por el servidor web pero no escribibles. Solo wp-content/uploads debe ser escribible para cargas.
2. Configuración de PHP
   Deshabilitar permitir_url_incluir, restrinja a través de open_basedir, y desactive funciones innecesarias como exec, shell_exec, si no son requeridas por su entorno.
3. Desactive el editor incorporado
   Agregar a wp-config.php:

   define('DISALLOW_FILE_EDIT', true);

4. Asegure las cargas
   Prevenga la ejecución de archivos PHP en wp-content/uploads con reglas del servidor (ejemplos a continuación).
5. Rotar sales y claves
   Use sales fuertes y únicas y rótelas después de la remediación para invalidar sesiones existentes.
6. Copias de seguridad y pruebas
   Mantenga copias de seguridad regulares y fuera del sitio y pruebe las restauraciones periódicamente.
7. Revisión de código y actualizaciones por etapas
   Revise los temas/plugins de terceros antes de la implementación o restrinja su uso hasta que sean verificados.

Reglas prácticas de WAF y mitigaciones a nivel de servidor

Los bloqueos a nivel de servidor web (parcheo virtual) pueden ganar tiempo cuando un parche oficial no está disponible. Pruebe las reglas en un sistema de staging antes de aplicarlas en producción.

Patrones importantes para detectar y bloquear:

• Cualquier valor de parámetro que contenga php://filter
• Parámetros con múltiples ../ secuencias
• Intentos de byte nulo (%00)
• Solicitudes que intentan incluir wp-config.php, .env, /etc/passwd

Ejemplo de regla estilo ModSecurity/CRS:

# Block common LFI attack signatures
SecRule REQUEST_URI|ARGS|ARGS_NAMES|REQUEST_HEADERS "@rx (?i)((\.\./)|(\.\.\\)|php://filter|php%3A%2F%2Ffilter|%00|/etc/passwd|wp-config.php)" \
    "id:1009001,phase:1,deny,status:403,log,msg:'Potential LFI attempt blocked',severity:2,tag:'LFI',tag:'OWASP_TOP_10_A03'"

Ejemplo de regla Nginx:

if ($request_uri ~* "(php://filter|%00|\.\./){1,}") {
    return 403;
}

Apache .htaccess fragmento para bloquear la ejecución de PHP en cargas:

# Proteger cargas - prevenir la ejecución de PHP

Aplique tales reglas con cuidado: las reglas demasiado amplias pueden romper la funcionalidad legítima. Priorice el staging/testing y la implementación incremental.

Ejemplo de regex de detección y consejos de análisis de registros

Use estos patrones para el escaneo automatizado de registros (sin distinción entre mayúsculas y minúsculas):

(?i)(php%3A%2F%2Ffilter|php://filter|(\.\./){2,}|(\.\.\\){2,}|%00|wp-config\.php|/etc/passwd)

Alerta sobre entradas de registro como:

• GET /wp-content/themes/learnify/… ?…=php://filter/convert.base64-encode/resource=../../../../wp-config.php
• Cualquier solicitud utilizando php:// envolturas
• Respuestas que devuelven contenido codificado en base64 en páginas HTML normales

Realizar escaneos diarios de registros para estas firmas y notificar a los administradores cuando ocurran coincidencias.

Prueba segura para verificar vulnerabilidades (solo para propietarios de sitios)

Realice estas verificaciones solo en sitios que posea o administre. No pruebe sitios de terceros.

1. Utilice una php://filter solicitud no destructiva que apunte a un archivo conocido y inofensivo (por ejemplo, un tema readme).
2. Solicitud de ejemplo:

GET /wp-content/themes/learnify/index.php?tpl=php://filter/convert.base64-encode/resource=inc/readme.html

Si la respuesta incluye una cadena base64 que se decodifica al contenido del archivo, la función de inclusión es vulnerable. Deje de probar y proceda a la mitigación de inmediato.

Árbol de decisiones de remediación

Elija el camino apropiado dependiendo de la disponibilidad de un parche oficial:

• Si existe una versión parcheada: actualice de inmediato, luego verifique la integridad (escaneos de archivos, rotaciones de contraseñas).
• Si no existe un parche: elimine el tema de uso activo, aplique reglas a nivel de servidor para bloquear la explotación y considere reemplazar el tema por una alternativa mantenida.
• Si no se puede eliminar el tema: imponga controles de acceso estrictos (lista blanca de IP), aplique reglas de servidor estrictas y aumente la supervisión y las verificaciones de integridad frecuentes.

Después de la remediación: validar y monitorear

Después de aplicar correcciones:

1. Volver a ejecutar escáneres automáticos de vulnerabilidades y malware.
2. Verificar que no existan cuentas de administrador o tareas programadas inesperadas.
3. Comprobar la actividad de red saliente inesperada.
4. Asegurarse de que las copias de seguridad estén limpias y sean recientes.
5. Mantener un monitoreo elevado durante al menos 30 días después de la remediación.

Preguntas frecuentes (FAQ)

P: ¿Puede LFI llevar a la Ejecución Remota de Código?

R: LFI es principalmente una vulnerabilidad de lectura/inclusión de archivos. RCE es posible si un atacante puede incluir un archivo que controla (por ejemplo, un archivo PHP subido) o encadenar el LFI con otras configuraciones inseguras (directorios escribibles, envolturas peligrosas).

P: Uso un tema hijo de Learnify — ¿me afecta?

R: Posiblemente. Los temas hijos heredan el código del padre. Si la lógica vulnerable existe en el tema padre de Learnify y ese padre es ≤ 1.15.0, es probable que estés afectado. Verifica la versión del tema padre y actúa en consecuencia.

P: He parcheado el tema — ¿todavía necesito rotar credenciales?

R: Sí. Parchear previene nuevas explotaciones pero no elimina ninguna compromiso anterior. Rota las contraseñas de la base de datos, las claves API y las sales si hubo alguna exposición.

P: ¿Cómo puedo ser notificado de vulnerabilidades similares?

R: Suscríbete a avisos de seguridad y listas de correo de buena reputación, habilita alertas automáticas de vulnerabilidades para temas/plugins instalados y mantén el registro y monitoreo activos.

Reflexiones finales desde una perspectiva de seguridad de Hong Kong

Esta divulgación de LFI de Learnify destaca una realidad recurrente: los temas y complementos de terceros pueden introducir debilidades críticas. En el rápido entorno digital de Hong Kong, las prioridades son la velocidad y la exhaustividad: actúe rápidamente para contener la exposición e investigue a fondo para determinar si se accedió a credenciales o sistemas.

Prioridades prácticas: eliminar o aislar rápidamente componentes vulnerables, aplicar mitigaciones a nivel de servidor, verificar la integridad, rotar secretos y mantener el monitoreo. Si gestionas múltiples sitios, trata esta divulgación como un aviso para inventariar las versiones de los temas y hacer cumplir un plan de actualización o reemplazo.

Para organizaciones sin capacidad de seguridad interna, contrata a un consultor de seguridad calificado o a tu equipo de soporte de hosting para ayudar con la contención, la forense y la remediación.

Apéndice A: Lista de verificación rápida (copiar/pegar)

• [ ] Identificar si Learnify ≤ 1.15.0 está instalado.
• [ ] Cambiar a un tema diferente o desactivar Learnify.
• [ ] Aplicar reglas del servidor para bloquear php://filter y los intentos de recorrido de ruta.
• [ ] Escanear en busca de webshells y modificaciones de archivos no autorizadas.
• [ ] Rotar credenciales de la base de datos y sales de WordPress.
• [ ] Restaurar desde una copia de seguridad limpia si se detecta compromiso.
• [ ] Implementar el endurecimiento de permisos de archivos.
• [ ] Habilitar monitoreo de integridad de archivos y alertas.
• [ ] Monitorear registros durante 30 días después de la remediación.

Apéndice B: Recursos y referencias adicionales

• Aviso CVE-2025-60085
• Mejores prácticas de endurecimiento de PHP (open_basedir, deshabilitar funciones peligrosas)
• Manual de seguridad de WordPress y guías de administración
• Guías de ajuste de WAF y pruebas de reglas (probar en staging antes de producción)

Importante: Las acciones anteriores son operativamente sensibles. Si sospecha de un compromiso y carece de las habilidades para seguir el manual de incidentes, busque asistencia de un respondedor de seguridad profesional de confianza o de su proveedor de alojamiento.