Ir al contenido
Todos los artículos

Versiones de PHP sin soporte: riesgos, cómo revisar la suya y cómo actualizar

PHP 8.1 y anteriores ya no reciben correcciones de seguridad, y el soporte de 8.2 termina el 31 de diciembre de 2026. Así puede revisar sus sitios y actualizar con seguridad.

M Por Max · 7 min de lectura
Versiones de PHP sin soporte: riesgos, cómo revisar la suya y cómo actualizar

Si su sitio web o aplicación funciona con una versión de PHP que llegó al fin de su vida útil (EOL, por sus siglas en inglés), el proyecto PHP ya no corrige sus problemas de seguridad, ni siquiera los graves. A finales de 2026, las ramas con soporte en php.net son 8.2, 8.3, 8.4 y 8.5, y PHP 8.2 deja de recibir correcciones de seguridad el 31 de diciembre de 2026. Todo lo que esté en 8.1 o versiones anteriores (7.4, 7.x, 5.6) ya no tiene soporte. La solución es sencilla: averigüe qué versión usa cada sitio, pruebe el sitio en una versión con soporte y haga el cambio. Esta guía le explica los tres pasos.

Qué significa "fin de vida" en PHP

El proyecto PHP sigue un ciclo de vida predecible que publica en su página de versiones con soporte:

  • Soporte activo (2 años): cada nueva rama recibe correcciones de errores y de seguridad de forma regular.
  • Soporte solo de seguridad (2 años más): únicamente se corrigen problemas de seguridad críticos, con versiones publicadas según sea necesario.
  • Fin de vida (después de unos 4 años): no hay más versiones de ningún tipo.

Esta es la situación actual según php.net:

Rama Soporte activo hasta Soporte de seguridad hasta Estado (finales de 2026)
8.5 31 dic. 2027 31 dic. 2029 Soporte activo
8.4 31 dic. 2026 31 dic. 2028 Soporte activo
8.3 31 dic. 2025 31 dic. 2027 Solo seguridad
8.2 31 dic. 2024 31 dic. 2026 Solo seguridad, termina pronto
8.1 — Terminó el 31 dic. 2025 Fin de vida
8.0 — Terminó el 26 nov. 2023 Fin de vida
7.4 — Terminó el 28 nov. 2022 Fin de vida

Confirme siempre las fechas vigentes en php.net antes de planificar, porque esta tabla quedará desactualizada con el tiempo.

Por qué una versión de PHP sin soporte es un riesgo para el negocio

Una versión EOL no deja de funcionar el día que termina el soporte. El sitio sigue cargando, y justamente por eso muchas empresas no lo tocan. El problema es lo que ocurre con el tiempo:

  • Las nuevas vulnerabilidades quedan abiertas. Cuando se descubre una falla en el propio PHP, la corrección solo se publica para las ramas con soporte. Su versión queda expuesta de forma indefinida.
  • Los plugins y librerías avanzan. Los plugins de WordPress, los paquetes de Laravel y otras dependencias dejan de dar soporte a versiones antiguas de PHP, así que usted también deja de recibir sus actualizaciones de seguridad.
  • El hosting se complica. Los proveedores de hosting y los paneles de control van eliminando las versiones antiguas de PHP, lo que puede obligarle a una actualización apresurada en el calendario de otra persona.
  • Preguntas de cumplimiento. Los cuestionarios de seguridad, las solicitudes de ciberseguro y marcos como PCI DSS normalmente esperan software con soporte y parches al día en los sistemas que manejan datos de clientes.

Nada de esto significa que su sitio será atacado mañana. Significa que su margen de seguridad se reduce cada mes, y que la actualización será más grande cuanto más espere.

Una nota sobre los paquetes de distribuciones Linux

Algunas distribuciones Linux empresariales publican sus propios paquetes de PHP y les incorporan correcciones de seguridad durante toda la vida de la distribución, aunque el número de versión parezca antiguo. Si su servidor usa PHP de los repositorios oficiales de su distribución, revise el ciclo de vida de ese proveedor, no solo el de php.net. Si PHP proviene de un repositorio de terceros, de un panel de control o de una compilación propia, asuma que aplican las fechas de php.net.

Desarrollador web revisando la versión de PHP de un sitio en un panel de hosting

Cómo comprobar qué versión de PHP usa su sitio

El servidor y el sitio web pueden usar versiones distintas, y un mismo servidor puede alojar varios sitios con versiones diferentes. Revise cada sitio.

En un panel de control

  • cPanel: abra MultiPHP Manager para ver la versión asignada a cada dominio.
  • Plesk: abra el dominio y vaya a PHP Settings.
  • Los paneles de hosting administrado suelen mostrar la versión de PHP de cada sitio en su configuración.

En WordPress

