El 20 de octubre, un martes cualquiera, empezaron a circular por redes los detalles de dos fallos críticos en PHP. No en un plugin ni en un tema, sino en el propio PHP, el lenguaje sobre el que funciona WordPress y buena parte de las webs que hay ahora mismo en internet. Se les acabó llamando PHP2Shell y, al día siguiente, ya había ataques mientras el equipo de PHP terminaba de publicar las versiones corregidas.
Si tienes una web, es muy probable que esto te haya pasado por encima sin enterarte. Y la verdad es que no es un caso aislado. Cada vez aparecen más vulnerabilidades, cada vez se explotan más rápido y la inteligencia artificial tiene bastante que ver en las dos cosas.
En este artículo quiero explicar por qué está pasando, qué papel juega la IA (para bien y para mal) y, sobre todo, qué se puede hacer para que tu web no acabe siendo una de las afectadas.
Tabla de Contenidos
Por qué cada vez hay más vulnerabilidades
Los números son bastante claros. En 2025 se publicaron 48.185 vulnerabilidades con identificador CVE, frente a las 39.962 de 2024. Un 20,6 % más en un solo año, que viene a ser una media de unas 132 nuevas cada día (análisis de Jerry Gamblin). Y para 2026, FIRST (la organización que coordina a los equipos de respuesta a incidentes de medio mundo) prevé que se superen las 59.000 (Infosecurity Magazine).
Si nos vamos al mundo WordPress, que es el que más me toca, la tendencia es todavía más fuerte. Según el informe anual de Patchstack, en 2025 se descubrieron 11.334 vulnerabilidades nuevas en el ecosistema, un 42 % más que el año anterior. El 91 % estaban en plugins y el 9 % en temas. En el núcleo de WordPress solo aparecieron seis, y todas de prioridad baja.
¿Por qué pasa esto? No hay una única causa, pero creo que se puede resumir en unas cuantas.
Hay muchísimo más software. Cada web, cada app y cada servicio que usamos está hecho de capas y capas de código. Una web con WordPress tiene el núcleo, el tema, quince o veinte plugins, PHP, el servidor web, la base de datos… Cada pieza tiene sus propios fallos, y cuantas más piezas, más superficie de ataque.
Mucho código es antiguo. PHP2Shell es un buen ejemplo. Según Wiz Research, todas las versiones de PHP desde la 5.4 (que salió en 2012) están afectadas por al menos uno de los dos fallos (Patchstack). Es decir, el problema llevaba ahí más de una década sin que nadie lo hubiera encontrado o, por lo menos, sin que nadie lo hubiera contado.
Dependemos de terceros que no controlamos. Cuando instalas un plugin no solo confías en ese plugin, también confías en la empresa que lo desarrolla, en sus servidores y en cómo guarda sus claves. Este mes de octubre hemos tenido dos ejemplos muy claros (los cuento más abajo).
Hay más gente buscando, y con mejores herramientas. Y aquí es donde entra la IA.
Cómo está influyendo la IA
La IA está afectando a la seguridad del software por tres lados a la vez. Y no todos son malos.
1. Encuentra fallos mucho más rápido
Hasta hace poco, encontrar una vulnerabilidad seria en un proyecto grande requería a una persona muy experta revisando código durante días o semanas. Ahora una parte de ese trabajo lo hacen modelos de IA, y lo hacen a una escala que antes no era posible.
El CERT de las instituciones europeas (CERT-EU) publicó en abril un análisis con algunos ejemplos que dan una idea de por dónde van los tiros:
- En la competición AIxCC de DARPA, siete equipos con sistemas de IA encontraron 54 vulnerabilidades en 54 millones de líneas de código en cuatro horas, a unos 152 dólares por tarea.
- La empresa AISLE encontró con IA las 12 vulnerabilidades que OpenSSL corrigió en su actualización coordinada de enero de 2026.
- En la prueba CVE-Bench, la tasa de éxito de los mejores agentes de IA explotando vulnerabilidades pasó del 13 % al 90 % en menos de un año.
Esto en sí no es malo. Que se encuentren fallos que llevaban años escondidos es justo lo que queremos. El problema es que esas mismas herramientas están al alcance de cualquiera, incluidos los que no tienen ninguna intención de avisar al desarrollador.
2. Reduce el tiempo entre el aviso y el ataque
Antes, cuando se publicaba un parche, solía haber un margen de días o semanas hasta que aparecían los primeros ataques. Ese margen prácticamente ha desaparecido.
Según el informe M-Trends 2026 de Google, que también recoge CERT-EU, el tiempo medio hasta la explotación de una vulnerabilidad recién publicada es de unos -7 días. Sí, en negativo. Quiere decir que, de media, los ataques empiezan antes de que el fallo se haga público. En 2018 eran 63 días.
En WordPress pasa algo parecido. Patchstack calcula que, en las vulnerabilidades más explotadas de 2025, la mediana hasta el primer ataque fue de cinco horas, y que aproximadamente la mitad de las de alto impacto se explotaron en menos de 24 horas (informe de Patchstack).
Una de las razones es que la IA permite coger un parche, ver qué ha cambiado en el código y deducir qué fallo corrige en muy poco tiempo. En julio, Axios contaba el caso de un atacante que había creado un exploit funcional para un fallo crítico en nueve horas. Mientras tanto, según el mismo artículo, la mediana de tiempo que tardan las empresas en parchear fallos críticos subió a 43 días. Las cuentas no salen.
3. Genera código con fallos
El tercer lado es el que más me preocupa, porque nos toca directamente a los que desarrollamos. Cada vez más webs, apps y plugins se hacen con ayuda de IA, y muchas veces sin que nadie con experiencia revise lo que sale.
Un estudio publicado en arXiv este año (Deng, Fan y Meng) auditó 200 aplicaciones hechas con agentes de IA y desplegadas públicamente. El 91 % tenía al menos una vulnerabilidad. En total encontraron 1.186, y casi dos de cada tres eran críticas o graves. Las más habituales eran las de siempre (control de acceso mal hecho, inyecciones y fallos de autenticación).
No quiero decir con esto que no haya que usar IA para programar. La uso y creo que bien utilizada ahorra muchísimo tiempo. Pero un plugin «hecho en una tarde con IA» que nadie ha revisado es un riesgo, y cada vez hay más ahí fuera.
También ayuda a defenderse
Para ser justos, la IA también se está usando en el otro lado. En junio, WordPress.org anunció Protect The Shire, una iniciativa para revisar con más profundidad los más de 78.000 plugins y temas de su repositorio. Entre otras cosas, cada nueva versión de un plugin puede esperar hasta 24 horas antes de llegar por actualización automática, para dar tiempo a revisar los cambios. En el anuncio dicen que, con la IA, la profundidad de esa revisión es ahora «una cuestión de tiempo y tokens».
Así que no es tanto que la IA haga el software más inseguro, sino que lo acelera todo. Los fallos se encuentran antes, se explotan antes y también se corrigen antes. El que no va a ese ritmo es el que se queda expuesto.
PHP2Shell, paso a paso
Volvamos al caso de la semana pasada, porque reúne casi todo lo que acabo de contar.
Son dos vulnerabilidades, la CVE-2026-109618 y la CVE-2026-109619. Las dos tienen que ver con cómo PHP gestiona la memoria cuando algo falla (un error por falta de memoria en un caso y un error fatal en el otro), y las dos permiten ejecutar código en el servidor sin necesidad de usuario ni contraseña. PHP las calificó como críticas, con una puntuación de 9,2 sobre 10 (Qualys). Las descubrieron investigadores de Calif, que las comunicaron al equipo de PHP para publicarlas de forma coordinada (watchTowr).
La cronología es lo que más llama la atención:
- 20 de octubre. Los detalles se filtran en redes sociales antes de la fecha prevista, que era el 22. El equipo de PHP adelanta la publicación al día siguiente.
- 21 de octubre, por la mañana. Algunos servicios deciden desconectarse por precaución. A las 07:34 UTC varios proveedores de hosting ya avisan a Patchstack de intentos de explotación, y Cloudflare confirma ataques y empieza a desplegar reglas en su cortafuegos (Patchstack).
- 21 de octubre, 13:52 UTC. PHP publica las versiones corregidas, la 8.5.12, la 8.4.27, la 8.3.36 y la 8.2.35.
- 26 de octubre. La agencia de ciberseguridad de Estados Unidos (CISA) añade la CVE-2026-109618 a su catálogo de vulnerabilidades explotadas activamente (watchTowr).
Es decir, hubo ataques varias horas antes de que existiera un parche oficial. Hasta donde he podido mirar, no hay confirmación pública de que se usara IA para descubrir o explotar estos fallos, así que no lo voy a dar por hecho. Pero el patrón (filtración, ataques en horas, parche corriendo detrás) es justo el que describen los informes que he citado antes.
El problema de las versiones antiguas
Aquí viene lo que, creo, afecta a más webs de las que pensamos. Las versiones corregidas son solo las que todavía tienen soporte, de la 8.2 en adelante. Para PHP 7.4, 8.0 y 8.1 no hay versión oficial nueva, solo parches de código que algunas distribuciones y proveedores han aplicado por su cuenta, con más o menos cobertura. Y para PHP 7.3 o anteriores no hay corrección (watchTowr).
Qualys analizó los datos de más de 10.000 de sus clientes y encontró que el 71 % de las instalaciones de PHP que tienen controladas están en ramas sin soporte, de la 5.4 a la 8.1. Y solo 199.000 de 167 millones se parchearon en las primeras 12 horas (Qualys). Ojo, que son instalaciones de paquetes en empresas, no webs, pero da una idea bastante clara de lo que hay.
Además, PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de este año (php.net). Si tu web está en la 8.2 y te has quedado tranquilo porque «esa sí se ha parcheado», te quedan dos meses de margen.
¿Y esto cómo afecta a la web de mi negocio?
Es la pregunta lógica. Si tienes una pequeña empresa con su web en WordPress, puede que pienses que nadie se va a molestar en atacarte. El problema es que la mayoría de estos ataques no van dirigidos a nadie en concreto. Son automáticos, recorren internet buscando webs con una versión vulnerable y atacan todas las que encuentran. Da igual que vendas tornillos o seas un despacho de abogados.
Con PHP2Shell, por ejemplo, Wiz Research demostró la ejecución remota de código contra la imagen más reciente de WordPress en contenedor (Patchstack). El fallo no estaba en WordPress, estaba debajo. Tu WordPress podía estar perfectamente actualizado y aun así la web quedar expuesta si el servidor seguía con un PHP vulnerable.
Y no es solo PHP. Solo en este mes de octubre ha habido dos casos que me parecen especialmente ilustrativos:
- Rank Math SEO PRO. El 17 de octubre se publicó que la versión 3.0.123 de este plugin contenía una puerta trasera. No era un error de programación, sino que alguien había comprometido la infraestructura del propio desarrollador y la actualización oficial venía con código malicioso. Gravedad 9,8 sobre 10 (Patchstack).
- UpdraftPlus y UpdraftCentral. Entre el 18 y el 19 de octubre, alguien con claves válidas del servicio de gestión remota UpdraftCentral instaló plugins con puertas traseras en webs conectadas. El backdoor creaba un usuario que entraba sin pasar por el login, así que ni el doble factor ni los límites de intentos servían de nada. UpdraftPlus tiene más de cuatro millones de instalaciones activas, aunque solo estaban expuestas las webs con una clave activa. Y ojo, porque la casilla para conectarse viene marcada por defecto (Patchstack).
Estos dos casos me parecen importantes porque rompen la idea de que con actualizar ya está. En el primero, actualizar era justo lo que te infectaba. En el segundo, no había ninguna actualización que lo arreglara, había que saber que existía el problema, entrar en la web y borrar unas claves a mano.
A eso hay que sumarle que, según Patchstack, el 46 % de las vulnerabilidades de WordPress de 2025 no tenían parche del desarrollador en el momento de hacerse públicas (informe de Patchstack). Casi la mitad. Así que durante un tiempo no hay nada que actualizar, y hay que protegerse de otra manera.
Cómo protegerse
No existe la web 100 % segura, y desconfía de quien te la prometa. Pero sí se puede reducir muchísimo el riesgo y, sobre todo, reaccionar a tiempo cuando pasa algo. Estas son las medidas que creo que marcan la diferencia.
1. Mantener PHP en una versión con soporte. Es lo primero que revisaría. Si tu web está en PHP 7.4, 8.0 u 8.1, ya no recibe actualizaciones oficiales. Y si está en la 8.2, le quedan dos meses. Lo ideal ahora mismo sería pasar a la 8.3 o, mejor, a la 8.4. Eso sí, antes hay que comprobar que el tema y los plugins son compatibles, porque un cambio de versión hecho a ciegas puede romper la web.
2. Actualizar rápido, pero con cabeza. Con fallos que se explotan en horas, esperar a la revisión mensual ya no vale para las actualizaciones de seguridad. Pero el caso de Rank Math demuestra que tampoco hay que instalar todo lo que llega sin mirar. Lo razonable es tener copias de seguridad antes de cada actualización, priorizar las que corrigen vulnerabilidades y revisar después que la web sigue funcionando.
3. Protegerse mientras no hay parche. Como hemos visto, casi la mitad de las vulnerabilidades de WordPress se hacen públicas sin corrección disponible. Para ese hueco existen los cortafuegos de aplicación (WAF) y los parches virtuales, que bloquean el ataque concreto aunque el plugin siga teniendo el fallo. Con PHP2Shell, por ejemplo, Cloudflare desplegó reglas antes de que existiera la versión corregida.
4. Revisar los plugins que tienes. Menos plugins es menos superficie de ataque. Los que lleven años sin actualizarse o hayan desaparecido del repositorio, fuera. Y conviene prestar especial atención a los que tienen acceso a todo (copias de seguridad, gestión remota, migraciones), que se instalan una vez y se olvidan.
5. Cuidado con el código hecho con IA sin revisar. Si alguien te ha hecho un plugin o una funcionalidad a medida con IA, que una persona con experiencia lo revise antes de ponerlo en producción. Con los datos del estudio que he comentado antes, lo raro sería que no tuviera ningún fallo.
6. Vigilar, no solo prevenir. Hay que asumir que algo puede fallar. Escanear la web periódicamente en busca de malware, revisar si aparecen usuarios administradores que nadie ha creado y tener avisos cuando algo cambia. En el caso de UpdraftCentral, por ejemplo, la señal era justo un usuario nuevo que no debería estar ahí.
7. Tener un plan para cuando pase. Copias de seguridad recientes, guardadas fuera del propio servidor y comprobadas (una copia que no se ha probado a restaurar es una esperanza, no una copia). Y saber qué hacer si la web se infecta, quién lo hace y en cuánto tiempo. No es lo mismo tener la web caída una hora que una semana.
8. Lo básico, que sigue funcionando. Contraseñas fuertes y distintas, doble factor de autenticación para los administradores, cada persona con su propio usuario y solo con los permisos que necesita. No te salva de un PHP2Shell, pero sí de muchos otros ataques mucho más comunes.
Lo que ha cambiado de verdad
Si te fijas, ninguna de estas medidas es nueva. Actualizar, hacer copias, revisar plugins… se lleva diciendo años. Lo que ha cambiado es el ritmo. Antes podías revisar la web una vez al mes y llegabas a tiempo casi siempre. Ahora, entre que un fallo se publica y alguien lo intenta explotar pueden pasar unas pocas horas, a veces ni eso.
Y eso, para alguien que tiene un negocio que atender, es complicado de seguir. No es realista estar pendiente de los avisos de seguridad de PHP, de cada plugin y de cada proveedor, y además saber qué hacer en cada caso. La semana de PHP2Shell, por ejemplo, había que saber que existía, comprobar qué versión de PHP tenía la web, mirar si el hosting había aplicado el parche y, si la versión era antigua, planificar la migración sin romper nada.
Por eso creo que el mantenimiento de una web ya no es un extra. Es parte del coste de tenerla, igual que lo es el dominio o el hosting.
Es justo a lo que me dedico. En el servicio de mantenimiento de WordPress me encargo de mantener actualizados el núcleo y los plugins, de comprobar que nada se rompe y de que la web siga funcionando bien, para que no tengas que estar pendiente de estas cosas y te puedas centrar en tu negocio. Si te ha surgido alguna duda leyendo esto o quieres que le eche un vistazo a tu web, cualquier cosa me dices.
