PHP 8.2 se queda sin parches de seguridad el 31 de diciembre de 2026: qué significa para tu sistema

PHP 8.2 recibe parches de seguridad hasta el 31 de diciembre de 2026, y después ninguno más. Lo dice la página de versiones soportadas de php.net, que es la única fuente que manda en esto. Si tu sistema corre en 8.2 —o en algo más viejo—, el 1 de enero no se cae nada. Lo que cambia es que, a partir de ese día, cualquier falla de seguridad que se descubra en PHP 8.2 se queda abierta.

Del lado de Laravel el calendario va por delante: Laravel 11 dejó de recibir parches de seguridad el 12 de marzo de 2026 y Laravel 12 ya no recibe corrección de errores desde el 13 de agosto de 2026; solo seguridad, hasta el 24 de febrero de 2027.

Escribo esto para dos personas a la vez: el dueño o gerente que tiene un sistema en PHP o Laravel que «funciona» y no sabe en qué versión está, y el desarrollador que se lo tiene que explicar sin sonar a que quiere venderle un proyecto. Las fechas las revisé el 15 de octubre de 2026 en las fuentes oficiales que enlazo abajo.

Las fechas, sin redondear

PHP

Desde marzo de 2024 cada versión de PHP tiene cuatro años de vida: dos de soporte activo (corrección de errores y seguridad) y dos solo de parches de seguridad críticos, que salen cuando hacen falta, no en un calendario fijo.

Fuente: php.net/supported-versions.php, contrastada con endoflife.date/php. La última versión de la rama 8.2 al momento de escribir esto es la 8.2.34, del 24 de septiembre de 2026. Si tu servidor dice 8.2 pero con un número más bajo, ni siquiera tienes los parches que sí existen.

Ojo con la línea de 8.3: también lleva ya diez meses solo con parches de seguridad. No es un destino para quedarse cinco años.

Laravel

La política está en las notas de versión de Laravel: 18 meses de corrección de errores y 2 años de parches de seguridad por versión mayor.

Cualquier cosa anterior a Laravel 10 lleva años fuera de soporte.

Para que se vea en concreto qué significa «sin soporte» en Laravel: el 1 de junio de 2026 se publicó CVE-2026-48019, una inyección CRLF en la regla de validación de correo, de severidad alta, que permite a un atacante sin cuenta interferir con los correos que manda la aplicación. El parche salió en Laravel 12.60.0 y 13.10.0. Para Laravel 11 y anteriores no salió ninguno. El aviso no dice si esas versiones son vulnerables: dice a qué versiones hay que actualizar, y ninguna es la tuya.

Qué pasa de verdad el 1 de enero

Hay dos versiones exageradas de esta historia y ninguna sirve para decidir.

La que no pasa: el sistema no deja de funcionar. PHP no tiene fecha de caducidad interna. Tu sistema en PHP 8.2 va a abrir el 2 de enero igual que el 31 de diciembre. Quien te diga que «se apaga» te está asustando.

La que tampoco: que te hackean al día siguiente. Tampoco. El riesgo crece con el tiempo, no de golpe.

Lo que sí pasa son cuatro cosas, y vale la pena separarlas porque cada una tiene un costo distinto.

1. Las vulnerabilidades nuevas se quedan sin parche

Es el riesgo central. Para dimensionarlo: la versión 8.5.11 de PHP, del 24 de septiembre, corrigió más de diez fallas con CVE en una sola entrega —en OpenSSL, SOAP, el lector de archivos Phar, el cliente HTTP de los streams y el driver de MySQL, entre otros—, según el ChangeLog oficial. Hoy esas correcciones llegan también a 8.2 cuando aplican. A partir de 2027 ya no.

No todas te afectan: un CVE en SOAP no importa si no usas SOAP. Pero esa evaluación hay que hacerla con cada aviso, para siempre, y alguien tiene que hacerla.

2. El hosting retira la versión

Los proveedores no mantienen versiones muertas indefinidamente, y cada uno lo hace con su ritmo:

• cPanel (el panel de buena parte del hosting compartido en México) documenta que las versiones sin soporte salen de los perfiles por defecto de EasyApache 4, pero siguen disponibles para instalar (lista de versiones de cPanel). Así lo hizo con PHP 8.0 en noviembre de 2023. La decisión final es de tu proveedor, no de cPanel.
• Acquia, un hosting administrado más estricto, retiró PHP 8.2 el 1 de octubre de 2026 —tres meses antes de la fecha oficial— y pasó los entornos que quedaban a PHP 8.4 por su cuenta.

El segundo caso es el que duele: un día tu proveedor cambia la versión, el sistema truena y te enteras por los clientes. No encontré un anuncio de fecha de retiro de PHP 8.2 de los hostings compartidos más comunes en México; pregúntale al tuyo directamente y pídelo por escrito.

Un matiz para quien tiene servidor propio: si tu PHP viene de los paquetes de Debian 12, el que te manda parches no es php.net sino Debian. Ahí php8.2 sigue recibiendo actualizaciones (la 8.2.34 entró a oldstable-security el 4 de octubre, según el tracker de Debian), y Debian 12 tiene soporte LTS hasta el 30 de junio de 2028 (endoflife.date/debian). Después del 31 de diciembre, esos parches dependerán de que el equipo de LTS los adapte por su cuenta; Debian LTS no cubre todos los paquetes, así que compruébalo en tu servidor con check-support-status, no lo asumas.

3. Si cobras con tarjeta, tu auditor lo va a ver

Si tu empresa procesa, guarda o transmite datos de tarjeta y tiene que cumplir PCI DSS 4.0.1, el requisito 12.3.4 pide revisar al menos una vez al año el hardware y software en uso, incluyendo que «sigan recibiendo parches de seguridad de los proveedores a tiempo» y «un plan con un plazo identificado para remediar las tecnologías obsoletas, incluidas aquellas cuyo fin de vida haya sido anunciado». PHP 8.2 ya tiene fin de vida anunciado. No es una multa automática, pero sí un hallazgo que necesita respuesta con fecha.

Si cobras con una pasarela externa (Mercado Pago, Stripe, Openpay con su formulario alojado) y tu sistema nunca toca el número de tarjeta, tu alcance de PCI es mucho menor. Confírmalo con quien lleve el cumplimiento.

4. Las librerías suben su mínimo y te quedas sin actualizaciones

Este es el que nadie ve venir. Laravel 13 pide PHP 8.3. Symfony 8 pide PHP 8.4. Pest 5 y PHPUnit 13 piden PHP 8.4. Los paquetes de terceros siguen a sus frameworks. Un sistema en PHP 8.2 puede seguir corriendo, pero cada vez menos paquetes publican versiones que pueda instalar, incluidos sus parches de seguridad. El atraso no se nota durante meses y luego se vuelve un salto de tres versiones a la vez.

Cómo saber en qué versión estás

Tres formas, de la más confiable a la más fácil. El desarrollador debería poder darte la respuesta en cinco minutos; si no puede, eso ya es un dato.

1. En el servidor, por SSH:

php -v

Ojo: en servidores con varias versiones instaladas, la PHP de la terminal puede no ser la que atiende la web. Para estar seguro de la que corre el sitio, mira la configuración de PHP-FPM o del virtual host, o crea un archivo temporal con <?php echo PHP_VERSION; en una ruta privada, ábrelo una vez y bórralo enseguida. Nunca dejes un phpinfo() publicado.

2. La versión de Laravel, en el código:

php artisan --version
# o, sin ejecutar nada:
composer show laravel/framework | grep versions

Y en composer.json, la línea "php" dentro de "require" dice qué versión de PHP acepta el proyecto (por ejemplo "^8.1"), no cuál está corriendo. La versión exacta de Laravel instalada está en composer.lock, buscando "name": "laravel/framework".