Vaya a Herramientas › Salud del sitio › Información › Servidor. La línea "Versión de PHP" muestra la versión con la que WordPress funciona realmente. Salud del sitio también le avisa cuando la versión está desactualizada.

Desde la línea de comandos

Ejecute php -v por SSH. Tenga cuidado: el PHP de la línea de comandos puede ser distinto del que usa el servidor web. Para conocer la versión web, cree un archivo temporal con <?php echo PHP_VERSION;, ábralo una vez en el navegador y bórrelo de inmediato. Nunca deje una página phpinfo() en un sitio en producción.

Desde fuera

Ejecute curl -I https://sudominio.com y busque el encabezado X-Powered-By: PHP/…. Si aparece, también le está diciendo su versión al resto de internet, lo cual es una buena razón para configurar expose_php = Off. Si no aparece, use uno de los métodos anteriores.

Cómo planificar la actualización

La mayoría de las actualizaciones transcurren sin problemas cuando se prueban antes. Un plan práctico para una pequeña empresa es el siguiente.

1. Inventario

Haga una lista de cada sitio y aplicación, su versión actual de PHP, quién lo mantiene y de qué depende (versión de WordPress, tema, plugins, framework, código a medida). Anote todo lo crítico para el negocio, como pagos en línea, formularios de reserva o portales de clientes.

2. Elija la versión de destino

Elija una rama con bastante tiempo de soporte por delante. Pasar directamente a 8.4 u 8.5 suele ahorrarle una segunda actualización poco después. Revise qué admite su software: WordPress recomienda PHP 8.3 o superior, y los frameworks y plugins importantes publican sus propias notas de compatibilidad.

3. Actualice primero la aplicación

Actualice el núcleo de WordPress, los temas y los plugins (o el framework y los paquetes de Composer) mientras sigue en la versión antigua de PHP, hasta donde lo permitan. Reemplace los plugins abandonados que llevan mucho tiempo sin actualizaciones. Solo este paso resuelve la mayoría de los problemas de compatibilidad.

4. Pruebe en una copia de staging

Clone el sitio en un entorno de pruebas (staging) con la versión de PHP de destino. Después:

  • Active el registro de errores (no la visualización de errores en pantalla) y revise el log.
  • Recorra las páginas clave y pruebe cada formulario, proceso de pago e inicio de sesión.
  • Lea las guías oficiales de migración de PHP de cada versión que se salte. Enumeran las funciones eliminadas y los cambios incompatibles.
  • Si tiene código a medida, pida a su desarrollador que ejecute un análisis estático o de compatibilidad con la versión de destino.

5. Cambie producción con un plan de retorno

Haga una copia de seguridad completa de archivos y base de datos, programe el cambio en un horario tranquilo, cambie la versión de PHP y vuelva a probar de inmediato. En la mayoría de los paneles de control, volver atrás es un solo clic si aparece algo inesperado.

6. Ponga la próxima actualización en el calendario

Una vez al día, anote la fecha de fin del soporte de seguridad de su nueva rama y planifique revisarla un año antes. Actualizar una versión a la vez, según lo previsto, es mucho más fácil que saltar cuatro versiones bajo presión.

Problemas frecuentes al actualizar (y qué significan)

  • Pantalla en blanco o "error crítico": normalmente un plugin o tema antiguo que usa funciones eliminadas. El log de errores indica el archivo.
  • Avisos de obsolescencia (deprecation) en el log: no son urgentes, pero indican que el código fallará en una versión futura. Programe la corrección.
  • Extensiones que faltan: cada versión de PHP tiene su propio conjunto de extensiones activadas. Asegúrese de que las que necesita su sitio (por ejemplo intl, gd o imagick, mbstring) estén activadas en la nueva versión.

Lista de verificación

  • Versión de PHP de cada sitio registrada
  • Sitios en 8.1 o anteriores programados para actualizar ya
  • Sitios en 8.2 programados antes del 31 de diciembre de 2026
  • Aplicaciones, temas y plugins actualizados primero
  • Prueba en staging completada, log de errores limpio
  • Copia de seguridad hecha, producción cambiada y probada de nuevo
  • Próxima fecha de revisión en el calendario

¿Necesita ayuda?

Core Florida IT ayuda a empresas de Miami-Dade y de todo el sur de Florida a inventariar sus sitios web y servidores, probar actualizaciones de PHP en staging y cambiar producción de forma segura, con soporte remoto en todo el país. Si no está seguro de qué versión usan sus sitios, solicite una evaluación de TI gratuita y lo revisamos con usted.

Fuentes

Siga leyendo

Hagamos de su TI la parte más sólida de su negocio.

Agende una evaluación de TI gratuita y sin compromiso. Le mostraremos exactamente dónde está y qué conviene resolver primero.

Llamar Evaluación gratuita