PHP 8.1 fin de vida: riesgos y plan de migración para su empresa

PHP 8.1 llegó a su fin de vida el 31 de diciembre de 2025, y desde el 21 de octubre ese dato dejó de ser un asunto de calendario. Si su sitio, su tienda o su sistema interno siguen en PHP 8.1 o en una versión anterior, no hay una versión oficial que corrija PHP2Shell. Esta guía explica qué riesgo implica, qué puede hacer esta semana y cómo migrar con un plan ordenado.

¿Qué significa que PHP 8.1 esté sin soporte?

Significa que el proyecto PHP ya no publica correcciones de seguridad para esa rama. PHP 8.1 cerró con la versión 8.1.34 y su soporte de seguridad terminó el 31 de diciembre de 2025, según php.net/eol.php.

La rama 8.0 terminó el 26 de noviembre de 2023 y la 7.4, el 28 de noviembre de 2022. Una empresa en esas ramas lleva menos de un año, casi tres o casi cuatro sin correcciones oficiales.

El 21 de octubre de 2026, The PHP Foundation publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para cerrar dos fallas críticas (anuncio de The PHP Foundation). Para 8.1 y anteriores no hay versión equivalente. Datadog informa de backports de código fuente para 7.4, 8.0 y 8.1, pero no son versiones oficiales: los empaqueta y valida cada proveedor, y puede tardar.

¿Qué riesgos concretos tiene seguir así?

El riesgo principal es que cualquier vulnerabilidad nueva, no solo PHP2Shell, quedará sin corrección oficial. La exposición es abierta: crece con cada mes que pasa.

• Vulnerabilidades sin parche oficial. Los parches del 21 de octubre llegan a 8.2 en adelante. Las demás ramas dependen de terceros.
• Auditorías y cumplimiento. Según HeroDevs, los auditores marcan cada vez más los entornos sin soporte en revisiones SOC 2, ISO 27001, PCI DSS y HIPAA. Decir que la migración está «planeada» suele no bastar. HeroDevs vende soporte extendido para PHP 8.1, de modo que conviene leer su postura con ese contexto.
• Plugins y librerías que dejan de ser compatibles. Los frameworks y paquetes abandonan las versiones viejas, y eso bloquea otras actualizaciones de seguridad.
• Una migración más difícil cada trimestre. Cuantos más cambios incompatibles se acumulan, más riesgoso es el salto.

¿Qué hacer esta semana si no puede migrar todavía?

Reduzca la exposición mientras prepara la migración: la mitigación es un puente, no un parche. Si quiere el detalle de la falla, lo explicamos en qué es PHP2Shell y qué hacer hoy.

1. Pida el backport a su proveedor. Exija por escrito si aplicó la corrección para su versión exacta y en qué paquete.
2. Aplique las mitigaciones temporales de Datadog. Para CVE-2026-109618, memory_limit=-1 con límites de tamaño de petición y de memoria del contenedor. Para CVE-2026-109619, session.upload_progress.enabled=0. Después, reinicie todos los workers.
3. Ponga un WAF o proxy inverso delante. Permite limitar el tamaño de las peticiones y filtrar tráfico antes de que llegue a PHP.
4. Aísle lo que no necesita estar en internet. Paneles internos, entornos de prueba y servicios olvidados deben quedar tras una VPN o una lista de IP.
5. Active el monitoreo. Revise los registros de errores fatales y de picos de memoria, y deje alertas sobre procesos extraños.

Si el servidor lo administra otra empresa, el primer correo es para ella. Si lo administra usted, el soporte técnico continuo puede encargarse del monitoreo mientras avanza la migración.

¿Cómo es un plan de migración de PHP en cinco etapas?

Un plan sensato avanza de lo que se sabe a lo que se prueba, y nunca toca producción sin una vía de regreso. Estas son las cinco etapas.

