TL;DR: En 2025, los riesgos de seguridad más aterradores para los sitios web no provienen del núcleo de WordPress, sino de plugins vulnerables, temas descuidados y software de servidor sin parches, como OpenSSH y PHP en Ubuntu.
Estas son las 10 vulnerabilidades más impactantes en lo que va de año, incluyendo cómo funcionaban y qué lecciones deben aprender los propietarios y desarrolladores de sitios web. En resumen: las actualizaciones constantes, la gestión cuidadosa de las funciones y la atención a los avisos de seguridad son lo que evita que tus historias de alojamiento web se conviertan en historias de terror.
Siempre empieza de la misma manera.
Una llamada nocturna. Un cliente en pánico. Un sitio de WordPress que ayer funcionaba bien, pero que ahora muestra registros de errores y redirige a los visitantes a un dominio de farmacia sospechoso. En tu mente, lo único que oyes son los violines chirriantes de una banda sonora de terror.
La mayoría de las historias de hosting que dan miedo no están causadas por los fantasmas y monstruos de la famosa temporada de Halloween. Provienen de vulnerabilidades que han permanecido sin parchear durante demasiado tiempo. En 2025, el verdadero peligro no ha sido el núcleo de WordPress (que solo ha tenido un problema notable en lo que va de año), sino los plugins, temas y software de servidor que alimentan tu sitio.
Por eso estamos aquí, con una linterna en la mano, para guiarte a través de las 10 vulnerabilidades principales que han hecho temblar a los desarrolladores este año. No se trata de historias con moraleja destinadas a asustarte y alejarte de la web. Son notas de campo desde la primera línea, lecciones que puedes utilizar para evitar que tus historias de alojamiento se conviertan en historias de terror. Vamos a profundizar en ellas.
¿Cómo Se Ve El Panorama de Amenazas 2025 Para Plugins de WordPress y Paquetes de Ubuntu?
Los plugins y los temas son donde reside casi todo el riesgo de WordPress. En 2025, el núcleo de WordPress solo ha tenido una vulnerabilidad importante hasta ahora, pero el ecosistema de plugins y temas ya ha producido cerca de 8000 vulnerabilidades hasta septiembre (cuando escribimos este artículo).
Los informes de mitad de año confirman no solo el gran volumen, sino también la alta explotabilidad en el mundo real. En la primera mitad del año se identificaron 6700 vulnerabilidades, de las cuales el 41 % se clasificó como explotable en ataques reales.
Los avisos de seguridad de Ubuntu (USN) proporcionan actualizaciones periódicas y transparentes sobre los problemas de las versiones compatibles. Muchos de esos USN cubren software crítico que se utiliza habitualmente en entornos de alojamiento (PHP, OpenSSH, bibliotecas como libxml2, etc.). Entre enero y agosto de 2025, Canonical publicó 829 USN que cubrían 7408 CVE únicas en las versiones compatibles. Eso ya supera todo el año 2024, en el que se publicaron 884 USN que abordaban 5611 CVE.
La tendencia es clara: el volumen de vulnerabilidades a nivel del sistema operativo se está acelerando, y a menudo se solapa en riesgo con fugas de plugins y temas.
Entonces, ¿qué pueden aprender los empresarios del panorama de amenazas en 2025? Hay tres cosas principales:
- No pueden confiar en el núcleo para protegerse – El verdadero peligro proviene del código de terceros en los complementos y temas, porque es ahí donde se multiplican las vulnerabilidades.
- La explotabilidad está aumentando – Y no se trata solo de más errores. Una parte cada vez mayor de esos errores se puede utilizar en ataques en este momento.
- Las vulnerabilidades del sistema operativo agravan el riesgo – Incluso si el código de WordPress es sólido, los paquetes de Ubuntu obsoletos o vulnerables pueden ampliar drásticamente la superficie de ataque.
Las 10 Historias Escalofriantes de 2025: Qué Salió Mal (y Qué Podemos Aprender de Ello)
A continuación se muestran las vulnerabilidades reales que han sacudido el ecosistema de plugins de WordPress este año (hasta ahora). Ten en cuenta que no se trata de algo del pasado: muchos sitios siguen expuestos a menos que se aplique el parche correspondiente.
1. Post SMTP
Qué ocurrió: La versión ≤ 3.2.0 del plugin Post SMTP de WordPress tenía un control de acceso defectuoso en uno de sus puntos finales de la API REST (la función get_logs_permission). La función solo comprobaba si un usuario había iniciado sesión, no si tenía privilegios suficientes (por ejemplo, administrador).
Debido a esto, incluso los usuarios con nivel de suscriptor podían obtener registros de correo electrónico, ver el cuerpo de los correos electrónicos e interceptar los correos electrónicos de restablecimiento de contraseña destinados a usuarios con privilegios superiores. ¡Vaya!
Los registros de correo electrónico suelen incluir datos confidenciales. Interceptar los restablecimientos de contraseña significa que un usuario con pocos privilegios podría restablecer la contraseña de un administrador y hacerse con el control del sitio. Eso convierte lo que parece un inofensivo error de plugin en un compromiso total del sitio.
Además, Post SMTP es muy utilizado, con más de 400 000 instalaciones activas. Una gran parte de esos sitios web ejecutaban versiones vulnerables en el momento de la divulgación.
Conclusión clave: Ni siquiera las comprobaciones simples (is_user_logged_in) son suficientes para los datos confidenciales. Las comprobaciones de privilegios deben coincidir con la confidencialidad del punto final.
2. Complementos esenciales para Elementor
Qué ocurrió: Las versiones ≤ 6.0.14 de Complementos esenciales para Elementor tenían una vulnerabilidad de Cross-Site Scripting (XSS) reflejada en el argumento de consulta popup-selector. La entrada no se sanitaba/validaba correctamente antes de incrustarse en la salida de la página. El fallo se corrigió en la versión 6.0.15.
Este complemento tiene más de 2 millones de instalaciones, por lo que una vulnerabilidad como esta tiene un gran alcance potencial. El XSS reflejado puede permitir el phishing, el robo de credenciales, el secuestro de tokens o la desfiguración si un atacante engaña a un usuario para que haga clic en una URL creada ad hoc. La escala de instalaciones activas significa que muchos sitios quedaron expuestos.
Conclusión clave: Complemento popular + vector de entrada simple = riesgo generalizado. Una gran base de instalaciones magnifica incluso las vulnerabilidades “solo XSS”.
3. WPForms Lite
Qué ocurrió: Las versiones de WPForms Lite hasta la 1.9.5 eran vulnerables al Cross-Site Scripting almacenado a través del parámetro start_timestamp. Los usuarios autenticados con rol de colaborador o superior podían inyectar scripts que persistían y se ejecutaban cada vez que un usuario veía una página comprometida.
Dado que el acceso de nivel colaborador se concede a menudo (o se mantiene accidentalmente) en sitios con múltiples autores o miembros del equipo, el riesgo era real. La capacidad de persistencia de la inyección de scripts significa que la vulnerabilidad puede permanecer hasta que se limpie el código o la base de datos del sitio, y no se trata solo de un ataque reflejado puntual.
Aunque la gravedad CVSS es “media” (5.4) para este problema, el XSS persistente es más difícil de detectar, más difícil de eliminar y tiene consecuencias más graves (robo de cookies, escalada de privilegios, pérdida de confianza de los usuarios) de lo que mucha gente cree.
Conclusión clave: El XSS almacenado a través de usuarios con roles inferiores es peligroso. Los permisos son importantes, al igual que garantizar que incluso los usuarios “de confianza” no estén automáticamente seguros.
4. GiveWP
Qué ocurrió: Las versiones de GiveWP anteriores a la 3.19.4 contenían una vulnerabilidad de inyección de objetos PHP. Las entradas que se pasaban a determinadas funciones de deserialización no se validaban, lo que permitía inyectar cargas útiles creadas ad hoc. En algunas configuraciones de PHP, esto podía permitir a los atacantes activar “métodos mágicos” en las clases, lo que daba lugar a la ejecución remota de código (RCE).
GiveWP es uno de los complementos de donaciones más populares, con más de 100 000 instalaciones activas. Los sitios que lo utilizan para recaudar fondos sin ánimo de lucro podrían haber sufrido el secuestro de sus servidores, y no solo de sus pantallas frontales. Esto supone un desastre tanto para la continuidad del negocio como para la confianza.
Conclusión clave: Los complementos complejos, como las plataformas de donaciones, manejan datos confidenciales, lo que los convierte en objetivos principales. Actualízalos siempre rápidamente.
5. Complemento AI Engine
Qué ocurrió: El complemento AI Engine de Meow Apps lanzó una versión que carecía de controles de acceso, lo que permitía a los usuarios con funciones mínimas ampliar sus privilegios. Esto significaba que un atacante que pudiera registrarse como usuario básico podía ascender a administrador.
Las vulnerabilidades de ampliación de privilegios se encuentran entre las más devastadoras, ya que subvierten el modelo de confianza. Un usuario registrado (o, en algunos casos, incluso un bot que creara una nueva cuenta) podía obtener instantáneamente el control de todo el sitio. Dada la amplia adopción de AI Engine para integrar OpenAI y otros servicios de IA, el radio de acción se extendió tanto a los sitios web de marketing como a los de producción.
Conclusión clave: La escalada de privilegios es más peligrosa que el XSS porque entrega a los atacantes las llaves de tu sitio. Las auditorías de roles deben formar parte de todas las rutinas de mantenimiento mensuales.
6. Complemento B Blocks
Qué ocurrió: B Blocks, un complemento de WordPress con decenas de miles de instalaciones, tenía un fallo crítico: la falta de comprobaciones de autorización permitía a los visitantes no autenticados crear nuevas cuentas de administrador. A diferencia de otros errores de escalada de privilegios, este no requería ningún rol de usuario ni inicio de sesión.
Cualquier atacante que conociera el punto final podía crear una nueva cuenta de administrador. Desde allí, podían instalar puertas traseras, exportar la base de datos o inyectar enlaces de spam SEO en todo el sitio. Como no requería acceso previo, este error fue muy explotado poco después de su divulgación.
Conclusión clave: La escalada de privilegios sin autenticación es lo peor que puede pasar. Todos los propietarios de sitios web deben revisar regularmente su lista de usuarios, incluso cuando crean que todo está parcheado.
7. Tema Motors
Qué ocurrió: El tema Motors, muy utilizado en sitios web de concesionarios de automóviles y mercados de automóviles, contenía un fallo de escalada de privilegios. La vulnerabilidad permitía a los atacantes no autenticados aprovechar las comprobaciones débiles del código del tema para obtener privilegios de administrador.
A diferencia de los temas nicho pequeños, Motors es comercial y muy utilizado. Un tema comprometido a esta escala significa que miles de sitios web empresariales que anuncian inventario, pagos y clientes potenciales quedan expuestos de repente. La escalada de privilegios en este caso significa que los atacantes no tenían que ser muy inteligentes, simplemente podían “entrar” y promocionarse a sí mismos.
Conclusión clave: Los temas pueden ser tan peligrosos como los plugins. Si compraste un tema hace años y no lo has actualizado, ese tema puede ser tu eslabón más débil.
8. Base de datos para Contact Form 7 / WPForms / Elementor Forms
Qué ocurrió: El plugin Database for CF7, WPForms, and Elementor Forms tenía una vulnerabilidad crítica de ejecución remota de código / denegación de servicio. Las versiones ≤ 1.4.3 no lograban sanitizar las entradas proporcionadas por los usuarios, lo que permitía a los atacantes inyectar cargas maliciosas a través de los envíos de formularios.
Dado que este plugin es un complemento de tres de los creadores de formularios más populares, la exposición se amplificó. Un atacante podía enviar un formulario “inofensivo”, pero en realidad introducir código en tu servidor, una pesadilla para las agencias que gestionan múltiples sitios de clientes.
Conclusión clave: Incluso los pequeños plugins “auxiliares” pueden derribar toda una pila. Si amplías plugins críticos con complementos, aplícales parches con la misma urgencia que a la herramienta principal.
9. OpenSSH en Ubuntu 24.04
Qué ocurrió: Canonical reveló múltiples vulnerabilidades de OpenSSH en 2025, incluida una falla de omisión de reenvío en la que la directiva DisableForwarding no funcionaba como se esperaba (USN-7457-1). Otro aviso (USN-7270-1) abordaba los posibles riesgos de denegación de servicio en las conexiones de los clientes.
OpenSSH es uno de los paquetes más fundamentales de los servidores Ubuntu. Si el acceso SSH queda expuesto, los atacantes pueden encadenar estos errores para ganar persistencia o interrumpir la disponibilidad. Muchos administradores de sistemas dan por sentado que SSH es seguro por defecto, pero vulnerabilidades como estas demuestran que incluso el núcleo más reforzado necesita vigilancia.
Conclusión clave: No des por sentado que los paquetes críticos son invulnerables. Incluso un software maduro como OpenSSH necesita parches constantes y revisiones de configuración.
10. PHP en Ubuntu
Qué ocurrió: Una vulnerabilidad en el análisis SOAP/XML de PHP permitía que cargas útiles creadas con prefijos de espacio de nombres malformados provocaran bloqueos. Canonical lo incluyó en USN-7648-1, que corrigió el problema en las versiones de Ubuntu compatibles.
Muchos plugins y temas de WordPress dependen de las funciones SOAP/XML de PHP para las integraciones (pasarelas de pago, CRM, automatización de marketing). Un fallo en la capa del intérprete de PHP significa una denegación completa del servicio, y todos los sitios de ese servidor podrían verse afectados.
Conclusión clave: Los fallos del software del servidor son tan peligrosos como los errores de WordPress. Si tu proceso PHP falla, tu sitio web falla con él.
Lo Que Nos Enseñan Estas Historias
En conjunto, estos 10 casos cuentan una historia coherente: las vulnerabilidades más aterradoras en 2025 no han sido exóticos zero-days en el núcleo de WordPress. Han sido las grietas cotidianas en las paredes: plugins obsoletos, temas descuidados y software de servidor sin parches.
Hay tres lecciones que destacan:
- La escalada de privilegios está en todas partes. Desde Post SMTP hasta el complemento AI Engine, los atacantes buscan atajos para obtener derechos de administrador. Una vez que los tienen, todo lo demás es secundario.
Los plugins y los temas son el eslabón más débil. Los complementos populares son los responsables de la mayoría de las vulnerabilidades de WordPress, y su gran número de instalaciones los convierte en objetivos principales.
Los errores a nivel del sistema operativo son tan importantes como los errores de las aplicaciones. Los fallos de OpenSSH y PHP nos recuerdan que mantener actualizados los paquetes de Ubuntu es tan importante como actualizar el propio WordPress.
La conclusión no es que debas temer a tu pila de software, sino respetarla y cuidarla. Cada complemento, tema o paquete de servidor que instalas amplía la superficie de ataque. La diferencia entre una historia aterradora sobre el alojamiento web y un ciclo de parches rutinario es la rapidez con la que detectas y abordas esos riesgos.
La seguridad no tiene por qué ser aterradora. Con actualizaciones constantes, una gestión cuidadosa de las funciones y atención a los avisos, puedes mantener a raya a los monstruos.
