Extensión de WordPress marcada como vulnerable a pesar de estar actualizada: cómo decidir

Extensión de WordPress marcada como vulnerable: de dónde viene la alerta

El caso se repite todas las semanas en los foros de WordPress.org: una extensión de WordPress marcada como vulnerable cuando ya está instalada la última versión. El mensaje cita un CVE, a veces tres fallos a la vez, y la actualización no cambia nada. Antes de ignorar la alerta o desinstalar la extensión de urgencia, hay que entender cómo se genera.

Un control de vulnerabilidades no lee el código de tu extensión. Compara dos cosas: el nombre y la versión de lo que está instalado, y una lista pública de fallos conocidos, donde cada fallo está vinculado a una extensión y a un rango de versiones afectadas. Cuando ambos coinciden, aparece la alerta.

El principio es sencillo y rápido, pero cada lado de la comparación puede equivocarse. Las causas más frecuentes de una alerta en una versión actualizada son las siguientes.

• La lista es falsa o llega tarde: el fallo se corrigió en la última versión, pero la entrada todavía indica «todas las versiones» o un rango demasiado amplio. Esta es la causa más común de los falsos positivos.
• Dos extensiones tienen el mismo identificador: una extensión o tema vendido fuera del repositorio de WordPress.org puede compartir el nombre de su carpeta con otro y heredar sus fallos.
• La versión leída no es la correcta: algunos productos prémium declaran un número en su cabecera que no coincide con el de su propia pantalla de actualización.
• El resultado es anterior a la actualización: la herramienta todavía no ha vuelto a realizar su comprobación.
• La alerta apunta al elemento equivocado: el fallo afecta a una biblioteca integrada, o al propio WordPress después de una actualización del núcleo, y está vinculado a una extensión.

Falso positivo o fallo sin parche: la diferencia que importa

No todas las alertas sobre una versión actualizada son errores. Un fallo puede hacerse público antes de que el autor haya publicado una corrección. En este caso, la última versión es realmente vulnerable y la alerta es correcta.

Para decidir, abre la ficha del fallo en la base de datos que lo publica, a partir de su referencia CVE o del enlace proporcionado por la alerta. Lee tres informaciones.

Si la ficha indica una versión corregida igual o inferior a la tuya, se trata de un falso positivo. Si no indica ninguna corrección, el fallo está abierto: hay que actuar mientras se espera al autor. Si la ficha sigue sin estar clara, el registro de cambios de la extensión y su foro de soporte suelen resolver la cuestión en una línea.

• Las versiones afectadas: «hasta la 7.5.1 incluida» y «antes de la 7.5.1» no dicen lo mismo.
• La versión corregida, o la mención de que todavía no existe ninguna corrección.
• La fecha de publicación del fallo, para compararla con la fecha de tu versión.

Una alerta en una versión actualizada significa «comprueba», ni «te paniques» ni «ignores».

Qué comprueba el módulo de Seguridad de nexya

nexya reúne las tareas comunes de un sitio de WordPress en un solo panel de administración. Cada tarea es un módulo que se enciende o se apaga desde el centro de control (hub). Un módulo apagado no registra nada: ninguno de sus ganchos (hooks) se ejecuta en el sitio.

El módulo de Seguridad comprueba las extensiones instaladas frente a la lista de fallos conocidos. También configura las cabeceras de seguridad, una política de contenido y un límite de intentos de inicio de sesión fallidos.

Este control se basa, al igual que los demás, en una lista de fallos conocidos. Por lo tanto, también puede transmitir una entrada con información errónea. El método de la sección anterior se aplica tal cual: la ficha del fallo y el número de versión instalado son los que mandan.

Todo lo siguiente es gratuito, en tantos sitios como quieras, excepto lo marcado como Pro. La versión gratuita no contiene el código de las funciones Pro; nexya Pro se entrega a través de Freemius después de la compra y conserva la misma configuración.

• Gratis: la comprobación de las extensiones instaladas con la lista de fallos conocidos, las cabeceras de seguridad, la política de contenido, el límite de conexiones fallidas.
• nexya Pro: una revisión diaria de las vulnerabilidades y una huella de los archivos con opción de deshacer (rollback).
• nexya Pro: una conexión en dos pasos para los roles que elijas.

Descubrir qué ha cambiado y cuándo

Una alerta que aparece justo después de una actualización plantea dos preguntas: ¿ha cambiado realmente la versión y quién ha hecho el cambio? Empieza por el número que se muestra en la lista de extensiones de WordPress y compáralo con el de la ficha del fallo.

El módulo de Registro de actividad (Activity Log) guarda quién ha cambiado qué en el sitio, con el antes y el después. En un sitio gestionado por varias personas, es la forma más rápida de saber qué se ha tocado, quién lo ha hecho y en qué momento, sin tener que preguntar a todo el equipo.

Si los números coinciden con una versión corregida y la alerta persiste, deja que la herramienta vuelva a realizar su comprobación. Un resultado antiguo, calculado antes de la actualización, explica una parte de los mensajes que parecen absurdos.

Cómo verificar una alerta de vulnerabilidad, paso a paso

1. 1

   Activar el módulo de Seguridad

   En el panel de nexya, active el módulo de Seguridad. Este comprobará las extensiones instaladas con la lista de vulnerabilidades conocidas. Si está desactivado, no registrará nada en el sitio.

   
2. 2

   Comparar su versión con la ficha de la vulnerabilidad

   Consulte el número de versión en la lista de extensiones, abra la ficha de la vulnerabilidad y lea las versiones afectadas y la versión corregida. El registro de actividad le indica quién cambió qué y cuándo.

   
3. 3

   Actualizar de forma segura o reportar el falso positivo

   Si existe un parche, actualice detrás de la página de espera del módulo de Mantenimiento: la versión anterior se guarda y se puede restaurar con un solo clic. Si la ficha es incorrecta, repórtelo a la base de datos de vulnerabilidades y al autor.

   

Corregir sin romper el sitio

Lo que sigue depende de lo que diga la ficha. En los tres casos, el objetivo es el mismo: no dejar un fallo real abierto y no estropear un sitio que funciona debido a una alerta sin fundamento.

Una actualización de extensión sigue siendo una intervención en un sitio en producción. El módulo de Mantenimiento guarda la versión anterior de cada extensión y de cada tema justo antes de su actualización, y la vuelve a colocar en su sitio con un solo clic. También ofrece una página de espera para cerrar el sitio mientras dura la intervención.

En nexya Pro, una actualización que rompe el sitio se deshace automáticamente y el administrador recibe un correo electrónico.

• Vulnerabilidad con parche: actualice, verifique el sitio y deje que el control se realice nuevamente.
• Vulnerabilidad sin parche: desactive la extensión si puede prescindir de ella, o busque un reemplazo, y siga el foro del autor.
• Falso positivo: repórtelo a la base de datos de vulnerabilidades y al autor, con su número de versión y la referencia de la corrección, y anótelo para el equipo.

Lo que nexya no hace

El módulo de Seguridad no corrige una lista de vulnerabilidades mantenida por terceros, ni puede garantizar que una entrada pública sea exacta. Su función es avisar; la lectura de la ficha sigue siendo tarea suya.

nexya no cuenta con un análisis antimalware pesado ni limpia un sitio pirateado. Compara las extensiones instaladas con las vulnerabilidades conocidas y, en la versión Pro, controla la huella de los archivos. Las redes multisitio no son compatibles: en una red, el plugin permanece desactivado y lo indica.