1. Inventario y dependencias. Liste cada aplicación, su versión de PHP, el framework, las extensiones y los plugins. Incluya lo que nadie recuerda: crons, scripts y sitios viejos en el mismo servidor.
2. Matriz de compatibilidad. Cruce cada componente con la versión de destino. Marque qué ya es compatible, qué necesita actualizarse y qué no tiene reemplazo.
3. Staging y pruebas. Copie el entorno completo, suba la versión allí y corra pruebas de los flujos que generan dinero: compra, factura, inicio de sesión, reportes. Registre las advertencias de funciones obsoletas.
4. Despliegue con reversa. Elija una ventana de bajo tráfico, tenga el respaldo verificado y deje lista la versión anterior para volver en minutos si algo falla.
5. Monitoreo posterior. Vigile errores, tiempos de respuesta y consumo durante las primeras semanas, y retire entonces las mitigaciones temporales.

¿A qué versión de PHP migrar?

A PHP 8.4 u 8.5, porque son las que tienen soporte activo y más años por delante. Las fechas salen de php.net/supported-versions.php (consultado el 22-oct-2026).

Elegir 8.2 para «ir rápido» obliga a repetir el proyecto en pocos meses. La versión más alta no siempre es la correcta: su framework y sus plugins fijan el techo. La guía oficial de cambios incompatibles está en el manual de PHP para 8.3 y para 8.4.

¿Qué se rompe con más frecuencia y cuándo conviene modernizar?

Casi siempre se rompen cuatro cosas: código que usa funciones obsoletas, extensiones, código cifrado y plugins abandonados.

• Funciones y comportamientos obsoletos. Por ejemplo, las propiedades dinámicas en clases quedaron obsoletas en PHP 8.2 (lista oficial). Hoy generan avisos; más adelante, errores.
• Extensiones. Las compiladas para una versión deben reinstalarse o reemplazarse en la nueva.
• Código cifrado, tipo ionCube. Necesita un cargador compatible con la versión de destino, y a veces el proveedor debe reemitir los archivos. Si ya no existe ese proveedor, el código es un problema aparte.
• Plugins y temas abandonados. Si el autor no publica una versión compatible, hay que sustituirlos o reescribirlos.

¿Parchear o modernizar?

Parchear tiene sentido cuando la aplicación es pequeña, tiene pruebas y pocos componentes sin mantenimiento. Modernizar conviene cuando se repiten tres señales: el código no tiene documentación, el único que lo entendía se fue y la lista de incompatibilidades crece con cada versión.

En ese caso, migrar la versión de PHP sin reordenar el sistema deja la deuda intacta. Hablamos del tema en software heredado sin documentación, y si la decisión toca su ERP, en integrar o cambiar de ERP. Para dimensionar un rediseño, vea cuánto cuesta un software a la medida.

¿Cuánto cuesta y cuánto tarda migrar?

Depende del inventario. Por eso no damos una cifra a ciegas: dos empresas con el mismo PHP 8.1 pueden estar a semanas o a meses de distancia, según cuántas aplicaciones, cuánto código propio y cuántos componentes sin mantenimiento tengan.

Lo que sí cambia el costo es aquello que ya sabe: cuántos sistemas corren PHP, si existen pruebas automáticas, si hay código cifrado y si el entorno de staging existe. El diagnóstico de 30 minutos, sin costo ni compromiso, dimensiona el trabajo con esos datos. Si el alcance incluye reescribir módulos, forma parte de un proyecto de software a la medida, y si necesita un servidor con versiones gestionadas, de hosting y cloud.

PHP 8.1 sin parche no obliga a decidir hoy una reescritura, pero sí a dejar de tratar la versión como un detalle técnico: protéjase esta semana con mitigaciones y un proveedor que responda por escrito, y use los próximos meses para migrar con inventario, pruebas y reversa. Si prefiere empezar con otra mirada, agende el diagnóstico de 30 minutos, sin costo.