Qué hacer el día que se publica una vulnerabilidad de un plugin de WordPress

Casi cada día se publica una nueva vulnerabilidad en un plugin de WordPress. La mayoría no necesitan más que la próxima actualización habitual. Unas pocas requieren actuar hoy: las que se están explotando activamente, las que no necesitan inicio de sesión o las que están en un plugin que usas en decenas de sitios de clientes. Esta guía es una rutina para ese día: cómo decidir rápido si un fallo te afecta, cómo encontrar cada sitio afectado y qué hacer después de actualizar.

Paso 1: decide en cinco minutos si es urgente

Lee el aviso en sí (Patchstack, Wordfence o WPScan), no solo el titular. Cuatro preguntas deciden lo rápido que actúas:

• ¿Se está explotando? Un aviso que dice que se ven ataques reales pasa a lo más alto de tu día.
• ¿Necesita inicio de sesión? Un fallo que puede usar un visitante anónimo es mucho más peligroso que uno que requiere una cuenta de administrador.
• ¿Qué puede hacer un atacante? Subir archivos, ejecutar código o crear cuentas de administrador es peor que un XSS reflejado que necesita un clic.
• ¿En cuántos de tus sitios está instalado? Un sitio es una tarea; cuarenta sitios son un proyecto con fecha límite.

Si la respuesta a las dos primeras preguntas es sí, trátalo como urgente: los sitios afectados hoy, no en la próxima ronda de mantenimiento.

Paso 2: encuentra cada sitio afectado

Necesitas dos datos por sitio: si el plugin está instalado (activo o no) y en qué versión está. Los plugins inactivos también cuentan. El código vulnerable sigue en el servidor y a menudo todavía se puede alcanzar directamente.

Con WP-CLI esto lleva segundos por sitio:

wp plugin list --name=ninja-forms --fields=name,status,version

Sin WP-CLI, mira en Plugins en wp-admin o la versión en el readme.txt del plugin. Apunta el resultado en una sola lista: sitio, instalado sí o no, versión, versión corregida. Esa lista es tu checklist para el resto del día y luego tu prueba para el cliente.

Paso 3: actualiza los sitios afectados, primero los más expuestos

Empieza por los sitios que más importan si los atacan: tiendas online, sitios con muchos formularios o cuentas de usuario y sitios con mucho tráfico. Antes de cada actualización, asegúrate de que existe una copia de seguridad reciente que de verdad puedes restaurar.

Las actualizaciones de seguridad suelen ser pequeñas, pero no siempre. Algunos fabricantes incluyen la corrección en una versión mayor con otros cambios. Si la versión corregida es un gran salto, o el plugin gestiona formularios o el pago, pruébala primero en una copia del sitio cuando puedas y revisa después las páginas clave.

Si no puedes actualizar hoy, por ejemplo porque la corrección aún no ha salido o la actualización rompe algo, reduce el riesgo: desactiva el plugin si el sitio puede pasar un día sin él, o bloquea el endpoint vulnerable en tu cortafuegos si el aviso lo menciona. Cuéntale al cliente qué hiciste y por qué.

Paso 4: prueba lo que hace el plugin

Una actualización que termina bien no es lo mismo que un sitio que funciona. Después de actualizar, prueba aquello para lo que sirve el plugin. Con un plugin de formularios, envía un envío de prueba real y comprueba que llega el correo. Con un plugin de tienda, haz un pedido de prueba hasta el pago. Un formulario que deja de enviar sin avisar puede costarle a un cliente una semana de contactos antes de que alguien lo note.

Paso 5: comprueba si el sitio ya fue atacado

Actualizar cierra el agujero. No elimina nada de lo que un atacante dejó antes. Si el fallo se explotó antes de que aplicaras el parche, revisa en cada sitio afectado:

• cuentas de administrador que no reconoces;
• archivos PHP en la carpeta uploads, que solo debería contener medios;
• archivos modificados recientemente en plugins y temas que no actualizaste;
• tareas programadas desconocidas o redirecciones que no configuraste.

Si encuentras señales de un compromiso, restaura una copia de seguridad anterior al periodo del ataque, actualiza de inmediato y cambia todas las contraseñas y las claves de seguridad en wp-config.php. Solo aplicar el parche no basta.

Paso 6: informa al cliente, brevemente

Los clientes rara vez leen noticias de seguridad, pero sí notan cuando su agencia estuvo atenta. Basta con una nota corta: cuál era el problema, si su sitio estaba afectado o no, qué hiciste y cuándo. Convierte una tarea invisible en valor visible, y también tiene su sitio en tu próximo informe de mantenimiento.

Hazlo más rápido la próxima vez

• Lleva una lista de qué plugins hay en cada sitio, para que el paso 2 lleve minutos.
• Sigue una o dos fuentes de avisos, no diez.
• Asegúrate de que cada sitio tiene una copia de seguridad que ya has restaurado de verdad alguna vez.
• Acuerda de antemano con tus clientes que las actualizaciones de seguridad urgentes se hacen fuera del calendario normal.

Cómo gestiona Verploy las vulnerabilidades de plugins

Verploy muestra las vulnerabilidades conocidas en los plugins y temas de cada sitio conectado, para que veas al instante qué sitios están afectados. Cada actualización se revisa, y las arriesgadas se prueban primero en una copia, incluidos los formularios y el pago. Las copias de seguridad nocturnas vienen con una prueba de restauración, y si un sitio se rompe tras publicarse, Verploy lo revierte. Más sobre monitorización de vulnerabilidades de WordPress.