Qué pasa si no actualizo PHP: la lección de la vulnerabilidad de octubre de 2026

El 21 de octubre de 2026, el equipo de PHP hizo algo que casi nunca hace: publicar una actualización de emergencia fuera de calendario. Dos fallos críticos permitían a un atacante ejecutar código en el servidor sin tener ninguna contraseña. Puntuación de gravedad: 9,2 sobre 10.

Si gestionas una web, probablemente viste el titular y pensaste lo mismo que casi todo el mundo: «¿esto me afecta a mí?». Y justo después: «¿qué pasa si no hago nada?».

Este artículo responde a esas dos preguntas sin tecnicismos, y explica por qué el problema de fondo no es esta vulnerabilidad concreta, sino el hábito de no tocar nada hasta que algo se rompe.

Qué es PHP y por qué tu web depende de él

PHP es el lenguaje con el que está hecho el programa que genera tu web. No es tu web: es lo que hay debajo. Cuando alguien entra en tu página, el servidor ejecuta PHP para montar lo que esa persona ve.

Lo usan WordPress, WooCommerce, PrestaShop, Joomla, Drupal y Magento. Es decir: si tu web es cualquiera de esas cosas, tu web funciona con PHP, aunque tú nunca hayas oído hablar de él.

Y aquí está el detalle importante: PHP no se actualiza solo cuando actualizas WordPress. Son dos cosas distintas. Puedes tener WordPress al día y PHP con seis años de antigüedad.

Qué pasa si no actualizo PHP

No pasa nada. Hasta que pasa. Esa es exactamente la trampa: una web con PHP antiguo funciona con normalidad, carga, vende y nadie nota nada raro. El coste de no actualizar no se ve hasta que se cobra de golpe.

Esto es lo que te juegas:

• Quedas expuesto a fallos ya conocidos y publicados. Cuando se corrige una vulnerabilidad, el fallo se hace público junto con el parche. A partir de ese momento cualquiera sabe dónde está la puerta; el parche solo protege a quien lo instala.
• Los ataques son automáticos, no personales. Nadie elige tu web. Hay programas que recorren internet entero probando el mismo fallo en millones de direcciones. Ser pequeño no te protege: te hace más probable, porque las webs pequeñas son las que no están actualizadas.
• Tu hosting puede bloquearte. Si tu web empieza a enviar spam o a servir contenido fraudulento porque la han comprometido, lo habitual es que el proveedor suspenda la cuenta. Primero te apagan, luego avisan.
• Google te marca. Una web comprometida acaba con el aviso rojo de «sitio engañoso» en los resultados. Recuperar la confianza de Google lleva semanas.
• Dejas de poder actualizar lo demás. Las versiones nuevas de WordPress, de los plugins y de las pasarelas de pago exigen versiones mínimas de PHP. Con PHP antiguo te quedas atascado: no puedes actualizar nada sin actualizar primero el suelo.
• Tu web va más lenta de lo que debería. PHP 8 es notablemente más rápido que PHP 7. Es rendimiento que estás regalando.
• Y hay una parte legal. Si en tu web hay datos de clientes y se filtran por un fallo con parche disponible desde hace meses, la conversación con la Agencia de Protección de Datos es muy distinta a si te pilla un fallo desconocido.

Resumido: no actualizar no es ahorrar trabajo, es aplazarlo con intereses.

Qué versión de PHP usa mi web

Comprobarlo lleva dos minutos y no requiere saber programar. Tres formas, de la más fácil a la menos:

• Desde WordPress. Entra en Herramientas → Salud del sitio → Información y abre el apartado «Servidor». Ahí aparece «Versión de PHP».
• Desde el panel de tu hosting. Casi todos tienen una sección llamada «Versión de PHP», «Selector de PHP» o similar. Es el mismo sitio donde se cambia.
• Preguntando a quien lleva tu web. Si tienes un servicio de mantenimiento contratado, esto deberían saberlo sin mirar.

Lo que te salga, compáralo con la tabla siguiente.

Cronología de PHP: versiones, año y compatibilidad con WordPress

El proyecto PHP mantiene cada versión unos cuatro años: dos de correcciones generales y dos más solo de seguridad. Pasado ese plazo, si aparece un fallo, no se corrige nunca.

