El mensaje dice que un plugin en su sitio tiene una vulnerabilidad y debe actualizarse o eliminarse. Puede haber llegado de su proveedor de hosting, de un plugin de seguridad, o de un aviso sentado en su panel de WordPress. No sabe qué tan urgente es, si siquiera es real, o si darle clic a Actualizar romperá su formulario de contacto en medio de una semana ocupada. Una alerta de vulnerabilidad de plugin de WordPress es una razón para revisar una cosa específica, no prueba de que su sitio fue hackeado. Una alerta real de todos modos merece atención el mismo día. Los pasos seguros llegan en un orden fijo, y los primeros toman minutos. Puede trabajarlos usted mismo, y al final sabrá si esto es una actualización de rutina o un trabajo para alguien más.
Puntos clave
Abra WordPress escribiendo su dirección habitual, luego compare el plugin, su versión instalada y la versión corregida contra un aviso con nombre. El Equipo de Seguridad de WordPress dice que nunca le envía un correo pidiéndole instalar un plugin o entregar credenciales de administrador.
Tome un respaldo de archivos y base de datos que sepa que restaura, instale la versión corregida si existe, y desactive el plugin si no hay parche. Pruebe primero en un entorno de prueba un sitio crítico para el negocio.
Un sitio Next.js exportado como estático no tiene plugins que hackear, pero sigue teniendo cuentas, scripts y dependencias que proteger, y migrar es una decisión separada y más grande que responder a una sola alerta.
Averigüe en minutos si la alerta aplica a su sitio
Si la alerta coincide con un aviso real para un plugin y una versión instalados en su sitio, no la ignore, y no le dé clic al enlace del correo. Inicie sesión a través de su panel habitual de WordPress, confirme la versión afectada, asegúrese de tener un respaldo utilizable, y luego instale la actualización corregida del desarrollador, o desactive el plugin si no existe parche. El resto de este artículo cubre cómo hacer bien cada uno de esos pasos.
La alerta suele apuntar a un registro público. Una falla de plugin normalmente se reporta primero en privado: el proyecto WordPress pide a los investigadores reportar hallazgos de plugins al desarrollador y al Equipo de Plugins y mantenerlos confidenciales, para que pueda salir un arreglo antes de que se difundan los detalles. Luego, la falla puede recibir un CVE, un identificador para una vulnerabilidad específica. Un CVE le dice que la falla existe. Si su sitio está expuesto depende de la versión que tenga instalada.
Las bases de datos enfocadas en WordPress conectan cada falla con un plugin, las versiones afectadas, la versión corregida y el arreglo recomendado. WPScan corre una base de datos de vulnerabilidades con API, Wordfence dice que su base de datos Intelligence tiene más de 12,000 registros, y Patchstack mantiene la suya propia. Estos registros son contra lo que compara su alerta.
Una alerta también puede traer una etiqueta de severidad. Esa etiqueta viene de CVSS, un puntaje estándar publicado por FIRST. Bajo la especificación CVSS v3.1, las bandas se ven así:
| Puntaje CVSS | Calificación de severidad |
|---|---|
| 0.1 a 3.9 | Baja |
| 4.0 a 6.9 | Media |
| 7.0 a 8.9 | Alta |
| 9.0 a 10.0 | Crítica |
Una banda describe qué tan grave es la falla técnicamente. No es una predicción de que alguien atacará su sitio, y «Crítica» no prueba que la falla se esté usando en la práctica. Un puntaje Medio tampoco es inofensivo: CISA señala que las vulnerabilidades explotadas conocidas pueden tener puntajes Medios o Bajos, y advierte contra usar solo CVSS para decidir qué arreglar primero. Así que, lea cuatro cosas junto al puntaje: el rango de versiones afectadas, si existe una versión corregida, qué tipo de inicio de sesión necesitaría un atacante, y si la fuente reporta explotación activa.
Mantenga el sitio funcionando arreglando las cosas en el orden correcto
El miedo detrás de esta alerta suele ser dos miedos a la vez: que lo hackeen si espera, y romper el sitio si actúa. El orden de abajo atiende ambos. Va del paso más barato y seguro al que cambia su sitio, y le da una forma de regresar en cada punto. Trabaje los cuatro pasos en secuencia en vez de saltar directo a Actualizar.
1. Confirme la alerta donde normalmente inicia sesión
Escriba la dirección habitual `/wp-admin` de su sitio, o inicie sesión a través de su hosting de la forma normal, en vez de seguir cualquier enlace del mensaje. En Plugins, compare el nombre del plugin, su versión instalada, las versiones afectadas, el CVE o ID del aviso, y la versión corregida contra las notas de lanzamiento del desarrollador o un registro con nombre de una base de datos. Si su versión está fuera del rango afectado, ya tiene su respuesta.
2. Haga un respaldo que en verdad pueda restaurar
La propia guía de WordPress.org es tomar un respaldo actual antes de actualizar plugins, porque pueden pasar problemas durante una actualización. El respaldo necesita tanto los archivos del sitio como la base de datos, y usted debería saber que restaura. Anote también la versión actual del plugin, para saber a qué regresar si algo sale mal.
3. Actualice a la versión corregida, o desactive el plugin
Si existe una versión corregida, instálela. Para un sitio que recibe pagos, reservas o inicios de sesión, pruebe primero la actualización en una copia de prueba, y luego revise sus formularios, pago, inicio de sesión y rastreo después. Si no hay parche, o el aviso le dice que desactive el plugin, desactívelo y averigüe qué función dejó de funcionar. Cuando aplicar el parche no es posible de inmediato, el manual de respuesta federal 2024 de CISA enumera limitar el acceso, aislamiento, cambios de configuración, desactivar servicios, cambios de firewall y monitoreo más cercano. Está escrito para agencias federales, no pequeños negocios, pero las opciones que enumera son una lista útil de verificación.
4. Busque señales de que alguien ya entró
Revise sus usuarios en busca de cuentas de administrador que no reconoce, y revise si hay archivos modificados, redirecciones extrañas y cualquier cosa que el aviso nombre como señal de ataque. Desactivar un plugin lo detiene, pero no prueba que un ataque anterior ya se haya limpiado. Un sitio que ya se ve mal necesita respuesta a incidentes, no solo una actualización.
Distinga un aviso real de un correo de phishing
Algunos correos de vulnerabilidad son el ataque mismo. En diciembre de 2023, WordPress publicó una alerta sobre estafadores que suplantan a su Equipo de Seguridad, y dijo que el equipo nunca le enviará un correo pidiéndole instalar un plugin o tema, o proveer credenciales de administrador. Un correo que lleva el nombre de WordPress y pide alguna de las dos cosas no viene de WordPress.
Por eso el primer paso ocurre en su propio panel. Un aviso genuino puede compararse contra un registro con nombre y contra la versión en su propio panel. Si no puede compararlo, no actúe sobre el mensaje. Nunca instale un archivo ZIP enviado en un correo no solicitado. Trate el mensaje como trataría un aviso de renovación con apariencia oficial que no esperaba: revíselo a través de la cuenta que ya usa, no a través del mensaje.
Si ya le dio clic al enlace, ingresó una contraseña o instaló el archivo, cambie esas credenciales y haga revisar el sitio. Eso convierte un trabajo pequeño en un posible incidente de seguridad, y vale la pena atenderlo antes que cualquier otra cosa en esta lista.
Responda las grandes preguntas con una revisión de quince minutos
Puede averiguar dónde está parado en unos quince minutos, sin tocar nada que pueda romperse.
La revisión de quince minutos de la alerta de plugin
- 1
Minutos 1 a 3, entre con seguridad
Escriba su dirección habitual /wp-admin o use su inicio de sesión normal de hosting. Busque un aviso de actualización en el panel o un aviso del escáner que ya usa.
- 2
Minutos 4 a 8, enumere sus plugins
En Plugins, anote cada plugin activo e inactivo, su versión instalada, cualquier actualización disponible y su última fecha de actualización. Compare el plugin y la versión de la alerta con el aviso con nombre.
- 3
Minutos 9 a 11, revise el respaldo
Encuentre la fecha del último respaldo exitoso, y confirme que incluye tanto la base de datos como los archivos del sitio y que se puede restaurar.
- 4
Minutos 12 a 15, revise la salida
Confirme si existe una versión con parche y si su sitio tiene una copia de prueba para probar.
Si la alerta es real, existe un parche, el sitio es sencillo y su respaldo es bueno, puede que pueda terminar esto usted mismo con una actualización normal del panel. Deténgase y pida ayuda antes de cambiar el sitio en vivo si no hay un respaldo verificado, no hay parche, es un plugin cerrado, hay funciones de pago o inicio de sesión, o cualquier señal de un ataque previo.
Reemplace un plugin cerrado o abandonado sin perder lo que hace
A veces la alerta dice que el plugin fue cerrado en WordPress.org. Según las preguntas frecuentes de desarrolladores de plugins de WordPress, un plugin cerrado ya no se puede descargar ni instalar desde el directorio, y dejan de producirse archivos de actualización. Su copia instalada no desaparece sola, así que puede quedarse en su sitio sin más actualizaciones por venir. Después de 60 días, la página del directorio puede mostrar una razón amplia como Problema de Seguridad, pero WordPress.org no publica los detalles técnicos, como explica su página sobre alertas y avisos de plugins.
El cierre puede significar un problema de seguridad, un asunto de pautas o licencias, una solicitud del autor, o inactividad prolongada. No prueba por sí solo que el plugin sea malicioso o que su sitio haya sido violado. Sí significa que no debería esperar un parche que quizá nunca llegue. El reporte Estado de la seguridad de WordPress en 2025 de Patchstack contó 1,614 plugins y temas eliminados del repositorio de WordPress en 2024 por problemas de seguridad sin corregir.
El arreglo es un reemplazo, hecho en orden. Identifique exactamente qué función de negocio provee el plugin, como un formulario, un calendario de reservas o una galería. Exporte sus datos y configuración si puede. Elija un plugin mantenido activamente que haga el mismo trabajo, pruébelo en un entorno de prueba, y luego elimine el plugin viejo en vez de dejarlo instalado e inactivo. Un fork, donde alguien toma el control del código viejo, es un proyecto de desarrollador, no un paso por defecto para un dueño.
Reciba menos alertas de aquí en adelante
Los plugins son donde vive sobre todo este problema. Patchstack reportó 7,966 vulnerabilidades nuevas en todo el ecosistema de WordPress en 2024, y en sus estadísticas de base de datos de 2024, los plugins representaron el 96%, los temas el 4%, y el núcleo de WordPress apenas el siete. Esas son cifras propias de Patchstack, de sus propios datos, y muestran dónde enfocar su mantenimiento.
Las actualizaciones automáticas ayudan con la velocidad. WordPress 5.5 agregó actualizaciones automáticas por plugin y por tema, y WordPress normalmente revisa dos veces al día. Un hosting o código personalizado puede apagar esos controles, y dependen de que WP-Cron esté corriendo, así que revise que estén realmente activados. Reducen la demora entre un arreglo y que su sitio lo reciba, pero no reemplazan los respaldos ni las pruebas.
El resto es propiedad: mantener actualizados el núcleo, los temas y los plugins que usa, quitar lo que no usa, y darle a cada persona su propio inicio de sesión con solo el acceso que necesita. Ningún regulador fija un plazo universal en horas para que los pequeños negocios actualicen plugins, así que el plazo es el que usted fije. Más plugins significan más partes que mantener, aunque ningún conteo fijo prueba que un sitio sea inseguro.
La tabla de abajo enumera brechas comunes de la práctica, no un estudio clasificado. Ningún conjunto de datos nacional clasifica con qué frecuencia ocurre cada una en pequeños negocios.
| La brecha | El arreglo | Tamaño aproximado del trabajo |
|---|---|---|
| Una actualización disponible no aplicada | Confirmar el respaldo, actualizar, luego probar formularios, pago, inicio de sesión y rastreo | Pequeño, más grande con integraciones personalizadas |
| Plugins sin uso dejados instalados | Confirmar que nada depende de él, exportar cualquier dato, desactivar y eliminar | Pequeño |
| Sin respaldo actual que restaure | Configurar respaldos programados fuera del servidor y probar una restauración | Pequeño a mediano |
| Actuar sobre un correo de phishing | No dar clic; si lo hizo, cambiar credenciales e investigar | Pequeño si no se tocó nada, grande si se usó |
| Actualizar un sitio crítico sin pruebas | Configurar un entorno de prueba, actualizar y probar ahí, luego desplegar | Configuración mediana, pequeño cada vez después |
| Sin parche, o un plugin cerrado | Desactivar o aplicar el arreglo del desarrollador, luego reemplazar y probar | Mediano a grande para tiendas, reservas o formularios |
| Un ataque sospechado | Conservar evidencia, contenerlo, revisar cuentas, archivos y datos, luego recuperar | Grande, trabajo especializado |
Dejar WordPress por un sitio Next.js a la medida: qué gana y qué se queda
Un sitio Next.js exportado como estático no tiene plugins que hackear. No hay mercado de plugins, no hay código PHP de plugin, no hay base de datos y no hay inicio de sesión de administrador de WordPress en el servidor público, así que no hay nada ahí de qué trate este tipo de alerta. Esa es la diferencia real, y por eso surge la pregunta después de una alerta de plugin. Las secciones de abajo cubren qué elimina eso, qué sigue necesitando protección, y qué se cambia a cambio.
Sin plugins, sin base de datos, sin inicio de sesión de administrador en el sitio en vivo
Una exportación estática es un conjunto de páginas terminadas servidas como archivos. Las superficies de ataque que vienen con los plugins de WordPress, una base de datos en vivo y un inicio de sesión de administrador público no están presentes en ese servidor. Eso elimina esos riesgos en particular. No elimina todo el riesgo, y nadie debería prometer que lo hace.
La superficie de ataque que queda
Todavía tiene cuentas que proteger: su registrador de dominio, DNS, hosting, y las cuentas de código fuente y despliegue que publican el sitio. La analítica de terceros, los widgets de chat, los servicios de formularios y otros scripts todavía cargan en sus páginas. El sitio está construido a partir de paquetes npm, que son dependencias con sus propias actualizaciones, y los secretos de construcción todavía necesitan mantenerse en secreto. Si la construcción usa funciones de servidor como manejadores de rutas, puntos finales de API, middleware, autenticación, optimización de imágenes o una base de datos, eso es código de servidor y necesita el mismo cuidado. Next.js publica una lista de verificación de producción, y su documentación de configuración cubre establecer encabezados de respuesta, incluyendo encabezados de seguridad.
Cómo funcionan las actualizaciones sin un botón de Actualizar
En un sitio Next.js a la medida, las actualizaciones pasan por un desarrollador o un proceso de despliegue mantenido en vez de un botón en un panel. Eso normalmente significa alertas automatizadas de dependencias, correr `npm audit` para revisar las dependencias contra vulnerabilidades conocidas, y luego probar la actualización y desplegarla. Alguien todavía tiene que ser dueño de ese trabajo.
¿Es vulnerable Next.js?
Sí, Next.js ha tenido vulnerabilidades publicadas, y una fue grave. CVE-2025-29927 fue una omisión de autorización Crítica de 9.1 en middleware para despliegues de servidor afectados. Se corrigió en las versiones 12.3.5, 13.5.9, 14.2.25 y 15.2.3, como enumera el aviso de seguridad publicado. La autopsia de Vercel sobre la omisión de middleware dice que las exportaciones estáticas no se vieron afectadas, porque el middleware no corre sin un runtime de servidor. Ese es el patrón que hay que recordar: entre menos código de servidor corra un sitio, menos hay para que una falla así alcance, y las dependencias necesitan actualizarse de todos modos.
Qué se pierde
Pierde la edición de WordPress con apuntar y hacer clic y su mercado de plugins. Los cambios de rutina suelen necesitar un desarrollador o un flujo de contenido construido aparte, y un sitio estático puede no reproducir cada función de WordPress sin servicios extra o trabajo personalizado. Una migración tiene sentido cuando quiere deshacerse de la administración y mantenimiento de plugins de WordPress, tiene problemas continuos de plugins o rendimiento, y se siente cómodo con cambios gestionados por un desarrollador, una gama más amplia que solo la seguridad que cubre nuestra comparación de WordPress y un sitio web a la medida. Para la alerta que tiene frente a usted hoy, arreglar y actualizar el sitio de WordPress suele ser el primer movimiento correcto, y una migración es una decisión más grande que tomar por sus propios méritos después.
¿Está listo para manejar una alerta de plugin?
Elija una respuesta para empezar.
1. Una alerta dice que un plugin en su sitio tiene un puntaje CVSS Crítico. ¿Qué le dice eso?
2. Un correo con la marca WordPress le pide instalar un plugin de seguridad desde un enlace. ¿Qué debería hacer?
3. Un plugin que usa fue cerrado en WordPress.org. ¿Cuál es el movimiento correcto?
Preguntas frecuentes sobre la vulnerabilidad de plugin de wordpress
¿Es real una alerta de vulnerabilidad de plugin de WordPress?
Puede serlo. Verifíquela desde su panel normal y un aviso con nombre en una base de datos como WPScan, Wordfence Intelligence o Patchstack, no a través del enlace del correo.
¿Debo actualizar un plugin vulnerable de inmediato?
Por lo general, sí, a la versión corregida listada, una vez que confirme un respaldo actual. Pruebe primero en un entorno de prueba un sitio crítico para el negocio.
¿Qué pasa si no hay parche?
Desactive o restrinja el plugin como diga el aviso, luego planee un reemplazo mantenido y pruébelo antes de quitar el viejo.
¿Qué significa CVSS Crítico?
Es una banda de severidad técnica, de 9.0 a 10.0 bajo CVSS v3.1. No es prueba de que su sitio fue atacado.
¿Desactivar un plugin elimina el riesgo?
Detiene el plugin, pero no prueba que un ataque anterior se haya limpiado. Revise también usuarios, archivos y redirecciones.
¿Puede hackearse un sitio Next.js estático?
Sí, a través de cuentas, dependencias, scripts y cualquier función de servidor, aunque no tiene plugins de WordPress que explotar.
Conclusión
Una alerta de vulnerabilidad de plugin es una señal para revisar, no un veredicto. Confírmela en su propio panel, respalde archivos y base de datos, instale la versión corregida o desactive el plugin, y busque señales de que alguien ya entró. Una etiqueta Crítica le dice qué tan grave es la falla, no que su sitio fue atacado, y un plugin cerrado necesita reemplazo en vez de dejarlo inactivo.
Una vez que sabe qué plugins usa, quién los actualiza y que su respaldo restaura, la siguiente alerta se convierte en una tarea corta en vez de una carrera. Eso se mantiene sin importar si sigue en WordPress o se cambia a algo más después.
Si prefiere no hacer esto solo, Web Leveling puede trabajarlo con usted. Nuestra auditoría de seguridad web enumera los plugins y versiones que usa, verifica que su respaldo restaure y establece quién es dueño de las actualizaciones, empezando con el sitio de WordPress que tiene ahora. Cada sitio que construimos es un sitio Next.js a la medida, así que si también está pensando en dejar WordPress, podemos explicarle qué implicaría ese cambio, sin apresurarlo. Trabajamos con negocios pequeños y medianos en todo el país y en el extranjero. Cuéntenos sobre la alerta que recibió, y le ayudaremos a averiguar qué significa para su sitio.
Términos
Palabras sobre seguridad de plugins en este artículo
Toque un término para ver qué significa.
CVE. Un identificador público para una falla de seguridad específica, como CVE-2025-29927.
CVSS. Un puntaje estándar de 0.1 a 10.0 que califica qué tan grave es técnicamente una falla, de Baja a Crítica.
Aviso. Un anuncio publicado que nombra una falla, las versiones afectadas y la versión corregida.
Sitio de prueba. Una copia privada de su sitio web donde las actualizaciones pueden probarse antes de salir en vivo.
Plugin cerrado. Un plugin eliminado del directorio de WordPress.org, así que no puede instalarse y no recibe actualizaciones.
Exportación estática. Un sitio web construido de antemano en archivos planos, sin base de datos ni inicio de sesión de administrador en el servidor en vivo.
Dependencia. Una pieza de código externo con la que se construye un sitio, y que necesita sus propias actualizaciones.
