PHP 8.2 deja de tener soporte el 31/12/2026: qué hacer antes

En 30 segundos

• PHP 8.2 recibe el último parche de seguridad, como mucho, hasta el 31 de diciembre de 2026. Desde el 1 de enero de 2027, cualquier falla nueva queda abierta.
• El sistema no se apaga ese día: sigue funcionando, pero sin correcciones, y la próxima falla grave, como fue PHP2Shell en octubre, no va a tener arreglo oficial para 8.2.
• Lo primero es confirmar la versión exacta en cada servidor. Hoy, la mínima segura de la rama es 8.2.35.
• El destino recomendado es PHP 8.4, con soporte hasta fin de 2028. Si alguna pieza del sistema todavía no lo admite, PHP 8.3 es el salto más corto, con soporte hasta fin de 2027.
• Dos meses alcanzan para un sistema al día, si se empieza ahora y se evita migrar en pleno cierre de año.
• Si no llegás a migrar antes del 31/12, va a haber parches de terceros para seguir protegido mientras terminás la migración.

PHP 8.2 deja de tener soporte el 31 de diciembre de 2026. Quedan dos meses para pasar a PHP 8.3 u 8.4, y el cierre coincide con las fiestas, la temporada alta de muchos comercios y el cierre contable. Conviene tener la migración resuelta antes de diciembre.

PHP 8.2 fue la versión de referencia durante 2023 y 2024, y muchos sistemas se instalaron o actualizaron sobre ella. Por eso hoy es una de las más usadas en servidores de empresa. En DCisGlobal lo vemos seguido en los diagnósticos: el sistema anda bien, nadie miró la fecha y el plazo ya se puede contar en semanas.

¿Qué pasa el 31 de diciembre de 2026?

Termina el soporte de seguridad de PHP 8.2. Su soporte activo, el que corrige errores generales, ya había terminado el 31 de diciembre de 2024. Desde entonces solo recibía parches de seguridad, y a partir de 2027 no va a recibir ninguno.

La fecha no se corre. PHP publica el calendario de cada rama cuando sale, y el de 8.2 está fijado desde 2022.

¿Y si no llegás a migrar antes del 31 de diciembre?

Va a haber parches después de esa fecha, pero no oficiales. Debian 12 sigue corrigiendo su PHP 8.2 hasta el 30/06/2028, y Red Hat Enterprise Linux 8 y 9 lo hacen hasta mayo de 2029. Para otros servidores hay empresas que publican parches para versiones de PHP sin soporte, también como extensión de paneles como cPanel y Plesk.

Estos parches corrigen fallas de seguridad sin cambiar de rama, así que el código no se rompe. Sirven para pasar el cierre de año sin apuro y migrar con calma en 2027, no para quedarse en 8.2 para siempre.

En DCisGlobal podemos instalar el parche y mantenerlo al día mientras se hace la migración.

¿Querés aplicar el parche? Escribinos por WhatsApp y revisamos tu servidor.

¿Qué se rompe y qué riesgo corrés?

El 1 de enero no se rompe nada. El sitio, la tienda o el sistema de gestión siguen funcionando igual. El problema es lo que pasa después:

• Fallas que no se corrigen. El ejemplo está fresco: el 21 de octubre de 2026, PHP publicó la corrección de PHP2Shell, dos fallas críticas que permiten tomar el control de un servidor. Llegó a 8.2.35 porque la rama todavía tenía soporte. Una falla parecida en 2027 ya no tendría arreglo oficial para 8.2. Lo contamos en qué es PHP2Shell y qué hacer.
• El hosting cambia la versión por su cuenta. Muchos proveedores retiran las versiones sin soporte o las pasan a un plan de pago. Si el cambio llega sin pruebas previas, el sistema puede dejar de andar de un día para el otro.
• Las piezas del sistema dejan de acompañar. Plugins, módulos, pasarelas de pago y librerías de facturación electrónica van subiendo la versión mínima de PHP. Quedarse en 8.2 termina bloqueando actualizaciones que sí necesitás.
• Auditorías y clientes que preguntan. Una versión sin soporte aparece en cualquier revisión de seguridad, y cada vez más empresas la piden en sus requisitos para proveedores.

Un matiz: si tu servidor usa el PHP que viene con la distribución de Linux (Debian 12, por ejemplo, trae 8.2), el responsable de esa distribución puede seguir aplicando algunos parches por su cuenta. Hay que confirmarlo con quien administra el servidor, no darlo por hecho.

¿Cómo saber qué versión de PHP tenés?

Lleva minutos, y conviene hacerlo en todos los servidores, no solo en el principal:

• Panel del hosting: casi todos muestran la versión de PHP de cada sitio en la configuración.
• En el servidor: el comando php -v muestra la versión exacta, por ejemplo 8.2.29. Ojo: la versión que usan las tareas programadas puede ser distinta de la que atiende la web.
• En WordPress: Herramientas, Salud del sitio, Información, sección Servidor.
• En la respuesta del sitio: algunos servidores la informan en una cabecera del tipo «X-Powered-By: PHP/8.2.20». Si se ve desde afuera, también la ve cualquiera.