WordPress, por su parte, recomienda PHP 8.3 o superior y admite versiones anteriores solo en instalaciones heredadas, advirtiendo expresamente del riesgo de seguridad.

Fíjate en la línea de PHP 8.1: es la trampa de este mes. Muchísimas webs van con 8.1, funcionan perfectamente y su dueño cree que está en PHP 8, que suena moderno. Pero 8.1 murió en diciembre de 2025, así que el parche de octubre no existe para ella. La única salida es subir de versión.

Las grandes brechas de PHP, y cómo se corrigieron

Esta no es la primera vez, y no será la última. El patrón se repite: se descubre el fallo, se publica el parche, y durante los meses siguientes los ataques se ceban con quien no lo instaló.

• 2012 — El fallo de la URL (CVE-2012-1823). En servidores con PHP en modo CGI se podía ejecutar código simplemente añadiendo parámetros a la dirección web. Se corrigió en cuestión de días, pero siguió siendo una de las vías de entrada más explotadas durante años, por las webs que nunca actualizaron.
• 2019 — El fallo de PHP-FPM (CVE-2019-11043). Afectaba al componente que ejecuta PHP en la mayoría de servidores con Nginx y permitía ejecución remota de código. Parcheado en las versiones de octubre de 2019.
• 2021 — El código fuente, manipulado. En marzo de 2021 alguien logró colar dos cambios maliciosos en el repositorio oficial de PHP, disfrazados de corrección de erratas. Insertaban una puerta trasera que se activaba con una cabecera concreta. Se detectó en días y no llegó a ninguna versión publicada, pero obligó al proyecto a mudar su código a GitHub y exigir doble factor a todos los desarrolladores.
• 2024 — El fallo de Windows (CVE-2024-4577). Una variante del fallo de 2012 que afectaba a servidores Windows. Lo relevante es el calendario: el ransomware TellYouThePass empezó a explotarlo dos días después de publicarse el parche. Dos días. Corregido en 8.1.29, 8.2.20 y 8.3.8.

Octubre de 2026: php2shell, la más grave hasta la fecha

Lo de este mes es de otra escala. El 20 de octubre el proyecto PHP avisó de que al día siguiente publicaría una actualización crítica. El 21 llegaron dos vulnerabilidades a la vez, bautizadas como php2shell:

• CVE-2026-109618, ejecución remota de código por corrupción de memoria.
• CVE-2026-109619, ejecución remota de código por estado global residual.

Las dos puntúan 9,2 sobre 10 en la escala CVSS v4.0, y las dos permiten lo mismo: que alguien sin usuario ni contraseña ejecute lo que quiera en tu servidor. A partir de ahí puede robar la base de datos, instalar software para minar criptomonedas, usar tu web para enviar spam o cifrarlo todo y pedirte un rescate.

Por qué es peor que las anteriores:

• Afecta a prácticamente todo. Están implicadas las versiones desde PHP 5.4 hasta la 8.5.11. No es un caso raro de una configuración concreta: es el intérprete de PHP.
• No hace falta ser nadie para explotarlo. Sin autenticación, sin ser cliente, sin ser usuario registrado.
• Ya se está explotando. Investigadores de seguridad reportaron intentos reales en sus sistemas trampa a las pocas horas del anuncio.
• Las mitigaciones temporales no bastan. El propio aviso de PHP lo dice: hay apaños parciales, pero lo único que lo arregla del todo es actualizar.

Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Si tu web va con 8.1 o anterior, no hay parche: hay que migrar a una versión soportada.

Dos días después, el 23 de octubre, PHP publicó un aviso adicional (CVE-2026-115560) que afecta solo a webs con una configuración poco habitual. La recomendación provisional es desactivar el seguimiento de progreso de subida de archivos hasta la próxima actualización.

Cómo actualizar PHP sin romper la web

Este es el miedo real, y es legítimo: cambiar la versión de PHP puede dejar una web en blanco si algún plugin antiguo no es compatible. Por eso tanta gente lo pospone indefinidamente. Pero hay una forma de hacerlo sin sustos:

