Vulnerabilidades de PHP: cómo saber si tu web está expuesta y qué versión instalar
Contenido del artículo
PHP es el lenguaje en el que funcionan muchas webs corporativas, tiendas online y gestores de contenido. Cuando aparece un fallo grave en PHP, el problema no está en tu diseño ni en tus textos, está en el motor que ejecuta la web en el servidor. Esta guía explica cómo saber qué versión tienes, qué significa que una rama tenga soporte y qué hacer cuando se publica una alerta como la de octubre de 2026.
Qué versión de PHP debe tener tu web en 2026
Tu web debe usar una rama de PHP que todavía reciba correcciones de seguridad, y dentro de ella la última versión publicada. La página oficial de versiones con soporte de php.net indica qué ramas están vivas y hasta cuándo. A fecha de noviembre de 2026, las ramas con correcciones son la 8.2, la 8.3, la 8.4 y la 8.5, y la 8.2 deja de recibirlas el 31 de diciembre de 2026.
Esto tiene una consecuencia práctica. Si tu web está en PHP 8.2, actualizar a la 8.2.35 te protege hoy, pero en dos meses vuelves a estar fuera de soporte. Lo sensato es planificar ya el salto a la 8.3 o a una rama posterior, probando antes que tu gestor de contenidos, tus plugins y tu tienda funcionan con ella.
Las vulnerabilidades críticas de PHP de octubre de 2026
El 21 de octubre de 2026 el proyecto PHP publicó versiones de seguridad para corregir dos vulnerabilidades críticas que permitían ejecutar código en el servidor sin autenticarse. Así lo recoge el aviso de la portada de php.net, que asigna a cada una una puntuación de 9,2 en CVSS v4.0.
| Identificador | Qué permite | Corregido en |
|---|---|---|
| CVE-2026-109618 | Ejecución remota de código por la gestión de errores de falta de memoria | 8.5.12, 8.4.27, 8.3.36 y 8.2.35 |
| CVE-2026-109619 | Ejecución remota de código por estado que sobrevive entre peticiones | 8.5.12, 8.4.27, 8.3.36 y 8.2.35 |
| CVE-2026-111497 | Escritura fuera de límites en la descompresión Brotli, en las compilaciones de Windows | Recompilaciones de Windows 8.5.12-1, 8.4.27-1, 8.3.36-1 y 8.2.35-1 |
Además, el 23 de octubre php.net publicó un aviso informativo sobre el progreso de subida de sesiones (CVE-2026-115560), que solo afecta a configuraciones poco habituales. Recomienda desactivar session.upload_progress.enabled hasta la siguiente versión de mantenimiento, en la que llegará la corrección completa.
El mismo aviso deja claro que las medidas de mitigación reducen la exposición pero no dejan la instalación segura. La corrección completa pasa por actualizar.
Cómo comprobar qué versión de PHP usa tu web
Hay tres formas sencillas de saberlo, de menos a más técnica:
- Panel del hosting. Casi todos los paneles de alojamiento muestran la versión de PHP de cada dominio y permiten cambiarla. Es el primer sitio donde mirar.
- Gestor de contenidos. WordPress, por ejemplo, muestra la versión de PHP en la sección de salud del sitio. Otros gestores tienen una pantalla de información del sistema parecida.
- Servidor propio. Si la web está en un servidor que administras tú, el comando php -v devuelve la versión instalada. Ojo, en un mismo servidor puede haber varias versiones y la web puede usar otra distinta de la que sale en consola.
Lo que no conviene es dejar a la vista una página de información de PHP en la propia web. Da a cualquiera la versión exacta y la configuración del servidor.
Qué hacer si tu web usa una versión vulnerable
Si tu versión es anterior a las corregidas, actúa en este orden:
- Haz una copia completa de archivos y base de datos antes de tocar nada.
- Actualiza dentro de tu rama a la última versión. Es el cambio con menos riesgo de romper la web.
- Si estás en 8.1 o anterior, no existe versión oficial que corrija estos fallos. Toca migrar a una rama con soporte, probando antes en una copia de la web.
- Revisa el resto de piezas: gestor de contenidos, plugins, temas y librerías. Un PHP al día con un plugin abandonado sigue siendo una puerta abierta.
- Comprueba que la web funciona después: formularios, carrito, pagos y área privada.
Si no puedes actualizar de inmediato, php.net propone medidas temporales, como ajustar límites de memoria y de tamaño de envío. Sirven para ganar tiempo, no como solución. Si el servidor no se puede actualizar en un plazo razonable, sacarlo de internet hasta corregirlo es más seguro que dejarlo expuesto.
Este tipo de alertas encaja dentro de un proceso más amplio. En nuestra guía de gestión de vulnerabilidades explicamos cómo priorizar y en por qué son importantes los parches por qué el tiempo entre aviso y corrección es lo que más cuenta.
Webs con hosting compartido, servidor propio o mantenimiento contratado
Quién tiene que actualizar depende de cómo esté alojada la web:
- Hosting compartido: el proveedor instala las versiones de PHP, pero muchas veces eres tú quien elige qué rama usa tu dominio. Si sigues en una rama antigua, el proveedor no la cambia por ti.
- Servidor virtual o dedicado: la actualización es tuya o de quien te administre el servidor.
- Mantenimiento contratado: pide por escrito qué versión de PHP tiene tu web, cuándo se actualizó por última vez y qué plan hay para el fin de soporte de la 8.2.
Muchas pymes estrenaron web en los últimos años y nadie volvió a revisar el servidor después de la entrega. Una web que no se mantiene envejece aunque no se toque. Si tu web la hicimos nosotros o la quieres renovar, en creación de páginas web tienes cómo trabajamos.
Cómo evitar que te pille la próxima alerta
Las alertas de PHP se repiten varias veces al año. Lo que marca la diferencia es enterarte pronto y tener un procedimiento:
- Inventario de webs y servidores, con la versión de PHP y del gestor de contenidos de cada uno.
- Calendario de fin de soporte, para migrar de rama antes de quedarte sin parches.
- Monitorización del servidor y de la web, que avise si algo cambia o se cae. Lo contamos en monitorización y alertas.
- Revisión periódica de seguridad de lo que está publicado, como parte de una auditoría de ciberseguridad.
- Plan de respuesta por si un fallo llega a explotarse. Tienes más detalle en respuesta ante incidentes.
Preguntas frecuentes
Si usa WordPress, PrestaShop, Joomla, Drupal o Magento, funciona con PHP. En otros casos, el panel del hosting o quien te hizo la web te lo puede confirmar en un minuto.
Dentro de la misma rama el riesgo es bajo. Al cambiar de rama sí pueden fallar plugins o temas antiguos, por eso conviene probar antes en una copia de la web.
Deja de recibir correcciones de seguridad oficiales. Los fallos nuevos que se descubran no se corrigen para esa rama, así que la web queda expuesta de forma permanente.
No. El certificado cifra la conexión entre el visitante y la web, pero no corrige fallos del software que se ejecuta en el servidor.
Suele instalar las versiones nuevas de cada rama, pero la elección de la rama de tu dominio a menudo es tuya. Revisa el panel o pregúntalo por escrito.
Sigue leyendo
- Ciberseguridad
Gestión de vulnerabilidades: tapa los agujeros antes que el atacante
Qué es la gestión de vulnerabilidades: descubrir, priorizar y remediar fallos, escaneo continuo, parches y ventana de exposición. En qué se diferencia de un pentest.
- Ciberseguridad
¿Por qué son tan importantes las actualizaciones y los parches?
Actualizar y aplicar parches cierra vulnerabilidades conocidas y reduce la ventana de exposición. Te explicamos por qué es clave para la seguridad de tu empresa.
- Ciberseguridad
Qué es un SOC y un SIEM, y cuándo los necesita una pyme
Qué es un SOC y un SIEM explicados sin tecnicismos, en qué se diferencian del MDR gestionado y cuándo compensan para una pyme. Guía de 3L Systems.
¿Quieres saber si tu web
está al día?
Revisamos la versión de PHP, el gestor de contenidos y los plugins de tu web y te decimos qué actualizar. Primera consultoría gratuita y sin compromiso.
info@3lsystems.es · Primera consultoría gratuita y sin compromiso