Con la versión en la mano, la lectura es simple. Si es 8.2 y está por debajo de 8.2.35, hay que actualizar dentro de la rama ya mismo, por PHP2Shell. Y en paralelo, planificar el salto a 8.3 u 8.4 antes de fin de año.

¿No sabés qué versión corre tu sistema o qué tan grande es el salto? Escribinos con el nombre del sistema y lo revisamos con vos. Revisar mi versión de PHP

¿A qué versión conviene pasar: 8.3, 8.4 u 8.5?

A la más nueva que soporten todas las piezas del sistema: el framework o CMS, los plugins o módulos y las librerías que conectan con terceros.

• PHP 8.4, el destino recomendado. Tiene soporte activo hasta el 31/12/2026 y de seguridad hasta el 31/12/2028. Desde 8.2 es un salto de dos versiones, pero los cambios siguen siendo acotados.
• PHP 8.3, si alguna pieza todavía no admite 8.4. Es el cambio más chico, pero deja un año de margen: su soporte activo terminó el 31/12/2025 y recibe solo parches de seguridad hasta el 31/12/2027. Lo detallamos en PHP 8.3: fechas, riesgos y cómo migrar.
• PHP 8.5, si el sistema es moderno y está al día. Es la rama más nueva, con soporte hasta el 31/12/2029. Conviene confirmar antes que cada dependencia ya la admita.

Qué cambia al pasar de PHP 8.2 a 8.3 y 8.4

Poco, comparado con saltos anteriores como el de 7.4 a 8.0. Las guías oficiales de migración de php.net documentan sobre todo funciones obsoletas y ajustes puntuales:

• Incrementar textos vacíos o con símbolos queda obsoleto (8.3). Usar «++» sobre un texto que no es un número ni una combinación de letras y números empieza a dar avisos. Aparece en código viejo que arma códigos o numeraciones.
• Errores de fechas más estrictos (8.3). Las funciones de fechas ahora lanzan errores propios en lugar de simples advertencias. Hay que probar todo lo que calcule vencimientos, turnos o períodos.
• Parámetros que aceptan vacío sin declararlo (8.4). Una forma muy común de escribir funciones queda obsoleta. No detiene nada, pero llena los registros de avisos hasta que se corrige, y la corrección es mecánica.
• Extensiones que dejan de venir incluidas (8.4). IMAP, OCI8, PDO_OCI y PSpell salen de PHP y hay que instalarlas aparte. Si tu sistema lee correo por IMAP o se conecta a una base Oracle, este punto se revisa primero.
• Contraseñas un poco más costosas de calcular (8.4). El valor por defecto para guardar contraseñas con bcrypt subió de 10 a 12. Es más seguro, y en servidores muy justos se nota en el inicio de sesión.

Como en los otros saltos, el trabajo grande no suele estar en PHP sino alrededor: el framework, el CMS y los plugins que necesitan su propia actualización.

Cómo migrar en dos meses sin frenar el negocio

1. Esta semana, el inventario. Versión exacta en cada servidor (producción, pruebas y los que nadie recuerda), qué sistema corre en cada uno y quién lo mantiene.
2. Dependencias. Listar framework, CMS, plugins, módulos y librerías, y verificar cuáles tienen versión compatible con 8.4 o, como mínimo, con 8.3. De acá sale el destino.
3. Una copia para probar. Montar el sistema con la versión nueva en un entorno de pruebas, activar los avisos de funciones obsoletas y corregir lo que aparezca.
4. Probar lo que factura. Ventas, cobros, facturación, integraciones y tareas programadas, con alguien de tu equipo que use el sistema todos los días.
5. Elegir la fecha. Migrar en noviembre o a principios de diciembre, lejos de las fiestas, de los picos de venta y del cierre contable, con copia de seguridad y un plan claro para volver atrás.
6. Dejar agendado el próximo salto. Con 8.4 el margen llega a fin de 2028. La siguiente actualización se planifica con tiempo, no en la última semana.

Si el sistema es antiguo o depende de piezas abandonadas, dos meses pueden no alcanzar. En ese caso, primero se protege lo que está expuesto y después se arma un plan por etapas. Lo explicamos en cómo actualizar PHP en sistemas sin soporte.

Cómo lo resolvemos en DCisGlobal

Pasar de 8.2 a 8.3 u 8.4 suele ser un proyecto acotado, y lo tratamos así: diagnóstico tecnológico para definir el destino, plan con costo por etapa, migración en un entorno de pruebas y validación con tu equipo antes de tocar producción.

Si el servidor también necesita orden, nos podemos hacer cargo con hosting administrado. Y para que el sistema no vuelva a quedar atrás, el soporte y mantenimiento incluye las actualizaciones de PHP en el calendario.

Si la migración no puede hacerse enseguida, instalamos un parche de soporte extendido para que el sistema siga protegido mientras tanto.

Consultar por WhatsApp

Para seguir leyendo

• PHP 8.3 fin de soporte: fechas, riesgos y cómo migrar.
• PHP 8.1 fin de soporte: por qué pasar a PHP 8.3.
• Actualizar PHP: qué riesgo corre un sistema sin soporte.
• PHP2Shell: qué es la falla crítica de PHP y qué hacer ahora.
• PHP 8.0: vulnerabilidades y fin de soporte.
• PHP 7.4: fin de soporte y cómo actualizar.