Índice de contenidos

1. 1

   Qué ha cambiado: la IA como cazadora de fallos

2. 2

   Menos tiempo entre el aviso y el ataque

3. 3

   El caso de PHP: qué versiones siguen protegidas

4. 4

   Cómo actualizar PHP sin romper tu web

5. 5

   Más allá de PHP: medidas imprescindibles

6. 6

   Preguntas frecuentes

1. Qué ha cambiado: la IA como cazadora de fallos

Buscar vulnerabilidades siempre ha sido un trabajo lento y especializado: leer código, probar entradas extrañas y entender cómo encadenar pequeños errores hasta tomar el control de un sistema. En apenas un año, varios hechos han demostrado que los modelos de IA ya hacen ese trabajo a gran escala:

• Julio de 2025. El agente Big Sleep, de Google, localizó un fallo crítico en SQLite, una de las bases de datos más usadas del mundo, que según Google solo conocían los atacantes y estaban a punto de explotar. Fue la primera vez que un agente de IA ayudó a frustrar un ataque real antes de que ocurriera.
• Noviembre de 2025. Anthropic informó de que había detectado y desarticulado una campaña de ciberespionaje atribuida a un grupo patrocinado por el Estado chino, en la que una IA ejecutó hasta el 90 % de las tareas del ataque: reconocimiento, explotación de fallos, prueba de credenciales y extracción de datos. Los humanos se limitaban a aprobar los pasos decisivos.
• Abril de 2026. Anthropic presentó el Proyecto Glasswing, en el que un modelo que no ha puesto a disposición del público (Claude Mythos Preview) ha encontrado miles de vulnerabilidades graves y desconocidas en sistemas operativos y navegadores. Entre ellas, un fallo de 27 años en OpenBSD y otro de 16 años en FFmpeg. La compañía decidió no publicar el modelo por el riesgo de que se usara para atacar, y lo comparte primero con empresas como Microsoft, Google, Apple o la Linux Foundation para que corrijan sus productos.

Lo relevante para cualquier responsable de una web no son los nombres, sino la tendencia: fallos que llevaban décadas ocultos salen a la luz en semanas, y las mismas capacidades que usan los defensores acaban, antes o después, en manos de los atacantes.

2. Menos tiempo entre el aviso y el ataque

Cada vulnerabilidad que se publica es también un manual para atacar a quien no ha actualizado. Y ese margen se ha estrechado mucho:

• En 2025 se publicaron 11.334 vulnerabilidades nuevas en el ecosistema WordPress, un 42 % más que el año anterior. El 91 % estaba en plugins, según el informe anual de la firma de seguridad Patchstack.
• En los fallos más atacados, el primer intento de explotación llegó en una mediana de 5 horas desde su publicación, y casi la mitad no tenía parche del desarrollador cuando se hizo pública.
• En España, el INCIBE gestionó 122.223 incidentes de ciberseguridad en 2025, un 26 % más que en 2024, y notificó de forma proactiva 237.028 sistemas vulnerables.

La conclusión es incómoda: actualizar «cuando haya tiempo» ya no es una opción. Los parches críticos hay que aplicarlos en horas o pocos días, y el software sin soporte, que ya no recibirá parches, hay que sustituirlo.

3. El caso de PHP: qué versiones siguen protegidas

PHP es el lenguaje con el que funcionan WordPress, Moodle, PrestaShop y buena parte de las webs del mundo. Cada versión recibe dos años de soporte activo (correcciones de errores y de seguridad) y luego dos más solo de seguridad. Después queda sin soporte: si se descubre un fallo, nadie lo corregirá.

WordPress recomienda PHP 8.3, y a partir de WordPress 7.0 la versión mínima admitida es PHP 7.4. Que WordPress «funcione» con una versión no significa que esa versión sea segura: PHP 7.4 lleva años sin parches.

Fechas según el calendario oficial de php.net. Consúltalo antes de planificar, porque pueden ajustarse.

4. Cómo actualizar PHP sin romper tu web

El miedo a que la web deje de funcionar es la razón principal por la que tantas siguen en versiones antiguas. Con un poco de orden, el riesgo es bajo:

1. Averigua qué versión usas. En WordPress, entra en Herramientas > Salud del sitio > Información > Servidor. También aparece en el panel de tu proveedor de alojamiento.
2. Haz una copia de seguridad completa de archivos y base de datos, y comprueba que sabes restaurarla.
3. Actualiza primero WordPress, el tema y los plugins. Las versiones recientes suelen ser compatibles con PHP moderno; las antiguas, no.
4. Elimina los plugins abandonados, los que llevan más de un año sin actualizarse. Son la causa más habitual de incompatibilidades y, además, un riesgo de seguridad.
5. Prueba en una copia de la web (entorno de pruebas o staging), que muchos alojamientos permiten crear con un clic.
6. Cambia la versión de PHP en el panel del alojamiento. Normalmente es un selector en la configuración del dominio o del servidor.
7. Revisa la web a fondo: portada, formularios, carrito de compra, área privada. Consulta el registro de errores de PHP.
8. Ten un plan de vuelta atrás: si algo falla, vuelve a la versión anterior desde el mismo panel mientras corriges el problema, sin dejarlo así indefinidamente.

5. Más allá de PHP: medidas imprescindibles

PHP es solo una pieza. Ante atacantes que automatizan la búsqueda de fallos, estas son las medidas que más reducen el riesgo:

• Actualizaciones automáticas para las versiones menores de WordPress y para los plugins de confianza. Lo que no se automatiza, se olvida.
• Menos es más: cada plugin, tema o extensión instalado es una puerta. Borra lo que no uses, no basta con desactivarlo.
• Un cortafuegos de aplicaciones web (WAF), en el alojamiento o como plugin, que bloquee los ataques conocidos mientras llega el parche.
• Verificación en dos pasos para todos los accesos de administración, del hosting y del correo.
• Mínimos privilegios: cada usuario, con el rol imprescindible; nada de cuentas de administrador compartidas.
• Copias de seguridad automáticas, guardadas fuera del servidor y probadas de vez en cuando.
• El servidor también cuenta: sistema operativo, base de datos y panel de control actualizados, o un alojamiento gestionado que lo haga por ti.
• Avisos de seguridad: suscríbete a los boletines de vulnerabilidades del INCIBE y a los del software que uses.
• Formación del equipo: el robo de credenciales sigue siendo una de las entradas más comunes, y la IA también hace más creíbles los correos fraudulentos.

La IA no es solo una amenaza: las mismas técnicas se usan para revisar código, detectar comportamientos anómalos y priorizar qué parchear primero. La diferencia la marcará quién la aplique antes.

6. Preguntas frecuentes

¿Cómo sé qué versión de PHP usa mi web?

En WordPress, en Herramientas > Salud del sitio > Información > Servidor. En otras aplicaciones, en el panel de tu alojamiento, donde también podrás cambiarla.

¿Qué pasa si sigo con una versión de PHP sin soporte?

La web seguirá funcionando, pero cualquier vulnerabilidad nueva que se descubra en esa versión quedará sin corregir. Con la búsqueda de fallos automatizada por IA, esa ventana de exposición es cada vez más peligrosa. Además, cada vez más plugins dejan de ser compatibles con versiones antiguas.

¿Se puede romper mi web al actualizar PHP?

Puede ocurrir si usas plugins o temas antiguos. Por eso conviene actualizar primero todo lo demás, probar en una copia y tener preparada la vuelta atrás.

¿Mi alojamiento actualiza PHP por mí?

Algunos alojamientos gestionados lo hacen o avisan antes de retirar versiones antiguas, pero muchos dejan la decisión al cliente. Revisa tu panel: que la web funcione no significa que esté en una versión con soporte.

¿Puede la IA ayudarme a proteger mi web?

Sí. Los servicios de seguridad ya la usan para detectar ataques y analizar código. Pero ninguna herramienta sustituye lo básico: actualizar a tiempo, reducir lo instalado y tener copias de seguridad.

Datos revisados en octubre de 2026. Fuentes: calendario de versiones de php.net, anuncio del equipo de WordPress (enero de 2026), balance del INCIBE de 2025, informe anual de Patchstack sobre seguridad en WordPress y comunicados de Google y Anthropic.