| Nombre del complemento | Learnify |
|---|---|
| Tipo de vulnerabilidad | Inclusión de archivos locales |
| Número CVE | CVE-2025-60085 |
| Urgencia | Alto |
| Fecha de publicación de CVE | 2026-04-25 |
| URL de origen | CVE-2025-60085 |
Inclusión Crítica de Archivos Locales en el Tema Learnify (≤ 1.15.0) — Pasos Inmediatos para Propietarios de Sitios de WordPress
2026-04-25 | Equipo de Seguridad WP‑Firewall
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). El problema permite a atacantes no autenticados incluir y mostrar archivos locales desde el servidor web. La vulnerabilidad reportada tiene una alta severidad (CVSS 8.1) y puede ser explotada a gran escala — permitiendo a los atacantes filtrar archivos sensibles como wp-config.php, archivos de entorno, o cualquier archivo legible del lado del servidor. Esto puede llevar a la divulgación de credenciales, compromiso de bases de datos y toma de control total del sitio dependiendo del entorno.
Si utilizas Learnify o sitios que lo usan, lee esta publicación cuidadosamente. Explicamos qué significa la vulnerabilidad, cómo la abusan los atacantes, cómo detectar signos de explotación y el proceso de mitigación y respuesta a incidentes paso a paso que recomendamos. También mostramos reglas prácticas de WAF y orientación para endurecer el servidor para reducir la superficie de ataque de inmediato.
¿Qué es la Inclusión de Archivos Locales (LFI)?
La Inclusión de Archivos Locales (LFI) es una clase de vulnerabilidad en aplicaciones web que ocurre cuando se utiliza entrada controlada por el usuario para seleccionar e incluir archivos en el servidor sin la validación adecuada. En un sitio basado en PHP, por ejemplo, esto podría verse así:
include($_GET['template']);require_once($_REQUEST['page']);
Si un atacante puede controlar la entrada que determina qué archivo se incluye, puede apuntar la aplicación a archivos locales arbitrarios y forzar al servidor a leer y mostrar su contenido. Consecuencias comunes:
- Divulgación de secretos (credenciales de base de datos, claves API).
- Recolección de información para preparar ataques adicionales.
- En entornos que permiten envolturas peligrosas (php://input, php://filter) o donde la inclusión de archivos remotos está habilitada, puede ser posible la ejecución remota de código (RCE).
LFI puede ser explotado utilizando cadenas de recorrido simples (../../../../) y técnicas de envoltura (php://filter) para leer archivos de manera segura en contextos donde la inclusión directa no imprimirá el contenido del archivo.
Por qué este LFI de Learnify es peligroso
Datos clave sobre este incidente:
- Afecta a las versiones del tema Learnify ≤ 1.15.0.
- CVE: CVE-2025-60085.
- Privilegios requeridos: ninguno (no autenticado).
- CVSS: 8.1 (Alto).
- No hay un parche oficial del proveedor disponible en este momento (los propietarios del sitio deben aplicar mitigaciones).
Por qué este LFI en particular es un problema de alta prioridad:
- No autenticado: Un atacante no necesita credenciales para intentar la explotación.
- Fácil de automatizar: Las comprobaciones de LFI se pueden ejecutar mediante escáneres automatizados en miles de sitios.
- Archivos de destino sensibles: WordPress almacena credenciales de base de datos y sales en
wp-config.php, lo que convierte a este archivo en un objetivo principal. - Encadenabilidad: LFI se puede encadenar con otras configuraciones incorrectas (permisos de archivo débiles, directorios de plugins/temas escribibles, envolturas PHP peligrosas) para escalar a RCE o instalación persistente de puerta trasera.
Debido a estos factores, los sitios que ejecutan las versiones vulnerables de Learnify deben actuar de inmediato.
Detalles técnicos (cómo los atacantes suelen explotar LFI)
Si bien el nombre exacto del parámetro vulnerable puede variar entre versiones de temas, el patrón de explotación para LFI sigue pasos comunes. A continuación, explicamos el método general que un atacante utilizaría, para que puedas reconocerlo y defenderte contra él.
- Encontrando el punto de entrada
– El atacante busca archivos de tema que llamenincluir,requerir,file_get_contents, o funciones similares con variables influenciadas por valores GET/POST/cookie.
– Ejemplo de patrón arriesgado:include( $theme_dir . '/' . $_GET['tpl'] ); - Traversal de ruta
– El atacante envía cargas útiles que contienen secuencias de traversal:
–../../../../etc/passwd
–../../../../wp-config.php
– Muchos servidores impiden la lectura de archivos devolviendo errores al incluir archivos binarios. Los atacantes luego utilizan envolturas. - Usando envolturas para leer archivos (técnica común)
–php://filter/convert.base64-encode/resource=path/to/file— aplica un filtro para codificar en base64 un archivo cuando se incluye, haciéndolo imprimible en las respuestas.
– Ejemplo de carga útil:
–?tpl=php://filter/convert.base64-encode/resource=../../../../wp-config.php - Byte nulo y trucos de codificación
– En versiones antiguas de PHP y configuraciones de servidor, los atacantes pueden usar la truncación de byte nulo (%00) para eludir las comprobaciones de sufijos. Muchas versiones modernas mitigan esto, pero sigue siendo una carga útil común en escaneos automatizados:
–?tpl=../../../../wp-config.php - Pasos posteriores a la explotación
– Si se encuentran credenciales de wp-config, el atacante las utiliza para acceder a la base de datos o para crear un usuario administrador, cargar puertas traseras o exfiltrar secretos adicionales.
– Si las cargas de archivos son accesibles y no están saneadas, el atacante puede cargar shells PHP y obtener RCE.
Una divulgación responsable señaló que la lógica de inclusión del tema Learnify no logró sanear adecuadamente las rutas proporcionadas por el usuario, habilitando las técnicas anteriores.
Indicadores de ejemplo y patrones de solicitudes maliciosas a buscar
Verifique los registros de su servidor web y los registros de WAF en busca de solicitudes que contengan estos patrones:
php://filter/convert.base64-encode/resource=....o../repetido (traversal de ruta)%00o intentos codificados con byte nulo- Solicitudes a archivos PHP de temas con cadenas de consulta inusuales como
?tpl=...o?page=...(verifique cualquier parámetro que parezca seleccionar una plantilla) - Cadenas largas en base64 en las respuestas (indica que los contenidos del archivo están codificados y devueltos)
Línea de solicitud sospechosa de muestra:
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 de alta prioridad: aísla e investiga de inmediato.
Lista de verificación de acciones inmediatas (qué hacer en las primeras horas)
Si operas un sitio usando Learnify ≤1.15.0, realiza las siguientes acciones de inmediato:
- Lleva el sitio a modo de mantenimiento (si es factible) o aplica controles de acceso temporales (listas de permitidos de IP) para reducir la exposición.
- 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.
- Si se publica una versión de tema parcheada, aplica la actualización de inmediato. Si aún no existe un parche oficial, procede con las mitigaciones a continuación.
- Establece una regla de WAF (parcheo virtual) para bloquear solicitudes que contengan secuencias de recorrido o usos de envoltura (ver ejemplos de reglas en la sección “Reglas de WAF”).
- Cambia la contraseña de la base de datos de WordPress y cualquier credencial de servicio que pueda estar almacenada en
wp-config.phpy otros archivos de configuración, pero solo después de haber asegurado copias de seguridad y verificaciones de integridad, ya que la compromisión puede persistir. - Rota las claves secretas y las sales en
wp-config.phpdespués de la remediación. - Escanea el sitio en busca de webshells, archivos sospechosos y marcas de tiempo modificadas.
- Restaura desde una copia de seguridad limpia verificada si detectas compromisos.
- Aumenta la supervisión: habilita la monitorización de integridad de archivos, registros de auditoría y alertas.
Si no tienes la capacidad técnica para realizar todos los pasos, contacta a tu proveedor de hosting o a un equipo de seguridad y proporciónales los indicadores que has encontrado.
Cómo detectar si tu sitio ha sido explotado
Incluso si cierras la vulnerabilidad, debes verificar si fue explotada anteriormente.
Comprobar:
- Archivos nuevos o modificados en
wp-content/uploads,wp-content/temas,wp-content/complementos, o en otras ubicaciones inesperadas. - Nuevos usuarios administradores en WordPress (verificar
wp_usuariostabla). - Tareas programadas sospechosas (cron jobs) o entradas de cron no autorizadas en la base de datos.
- Conexiones salientes desde el servidor a IPs desconocidas (verificar registros de firewall/anfitrión).
- Uso inesperado alto de CPU/IO o picos en el tráfico.
- Consultas de base de datos inusuales en registros de consultas lentas o consultas utilizando cuentas no vistas anteriormente.
- Archivos PHP desconocidos o scripts codificados que contienen
evaluar,base64_decode, ogzinflate.
Herramientas recomendadas:
- Comprobaciones de integridad de archivos a nivel de servidor (estilo tripwire).
- Escáneres de seguridad de WordPress (preferir los que proporcionan escaneo a nivel de código y heurísticas).
- Escaneo completo de malware de archivos y contenido de la base de datos.
- Revisión manual de archivos críticos (wp-config, .htaccess, index.php en carpetas de plugins/temas).
Si encuentras evidencia de compromiso, sigue los pasos de respuesta a incidentes en la siguiente sección.
Respuesta a incidentes: manual paso a paso
Si confirmas explotación, procede de la siguiente manera:
- Contener
– Lleva el sitio fuera de línea o bloquea el tráfico para prevenir más daños.
– Revoca credenciales y claves API comprometidas.
– Aísla el servidor de la red si es posible. - Preservar la evidencia
– Haz una copia de seguridad de los registros (servidor web, base de datos, registros de aplicaciones) e imágenes de disco.
– No sobrescribas los registros — preserva las marcas de tiempo para análisis forense. - Erradicar
– Elimina todas las puertas traseras, shells y scripts maliciosos descubiertos.
– Reinstala el núcleo de WordPress, plugins y temas desde fuentes limpias.
– Reconstruye servidores a partir de imágenes si se sospecha persistencia a nivel de servidor. - Recuperar
– Restaurar desde una copia de seguridad limpia (tomada antes del compromiso).
– Aplicar todos los parches de seguridad disponibles y medidas de endurecimiento.
– Cambiar todas las contraseñas y rotar claves y sales. - Post‑Recuperación
– Fortalecer la monitorización y el registro.
– Realizar un análisis post-mortem: ¿cómo ocurrió el compromiso? ¿Qué controles fallaron?
– Educar al equipo y actualizar su plan de respuesta a incidentes. - Notificar
– Notificar a las partes interesadas, proveedor de alojamiento y, si es necesario en su jurisdicción, a clientes o reguladores.
Recomendaciones de endurecimiento para reducir el riesgo de LFI
Incluso después de la mitigación inmediata, adopte estas defensas a largo plazo:
- Principio de mínimo privilegio
– Asegúrese de que los permisos de archivos y directorios sean mínimos. La mayoría de los archivos de WordPress deberían ser legibles por el servidor web pero no escribibles, exceptowp-content/uploadsque necesita acceso de escritura solo para cargas.
– Las cuentas de base de datos utilizadas por WordPress solo deben tener los privilegios necesarios. - Configuración de PHP
– Deshabilitarallow_url_include.
– Deshabilitar envolturas no utilizadas si es posible.
– Usaopen_basedirpara restringir el acceso de PHP a directorios.
– Deshabilitarexec,shell_exec,passthru,sistemasi no es necesario. - Deshabilitar el editor de plugins y temas incorporado
– Agregar awp-config.php:
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);// restringe las instalaciones/actualizaciones de plugins/temas desde WP admin - Cargas seguras
– Prevenir la ejecución directa de archivos PHP enwp-content/uploadsañadiendo reglas del servidor (ver ejemplo de bloque .htaccess/nginx a continuación). - Utilizar sales y claves fuertes y únicas (rotar en la remediación)
– Cambiar las claves invalidará las cookies de autenticación activas — útil después de un incidente. - Copias de seguridad periódicas y restauraciones de prueba
– Mantener copias de seguridad frecuentes fuera del sitio y probar restauraciones regularmente. - Utilizar actualizaciones por etapas y revisión de código
– Para temas/plugins en desarrollo activo, revisar el código de terceros o restringir el uso hasta que se verifique la postura de seguridad.
Reglas prácticas de WAF y mitigaciones a nivel de servidor
El parcheo virtual (WAF) puede comprar tiempo cuando un parche oficial aún no está disponible. A continuación se presentan reglas de ejemplo que puede utilizar en sistemas WAF comunes o como controles a nivel de servidor web. Adapte y pruebe cuidadosamente — reglas incorrectas pueden bloquear tráfico legítimo.
Detección de patrones importantes para bloquear:
- Cualquier valor de parámetro que contenga
php://filter - Cualquier parámetro que contenga múltiples
../secuencias - Intentos de byte nulo
%00 - Intentos de incluir archivos con nombres de archivo sensibles (
wp-config.php,.env,/etc/passwd)
Ejemplo de regla estilo ModSecurity/Core Rule Language (CRS):
# Bloquear firmas de ataque LFI comunes"
Regla basada en la ubicación de Nginx para denegar php://filter o intentos de recorrido:
if ($request_uri ~* "(php://filter||\.\./){1,}") {
Apache .htaccess Fragmento efectivo para bloquear la ejecución de PHP en cargas:
# Proteger cargas - prevenir la ejecución de PHP
Un enfoque más matizado: bloquear solo solicitudes sospechosas, permitir las seguras. Probar reglas en staging antes de aplicarlas en producción.
Cómo ayudamos en WP‑Firewall (firewall gestionado + mitigación)
En WP‑Firewall operamos con una suposición: se descubrirán vulnerabilidades en temas/plugins. La protección más rápida y menos disruptiva es el parcheo virtual a través de un WAF gestionado que bloquea intentos de explotación en tiempo real mientras planificas y aplicas soluciones permanentes.
Protecciones básicas que ofrecemos y recomendamos:
- Reglas de WAF gestionadas actualizadas automáticamente en respuesta a nuevas divulgaciones — bloquear cargas útiles de explotación (php://filter, secuencias de recorrido, intentos de obtener
wp-config.php) antes de que lleguen a PHP. - Escaneo de malware y detección de firmas para detectar webshells y modificaciones sospechosas poco después de un intento de explotación.
- Monitoreo de integridad de archivos y escaneos diarios para detectar cambios inesperados en archivos.
- Alertas de incidentes y soporte para ayudar a clasificar hallazgos e implementar mitigaciones.
- Capacidad de parcheo virtual para que incluso si un tema no tiene un parche oficial, puedas continuar las operaciones mientras se reduce el riesgo.
Recomendamos emparejar el parcheo virtual inmediato con los pasos de endurecimiento del servidor descritos anteriormente, rotar credenciales e implementar monitoreo continuo.
Ejemplo de regex de detección y consejos de análisis de registros
Mantén un ojo en los registros del servidor web e implementa alertas sobre estos patrones:
Regex (sin distinción entre mayúsculas y minúsculas) para detectar posibles sondas LFI:
(?i)(phpfilter|php://filter|(\.\./){2,}|(\.\.\\){2,}||wp-config\.php|/etc/passwd)
Entradas de registro que activan alertas:
- GET /wp-content/themes/learnify/… ?…=php://filter/convert.base64-encode/resource=../../../../wp-config.php
- Cualquier solicitud que use
php://envolturas - Solicitudes que devuelven 200 con cadenas codificadas en base64 — base64 en páginas HTML a menudo es un indicador de lecturas de contenido de archivos.
Configura un trabajo automatizado para escanear registros diariamente en busca de estos patrones y notificar a los administradores.
Ejemplo de prueba segura para verificar vulnerabilidades (solo para propietarios del sitio)
Si eres el propietario del sitio y necesitas probar si tu instalación de Learnify es vulnerable, sigue este procedimiento de verificación seguro y solo de lectura. No intentes explotar los sitios de otras personas.
- Utiliza una solicitud no destructiva
php://filterque simplemente intente codificar en base64 un archivo reconocido (por ejemplo,readme.htmlen el directorio del tema). - Construye una solicitud similar a:
GET /wp-content/themes/learnify/index.php?tpl=php://filter/convert.base64-encode/resource=inc/readme.html
- Si la respuesta contiene una cadena base64 que se decodifica al contenido del archivo, la función en ese tema es vulnerable al uso indebido del patrón de inclusión. Deja de probar y procede a la mitigación.
Importante: Solo prueba en sitios que poseas o administres. No realices pruebas en sitios de terceros.
Árbol de decisiones de remediación: Actualizar vs Mitigación temporal vs Eliminar
- Si hay un tema oficial parcheado disponible: actualiza inmediatamente, luego sigue la lista de verificación de verificación (escaneo de integridad de archivos, rotaciones de contraseñas).
- Si no existe un parche oficial:
- Elimina el tema del uso activo (cambia a un tema predeterminado).
- Aplica reglas de WAF y restricciones del servidor para bloquear intentos de explotación.
- Trabaja con el proveedor del tema para establecer un cronograma o considera reemplazar el tema por una alternativa mantenida.
- Si no puedes eliminar el tema por razones comerciales:
- Coloca el sitio detrás de controles de acceso estrictos (lista blanca de IP) para el acceso de administrador.
- Aplica reglas de WAF estrictas y permite solo funcionalidad mínima.
- Programa monitoreo dedicado y escaneos de integridad frecuentes.
Después de la remediación: validar y monitorear
Después de aplicar las correcciones, valida tu entorno:
- Vuelve a ejecutar escáneres automatizados.
- Verifica que no haya cuentas de administrador inesperadas o tareas programadas presentes.
- Verifica conexiones de red inesperadas o cambios en DNS.
- Revisa las copias de seguridad en busca de indicadores tempranos de compromiso (asegúrate de que las copias de seguridad estén limpias).
- Continúa con un monitoreo intensificado 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 en sí es una vulnerabilidad de inclusión/lectura de archivos. La RCE puede ser posible si el atacante puede incluir un archivo que puede controlar (por ejemplo, un archivo PHP subido) o encadenar el LFI con otras configuraciones incorrectas (directorios escribibles, envolturas peligrosas o complementos maliciosos).
- P: Mi sitio utiliza un tema hijo de Learnify — ¿me afecta?
- R: Posiblemente. Los temas hijos heredan el código central de los temas padres. Si la lógica vulnerable existe en el código del tema padre y el tema padre es Learnify ≤1.15.0, es probable que estés afectado. Verifica la versión del tema padre y aplica mitigaciones.
- P: He parcheado el tema — ¿todavía necesito rotar credenciales?
- R: Sí. Si hay alguna posibilidad de que el sitio haya estado expuesto, rota las claves, contraseñas de base de datos y tokens de API utilizados en el sitio. Parchear previene futuras explotaciones pero no elimina compromisos que ocurrieron anteriormente.
- P: ¿Cómo puedo ser notificado de vulnerabilidades similares en el futuro?
- R: Suscríbete a un feed de seguridad confiable y mantén actualizadas tus firmas de WAF y escáneres de malware. Implementa monitoreo automatizado de vulnerabilidades para temas y complementos instalados.
Comience a proteger su sitio hoy — Plan gratuito disponible
Si deseas una capa de protección inmediata y sencilla mientras realizas los pasos técnicos de remediación anteriores, nuestro nivel gratuito administrado proporciona defensas esenciales para sitios de WordPress. El plan gratuito incluye un firewall administrado con parcheo virtual, un firewall de aplicaciones web (WAF), escaneo de malware, protección de ancho de banda ilimitado y mitigación para los riesgos del OWASP Top 10. Registrarse es simple y rápido: puedes comenzar a bloquear intentos de explotación en minutos.
Aprende más o regístrate para el plan gratuito aquí
Opciones de actualización: también ofrecemos planes de pago asequibles que añaden eliminación automática de malware, listas negras/blancas de IP, informes de seguridad mensuales y servicios administrados avanzados para empresas y agencias. Si estás gestionando múltiples sitios o requieres soporte de remediación activa, nuestros planes de nivel superior proporcionan un enfoque de seguridad completo y administrado.
Reflexiones finales de los expertos en seguridad de WP‑Firewall
Esta divulgación de LFI de Learnify es un recordatorio de que cualquier tema o complemento puede introducir debilidades críticas. Los aspectos más importantes de la respuesta a incidentes como este son la velocidad y la completitud:
- Velocidad para aplicar mitigaciones (parcheo virtual y eliminación temporal).
- Integridad en la investigación (¿el atacante obtuvo algo? ¿qué se accedió?).
- Mejoras a largo plazo (endurecimiento, monitoreo, menor privilegio).
Si necesita un socio que pueda gestionar el parcheo virtual y proporcionar detección y respuesta continua para su flota de WordPress, los servicios gestionados de WP‑Firewall están diseñados para hacer exactamente eso: proteger el tráfico en tiempo real, escanear indicadores post-explotación y ayudarle a recuperarse con una interrupción mínima del negocio.
Si gestiona múltiples sitios de WordPress, ahora es el momento de revisar su inventario de temas, confirmar versiones y aplicar los pasos anteriores. Si necesita ayuda para clasificar indicadores específicos, publicamos guías de remediación detalladas y proporcionamos soporte a los clientes que requieren asistencia acelerada. Manténgase alerta y trate cualquier sondeo LFI como potencialmente serio: los atacantes automatizan estas verificaciones, y un sitio explotable está en verdadero riesgo.
Apéndice A: Lista de verificación rápida (copiar/pegar)
- Identifique si Learnify ≤ 1.15.0 está instalado.
- Cambie a un tema diferente o desactive Learnify.
- Aplique regla(s) de WAF para bloquear intentos de php://filter y de recorrido de ruta.
- Escanee en busca de webshells y modificaciones no autorizadas de archivos.
- Rote las credenciales de la base de datos y las sales de WP.
- Restaure desde una copia de seguridad limpia si se detecta compromiso.
- Implemente el endurecimiento de permisos de archivos.
- Habilita la monitorización de integridad de archivos y alertas.
- Monitoree los registros durante 30 días después de la remediación.
Apéndice B: Recursos y referencias adicionales
- CVE-2025-60085 (referencia de aviso público)
- Mejores prácticas de endurecimiento de PHP
- Manual de seguridad de WordPress (guía para administradores de sitios)
- Guía de ajuste de WAF y pruebas de reglas
(Si desea ayuda para implementar reglas específicas de WAF o realizar un escaneo de vulnerabilidades seguro en su entorno, nuestro equipo de seguridad en WP‑Firewall puede ayudar. Ofrecemos opciones tanto de autoservicio como gestionadas adaptadas a sitios de todos los tamaños.)
Gracias por tomar la seguridad en serio. Si tiene preguntas sobre los pasos anteriores o desea orientación específica para su sitio, comuníquese con el soporte de WP‑Firewall o regístrese en el plan gratuito para obtener protección gestionada inmediata: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