1. Copia de seguridad completa antes de tocar nada. Archivos y base de datos. Y comprueba que la copia se puede restaurar, no basta con que exista.
2. Actualiza primero WordPress, plugins y plantilla. La incompatibilidad casi nunca viene de PHP: viene de un plugin de hace cuatro años. Si todo está al día, el salto es mucho más seguro.
3. Revisa qué tienes instalado y descarta lo abandonado. Un plugin que no recibe actualizaciones desde 2021 es el candidato número uno a romperse. Y, de paso, a ser la puerta de entrada del próximo problema.
4. Prueba en una copia, no en la web buena. Casi todos los hostings permiten crear un clon de pruebas. Ahí subes la versión de PHP y navegas: portada, formulario de contacto, carrito, proceso de pago, zona de clientes.
5. Sube de versión en versión si vienes de muy atrás. De 7.4 a 8.3 de golpe es pedir problemas. De 7.4 a 8.0, comprobar, y seguir.
6. Hazlo un martes por la mañana, no un viernes por la tarde. Si algo falla, quieres tener el día por delante y a tu proveedor de hosting despierto.

El cambio en sí es un desplegable en el panel del hosting y tarda segundos. Todo el trabajo está en lo de antes y en comprobar lo de después.

Por qué esto no se arregla una vez

Supongamos que actualizas esta semana. Perfecto. ¿Y en marzo, cuando salga el siguiente aviso? ¿Y cuando PHP 8.2 deje de recibir parches el 31 de diciembre de este año?

El problema de fondo no es php2shell. Es que la seguridad de una web no es un estado, es una rutina. Entre el día que se publica un parche y el día que empiezan los ataques masivos pasan, como vimos en 2024, unas 48 horas. Eso no se cubre revisando la web cuando uno se acuerda.

Un mantenimiento web serio cubre justamente ese hueco: alguien vigila los avisos de seguridad, sabe en qué versión está cada web, prueba las actualizaciones en un clon antes de aplicarlas y mantiene copias que de verdad se pueden restaurar. Es el trabajo que no se ve cuando todo va bien, y el único que importa cuando algo va mal.

En nuestro caso lo aplicamos a mantenimiento de WordPress, mantenimiento de WooCommerce y mantenimiento de PrestaShop. Y cuando llega tarde, también sabemos limpiar un WordPress hackeado, aunque esa factura siempre sale más cara que la de haberlo evitado.

Preguntas frecuentes

¿Mi hosting no actualiza PHP por mí?

Normalmente no, o no del todo. El hosting actualiza las versiones que ofrece, pero la versión que usa tu web concreta la eliges tú en el panel y ahí se queda, aunque pasen los años. Algunos proveedores fuerzan el salto cuando una versión muere; muchos se limitan a avisar por correo.

¿Y si mi web es muy antigua y no aguanta PHP 8?

Es una señal, no un impedimento. Significa que estás sosteniendo con alfileres algo que tarde o temprano habrá que rehacer. Lo razonable es ponerle fecha y presupuesto en vez de esperar al día en que no haya elección.

¿Cómo sé si ya me han entrado?

Señales típicas: aparecen archivos o usuarios administradores que nadie creó, la web redirige a sitios raros solo desde el móvil, el hosting avisa de consumo anormal, o Google empieza a mostrar en tus resultados páginas que tú no has escrito. Ante la duda, mejor que lo mire alguien.

¿Actualizar PHP afecta a mi posicionamiento en Google?

Para bien, si se hace con cabeza: las versiones nuevas son más rápidas y la velocidad sí cuenta. Para mal solo si la web se rompe y nadie se da cuenta durante días, que es exactamente lo que evita probar antes en un clon.

¿Cada cuánto hay que revisar todo esto?

Las actualizaciones de plugins y WordPress, cada semana o cada quince días. La versión de PHP, al menos una vez al año y siempre que salga un aviso crítico como el de octubre.

Qué hacer hoy, en orden

Si solo te llevas tres cosas de este artículo: mira qué versión de PHP tiene tu web, si es 8.1 o anterior ponte en marcha esta semana, y si es 8.2, 8.3, 8.4 u 8.5, asegúrate de que tiene instalada la revisión de octubre, porque tener PHP 8.4 no sirve de nada si es la 8.4.26.

¿No sabes por dónde empezar o prefieres que lo miremos nosotros? Cuéntanos cómo es tu web y te decimos en qué versión está y qué habría que hacer. Y si quieres dejar de estar pendiente de estas cosas, para eso está nuestro soporte web y mantenimiento.