3. En el panel del hosting: en cPanel es Seleccionar versión de PHP o MultiPHP Manager; en Plesk, Configuración de PHP del dominio. Ahí aparece la versión que atiende cada sitio.

Si tu sistema no es Laravel —PHP «a mano», CodeIgniter, Yii—, los pasos 1 y 3 aplican igual.

El dato que cambia la conversación: ¿puedes salir de 8.2 sin tocar Laravel?

Muchas veces, sí. La tabla de Laravel de arriba dice qué versiones de PHP soporta cada una, y de ahí sale esto:

Subir solo PHP no resuelve que el framework esté sin soporte, pero cierra el hueco más grande —el lenguaje mismo— con mucho menos trabajo que una migración completa. Para un sistema en Laravel 10 u 11, es el primer paso razonable. Para uno en Laravel 9, no existe ese atajo.

Las tres salidas

1. Actualizar

Subir PHP (y, si hace falta, Laravel) a versiones con soporte. Es la salida por defecto y casi siempre la correcta, por una razón simple: es la única que deja el problema resuelto en vez de pospuesto.

Conviene cuando: el sistema sigue siendo importante para la operación, va a vivir más de un año, y el código es razonable aunque nadie lo entienda del todo. Que no haya documentación ni pruebas no lo descalifica; hace el trabajo más lento, nada más.

Cómo, en orden: primero una copia del sistema fuera de producción, después PHP a la versión más alta que tu Laravel soporte, después Laravel de una versión mayor a la vez, con pruebas entre cada salto. Los detalles de cada salto están en la serie «qué se rompe»: Laravel 13 y, para lo que viene en noviembre, PHP 8.6. El procedimiento general —respaldo, rama, composer update, verificación— está en cómo actualizar un proyecto de Laravel.

Lo que cuesta: depende menos del tamaño del sistema que de cuántos paquetes de terceros usa, cuántos están abandonados y cuántas versiones atrás está. De Laravel 11 a 12 suele ser poco. De Laravel 6 a 13 es un proyecto.

2. Congelar con mitigaciones

Dejar la versión como está, a propósito y por escrito, y reducir la superficie de ataque mientras tanto. No es lo mismo que «no hacer nada»: no hacer nada es congelar sin saberlo.

Conviene cuando: el sistema tiene fecha de retiro cercana (lo vas a sustituir por un ERP, o el área que lo usa desaparece), es interno y no está expuesto a internet, o necesitas comprar unos meses mientras se planea la actualización.

Qué implica, como mínimo:

• Sacarlo de internet si se puede: detrás de VPN o con acceso restringido por IP.
• Un WAF delante (Cloudflare, por ejemplo) y cabeceras de seguridad bien puestas.
• PHP 8.2 en su última versión (8.2.34) antes de que se congele.
• Respaldos que se hayan restaurado al menos una vez, no solo generado.
• Si necesitas parches después de 2026: soporte extendido de pago (cPanel recomienda TuxCare ELS para versiones viejas) o los paquetes de tu distribución Linux si todavía los cubre.
• Una fecha escrita para revisar la decisión. Congelar sin fecha es como el «lo vemos después» que te trajo aquí.

3. Reescribir

Hacer un sistema nuevo y apagar el viejo. Es la opción que más se vende y la que menos veces conviene.

Conviene cuando: la tecnología ya no tiene ruta de actualización razonable (PHP 5 con extensiones que ya no existen, un framework abandonado), el negocio cambió tanto que el sistema ya no hace lo que se necesita, o el código está tan enredado que cada cambio cuesta más que hacerlo de nuevo, y eso lo dice un diagnóstico, no una corazonada.

Por qué casi nunca es lo primero: mientras se reescribe pagas dos sistemas, el nuevo tarda meses en igualar las reglas de negocio que el viejo ya tenía resueltas —muchas de ellas sin documentar, metidas en un if que nadie recuerda por qué existe— y una buena parte de las reescrituras se abandona a medias. Cuando sí conviene reescribir, casi siempre funciona mejor por partes: un módulo a la vez, con el sistema viejo operando.

