PHP 8.0 dejó de recibir parches de seguridad el 26 de noviembre de 2023 y su última versión fue la 8.0.30. Toda falla descubierta desde entonces, PHP2Shell incluida, queda abierta en esos servidores, y la salida es pasar a PHP 8.3 o superior.
Muchas empresas lo descubren por casualidad: un aviso del hosting, una auditoría o una cabecera del servidor que dice «X-Powered-By: PHP/8.0.30». En DCisGlobal vemos que ese hallazgo trae siempre las mismas dos preguntas: qué tan grave es y cuánto cuesta salir.
Qué significa ver «PHP/8.0.30» en una cabecera del servidor
Significa que el sistema corre sobre la última versión que publicó la rama 8.0. No existe una 8.0.31: el proyecto PHP cerró esa rama y no va a publicar más correcciones.
La cabecera aparece porque la directiva expose_php viene activada por defecto y anuncia la versión en cada respuesta. Ocultarla es una buena práctica, pero no corrige nada: el código sin parchear sigue en el servidor.
Para el negocio, la lectura es simple. Cualquiera que mire esa cabecera sabe que el sistema no recibe arreglos. Es como dejar en la puerta un cartel con el modelo de la cerradura y la aclaración de que el fabricante ya no la repara.
Qué vulnerabilidades tiene PHP 8.0.30 hoy
La 8.0.30 fue una versión de seguridad y cerró las fallas conocidas hasta ese momento. El problema es todo lo que vino después. Desde el 26/11/2023, el equipo de PHP corrige solo las ramas con soporte, y cada falla nueva que también afecta a 8.0 queda sin arreglo oficial.
El caso más reciente es PHP2Shell. El 21 de octubre de 2026, PHP publicó la corrección de dos fallas críticas solo para las ramas con soporte: las versiones mínimas seguras son 8.2.35, 8.3.36, 8.4.27 y 8.5.12. PHP 8.0 no recibe esa corrección. El contexto está en qué es PHP2Shell y qué hacer.
No hace falta entrar en detalles técnicos para medir el riesgo. Una versión sin soporte acumula fallas públicas que nadie va a cerrar, y el propio sitio de PHP advierte que quien la usa puede quedar expuesto a vulnerabilidades sin parchear.
¿Alcanza con un parche del hosting?
Algunos proveedores y distribuciones mantienen versiones viejas por su cuenta, con correcciones propias. Puede servir como puente, pero tiene dos límites:
- No es la corrección oficial de PHP, y su alcance depende de cada proveedor.
- No resuelve el resto del sistema: librerías, frameworks y plugins van dejando de publicar versiones compatibles con 8.0, y el sistema queda atado a dependencias viejas.
Nuestra recomendación es usarlo solo para ganar tiempo mientras se planifica la actualización, nunca como estado final.
A qué versión conviene pasar
| Versión | Soporte de seguridad | Lectura para el negocio |
|---|---|---|
| 8.0 | Terminó el 26/11/2023 | Sin parches ni corrección para PHP2Shell |
| 8.1 | Terminó el 31/12/2025 | Sin parches, igual que 8.0 |
| 8.2 | Hasta el 31/12/2026 | Vence en poco más de dos meses |
| 8.3 | Hasta el 31/12/2027 | Con soporte: destino mínimo razonable |
| 8.4 | Hasta el 31/12/2028 | Con soporte: más margen |
| 8.5 | Hasta el 31/12/2029 | Con soporte: la rama más nueva |
¿Tu versión de PHP es segura?
Escribí la versión exacta que corre tu servidor y te decimos al instante si está expuesta y qué hacer.
Pasar a 8.2 hoy sería mudarse a una oficina con un contrato que vence en diciembre. Por eso recomendamos 8.3 como mínimo y, si el sistema lo permite, 8.4 o 8.5.
La buena noticia es que el salto de 8.0 a 8.3 es mucho más corto que desde 7.4. Los cambios grandes del lenguaje llegaron con 8.0 y ya están resueltos. Lo que queda son funciones marcadas como obsoletas en 8.1 y 8.2 y ajustes menores, documentados en las guías de migración de php.net.
Si hay sistemas todavía más viejos en la empresa, la nota sobre PHP 7.4: fin de soporte y cómo actualizar cubre ese caso; para 8.1, está PHP 8.1 fin de soporte: por qué pasar a PHP 8.3.
Qué hacer ahora
- Confirmar la versión real. La cabecera puede venir de otro servidor o de una configuración vieja. Lo confirma el panel del hosting o quien administra el equipo.
- Inventariar qué corre sobre ese PHP. Sitio, tienda, CRM, integraciones y tareas programadas. Muchas veces hay más de un sistema en el mismo servidor.
- Revisar la compatibilidad. Framework, CMS y plugins: qué versión de PHP admite cada uno y cuáles hay que actualizar primero.
- Probar en una copia. Montar el sistema con PHP 8.3 o superior en un entorno de pruebas y recorrer los procesos críticos: ventas, facturación, altas de clientes.
- Migrar con plan de vuelta atrás. Copia de seguridad, ventana de cambio acordada y una forma clara de volver si algo falla.
- Dejar de anunciar la versión. Con el sistema ya actualizado, desactivar expose_php.
El proceso completo está en la guía cómo actualizar PHP en sistemas sin soporte.
Cómo lo resolvemos en DCisGlobal
Empezamos con un diagnóstico tecnológico: versión, dependencias, código propio y riesgos. Con eso entregamos un plan por etapas, con costo y orden de los cambios, antes de tocar producción.
Después hacemos la migración en un entorno de pruebas, la validamos con tu equipo y pasamos a producción con respaldo. Si el código no da para más, lo decimos y proponemos alternativas.