Si alguien te propone reescribir sin haber leído tu código, desconfía de la propuesta, sea mía o de quien sea.

Qué haría yo, en orden, antes de que acabe el año

1. Saber la versión de PHP y de Laravel, con los comandos de arriba. Hoy.
2. Preguntarle al hosting qué va a hacer con PHP 8.2 y cuándo, por escrito.
3. Ver la tabla de compatibilidad: si puedes subir PHP sin tocar Laravel, ese es el primer paso.
4. Decidir entre las tres salidas con un dueño y una fecha. Cualquiera de las tres es defendible si se decidió; la que no se defiende es la que nadie eligió.

Preguntas frecuentes

¿Cuándo deja de tener soporte PHP 8.2?

PHP 8.2 recibe parches de seguridad hasta el 31 de diciembre de 2026, según php.net/supported-versions.php. La corrección de errores terminó el 31 de diciembre de 2024. Después del 31 de diciembre de 2026 no habrá más versiones de la rama 8.2 publicadas por el proyecto PHP.

¿Mi sistema en PHP 8.2 deja de funcionar el 1 de enero de 2027?

No. PHP no tiene una fecha de caducidad interna y el sistema sigue funcionando igual. Lo que cambia es que las vulnerabilidades nuevas que se descubran en PHP 8.2 ya no se corrigen, que los proveedores de hosting empiezan a retirar la versión y que cada vez menos librerías publican versiones compatibles.

¿Qué versiones de Laravel tienen soporte en octubre de 2026?

Laravel 13 tiene soporte completo (corrección de errores hasta el Q3 de 2027 y seguridad hasta el Q1 de 2028). Laravel 12 solo recibe parches de seguridad, hasta el 24 de febrero de 2027; la corrección de errores terminó el 13 de agosto de 2026. Laravel 11 dejó de recibir parches de seguridad el 12 de marzo de 2026 y Laravel 10 el 4 de febrero de 2025.

¿Puedo actualizar PHP sin actualizar Laravel?

Depende de la versión de Laravel. Laravel 12 soporta PHP 8.2 a 8.5, Laravel 11 soporta 8.2 a 8.4 y Laravel 10 soporta 8.1 a 8.3, así que en esos casos puedes salir de PHP 8.2 sin cambiar de Laravel. Laravel 9 solo llega a PHP 8.2, así que salir de 8.2 obliga a subir también Laravel.

¿Cómo sé qué versión de PHP usa mi sistema?

En el servidor, con el comando php -v; en el panel del hosting, en «Seleccionar versión de PHP» o «MultiPHP Manager» de cPanel. Para Laravel, php artisan --version o composer show laravel/framework. La línea "php" de composer.json indica qué versiones acepta el proyecto, no cuál está corriendo.

¿Conviene reescribir un sistema PHP viejo desde cero?

Casi nunca como primera opción. Reescribir obliga a pagar dos sistemas durante meses y a redescubrir reglas de negocio que el sistema viejo ya resolvía. Conviene cuando la tecnología no tiene ruta de actualización razonable o el sistema ya no hace lo que el negocio necesita, y aun así suele funcionar mejor por partes, con el sistema viejo operando mientras tanto.

Si no sabes por dónde empezar

Es justo el trabajo que hago en el rescate de sistemas PHP y Laravel. Empieza con un diagnóstico de 5 días hábiles por $9,900 MXN + IVA: inventario de versiones de PHP, Laravel y cada paquete, riesgos ordenados por lo que te costaría que fallen, un respaldo verificado con una copia del sistema corriendo fuera de producción, y una recomendación argumentada de qué actualizar, qué congelar y qué conviene reescribir, con precio cerrado por etapa. Producción no se toca durante el diagnóstico, y si después contratas la estabilización, el diagnóstico se descuenta completo.

Si prefieres hacerlo con tu equipo, este artículo y los de la serie «qué se rompe» tienen lo necesario para empezar.