Desde el 21 de octubre de 2026, cualquier sistema con PHP por debajo de 8.2.35, 8.3.36, 8.4.27 u 8.5.12 está expuesto a una falla crítica que permite tomar el control del servidor, y PHP 8.1 o anteriores ya no reciben la corrección oficial. La salida no es necesariamente rehacerlo todo: primero hay que saber qué versión corre, qué depende de ella y cuál es el camino más corto para volver a tener soporte.
En DCisGlobal lo encontramos casi en cada diagnóstico. Un CRM instalado en 2016, una tienda online de 2017, un sistema de gestión que «anda perfecto». Debajo, una versión de PHP que dejó de recibir parches hace años.
Un número para dimensionarlo: PHP 7.4, una de las versiones más usadas en servidores de empresa, recibió su último parche de seguridad en noviembre de 2022. PHP 5.6 lo recibió en diciembre de 2018. Incluso PHP 8.1 quedó sin soporte a fines de 2025.
¿Hay que ponerse al día y no hay quién lo haga? En DCisGlobal hacemos la actualización de PHP, incluida la urgencia por PHP2Shell, y armamos el plan para los sistemas que no se pueden actualizar de un día para el otro. Consultar por WhatsApp
¿Qué es PHP y por qué importa en tu empresa?
PHP es el lenguaje sobre el que funcionan buena parte de los sistemas web que usan las pymes: CRM como Vtiger o SuiteCRM, tiendas como PrestaShop o Magento, sitios en WordPress, Joomla o Drupal, y muchos sistemas de gestión hechos a medida.
Nadie en la dirección elige «qué versión de PHP usar». Se elige un sistema, y ese sistema viene atado a una versión. Cuando el sistema no se actualiza durante años, la versión de PHP tampoco.
Por eso el problema es invisible hasta que aparece: el sistema funciona, pero lo que tiene debajo quedó congelado.
¿Qué significa que una versión de PHP no tenga soporte?
Cada versión de PHP recibe correcciones durante un tiempo limitado. Después queda en «fin de vida» (end of life): nadie publica más parches para ella.
En la práctica, eso implica tres cosas para la operación:
- Vulnerabilidades conocidas que no se corrigen. Cuando aparece una falla de seguridad, se corrige en las versiones vigentes y las viejas quedan expuestas.
- El proveedor de hosting empuja a actualizar. Muchos servidores administrados dejan de ofrecer versiones viejas, y el sistema puede dejar de funcionar el día que cambian la configuración.
- Las integraciones se rompen. Pasarelas de pago, facturación electrónica o servicios de correo dejan de aceptar conexiones de software antiguo.
No es una alarma de hoy para mañana. Es un riesgo que crece cada mes que pasa.
Octubre de 2026: actualizar dejó de ser opcional
El 21 de octubre de 2026, el equipo de PHP publicó una actualización de seguridad para todas las versiones con soporte. Corrige dos fallas críticas (CVE-2026-109618 y CVE-2026-109619), conocidas como PHP2Shell y calificadas con 9,2 sobre 10. Sus detalles se filtraron un día antes del parche y ya hay reportes de ataques reales: lo explicamos en PHP2Shell: qué es la falla crítica de PHP y qué hacer ahora.
Traducido a negocioUn atacante puede llegar a ejecutar código en el servidor sin usuario ni contraseña, solo enviando pedidos al sitio. Según el propio aviso de PHP, el riesgo alcanza a cualquier instalación que atienda tráfico web, y no existe una mitigación completa: la única salida segura es actualizar.
No vamos a detallar cómo funcionan las fallas. Lo que importa para decidir es qué versión hay que tener, como mínimo, a partir de ahora:
| Rama | Mínima segura (oct 2026) | Soporte hasta | Estado |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 31 dic 2029 | Con soporte |
| PHP 8.4 | 8.4.27 | 31 dic 2028 | Con soporte |
| PHP 8.3 | 8.3.36 | 31 dic 2027 | Con soporte |
| PHP 8.2 | 8.2.35 | 31 dic 2026 | Por vencer |
| PHP 8.1 | Sin corrección (última: 8.1.34) | 31 dic 2025 | Sin soporte |
| PHP 8.0 | Sin corrección (última: 8.0.30) | 26 nov 2023 | Sin soporte |
| PHP 7.4 | Sin corrección (última: 7.4.33) | 28 nov 2022 | Sin soporte |
| PHP 7.0 a 7.3 | Sin corrección | 2019–2021 | Sin soporte |
| PHP 5.6 | Sin corrección (última: 5.6.40) | 31 dic 2018 | Sin soporte |
¿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.
Por versión: PHP 8.1 sin soporte, PHP 8.0: vulnerabilidades y fin de soporte y PHP 7.4: fin de soporte y cómo actualizar.
Cómo leer la tabla:
- Cualquier versión por debajo de la mínima de su rama es vulnerable. Un servidor con PHP 8.3.30, por ejemplo, está tan expuesto como uno viejo: hay que llevarlo a 8.3.36 o superior.
- PHP 8.1 y anteriores no reciben la corrección oficial. PHP publicó parches para 7.4, 8.0 y 8.1 que algunos proveedores de Linux y de soporte extendido aplican por su cuenta. Si el sistema depende de una de esas versiones, hay que confirmar con el proveedor que el parche está aplicado o, mejor, salir de esa versión.
- PHP 8.2 termina su soporte el 31 de diciembre de 2026. Actualizar hoy a 8.2.35 resuelve la urgencia, pero en dos meses vuelve a quedar sin parches. Si hay que hacer el trabajo, conviene ir directo a 8.3 o superior.
La conclusión práctica: todo sistema que no corra sobre PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 o posteriores está hoy expuesto a una falla crítica conocida. Y los que necesitan PHP 8.1 o anterior, además, ya no van a recibir más correcciones.
¿Tu versión figura sin soporte o por debajo de la mínima de su rama? Mandanos el número de versión y te decimos qué riesgo corre y cuál es el camino más corto para salir. Consultar por WhatsApp
¿Qué sistemas suelen quedar atrapados en PHP viejo?
En nuestra experiencia, los casos más frecuentes son estos:
| Sistema | Versiones que suelen quedar atrapadas | Sobre qué PHP suelen correr |
|---|---|---|
| Vtiger CRM | 5.x, 6.x y 7.x | PHP 5 y 7 |
| SugarCRM (edición libre) | 6.5 | PHP 5 |
| SuiteCRM | 7.x antiguas | PHP 7 |
| Dolibarr | versiones de hace varios años | PHP 5 y 7 |
| Magento | 1.x (sin soporte desde 2020) | PHP 5 y 7 |
| PrestaShop | 1.6 y primeras 1.7 | PHP 5 y 7 |
| osCommerce | 2.x | PHP 5 |
| Joomla | 3.x (sin soporte desde 2023) | PHP 7 |
| Drupal | 7 (sin soporte desde enero de 2025) | PHP 5 y 7 |
| WordPress | sitios sin mantenimiento con temas y plugins viejos | PHP 7 |
| Sistemas a medida | hechos con CodeIgniter 3, Zend o PHP sin framework | PHP 5 y 7 |
Lo contamos sistema por sistema: Vtiger, PrestaShop 1.6, Magento 1 y Dolibarr.
A esto se suma el servidor: muchos de estos sistemas corren en CentOS 7, sin soporte desde junio de 2024, o en Windows Server 2012, sin soporte desde octubre de 2023.
PHP 5.6.40: la última versión de PHP 5
PHP 5.6.40 fue la última versión de toda la rama 5, y PHP 5.6 quedó sin soporte el 31 de diciembre de 2018. Desde entonces no recibe correcciones oficiales: cada vulnerabilidad descubierta en casi ocho años, PHP2Shell incluida, sigue abierta en un servidor con 5.6.40. No hay una configuración que lo vuelva seguro.
Además, es el salto más largo. Entre PHP 5.6 y PHP 8 desaparecieron funciones que los sistemas viejos usan a diario, como las de conexión a bases de datos mysql_* o las expresiones ereg, eliminadas en PHP 7.0. Por eso casi nunca alcanza con cambiar la versión de PHP: hay que actualizar o adaptar el sistema, y mientras tanto aislarlo.
CentOS 7 y PHP 8.2.35
CentOS 7 quedó sin soporte el 30 de junio de 2024, y su repositorio oficial trae PHP 5.4. Para tener PHP 8.2.35 o una versión más nueva sobre CentOS 7 hay que recurrir a repositorios de terceros o compilarlo a mano, y cada parche futuro depende de eso, sobre un sistema operativo que tampoco recibe correcciones. Si el servidor ya corre PHP 8.2 sobre CentOS 7, confirmá que esté en 8.2.35 o posterior, y tené en cuenta que 8.2 pierde el soporte el 31 de diciembre de 2026.
La salida sólida es mudar el sistema a un servidor con un sistema operativo con soporte, como AlmaLinux o Rocky Linux, los sucesores más directos de CentOS, e instalar ahí PHP 8.3 o superior. Así se resuelven las dos cosas en un mismo proyecto.
El costo oculto de no actualizar
Quedarse parece gratis, porque no hay una factura. En la práctica, el costo aparece por otros lados:
Seguridad y datos de clientes. Un CRM o una tienda guarda datos personales. Una filtración afecta la confianza y, en España, puede implicar sanciones por protección de datos.
Trabajo manual. Cada integración que se rompe se reemplaza con una planilla o con alguien copiando datos a mano.
Dependencia de una persona. Estos sistemas suelen haber sido adaptados por un programador que ya no está. Cada cambio se vuelve lento y caro.
Cambios forzados. Lo peor es actualizar por obligación: el día que el hosting retira la versión vieja, el sistema se cae y hay que resolverlo con apuro.
Señales de que ya hay que actuar
- Nadie sabe con certeza qué versión de PHP usa el servidor.
- El proveedor de hosting envió avisos sobre versiones «obsoletas» o «no soportadas».
- Hay plugins, módulos o integraciones que dejaron de funcionar y se reemplazaron a mano.
- Para cambiar algo hay que llamar siempre a la misma persona.
- El sistema muestra advertencias de funciones obsoletas (deprecated) o errores después de cambios del servidor.
Con dos o más de estas señales, conviene diagnosticar antes de que el cambio llegue por obligación.
¿Qué opciones hay para salir?
1. Actualizar el sistema a una versión vigente. Si el sistema sigue encajando con el negocio, se actualiza a una versión que soporte PHP 8.2 o superior. El trabajo está en migrar personalizaciones y datos sin perder nada.
2. Adaptar el código a PHP 8. En sistemas a medida, a veces alcanza con corregir el código para que funcione en una versión nueva de PHP. Es la opción más rápida cuando el sistema está bien armado.
3. Hardening (blindaje) mientras se planifica. Si no se puede actualizar ya, se reduce la exposición: restringir accesos, sacar el sistema de internet abierto, actualizar el servidor en lo posible y asegurar copias verificadas. Sirve para ganar tiempo, no para quedarse.
4. Migrar o rediseñar. Si el sistema ya no acompaña la forma de trabajar, conviene pasar a otra plataforma o construir algo a medida, migrando los datos y los procesos.
Para decidir miramos tres cosas: cuánto código propio tiene el sistema, qué integraciones son críticas y qué necesita la operación en los próximos años.
Qué hacer ahora
- Inventariar: qué sistemas tiene la empresa, sobre qué versión exacta de PHP (con su número completo, por ejemplo 8.3.36) y en qué servidor corre cada uno. Todo lo que esté por debajo de la versión mínima de su rama se actualiza primero.
- Asegurar lo básico: copias de seguridad probadas y accesos revisados.
- Medir el impacto: qué procesos dependen de cada sistema y cuánto costaría que fallen.
- Elegir un camino con fechas: actualizar, adaptar, blindar o migrar, sin frenar la operación.
Nuestro servicio: actualización de PHP
Para las empresas que necesitan ponerse al día, ofrecemos un servicio puntual de actualización de PHP, en remoto, para empresas de España y Latinoamérica. Sirve igual para hosting compartido, servidores virtuales (VPS) o servidores propios.
Qué incluye:
- Revisión de versiones. Relevamos cada servidor y cada sistema web de la empresa con su versión exacta de PHP, y marcamos qué está expuesto (incluido PHP2Shell).
- Actualización a una versión con soporte. Llevamos PHP a 8.3 o superior (como mínimo, a la versión corregida de su rama). Primero sobre una copia de prueba, verificando que el sistema siga funcionando, y después en producción.
- Adaptación del sistema. Si el CRM, la tienda o el sistema a medida no funciona en la versión nueva, lo actualizamos o corregimos su código para que sí funcione.
- Plan para lo que no se puede mover ya. Si un sistema depende de PHP 8.1 o anterior, lo aislamos de inmediato y armamos el plan para actualizarlo o migrarlo, con fechas.
- Cambio de credenciales y revisión de intrusión. Rotamos contraseñas y claves de los sistemas que estuvieron expuestos y revisamos el servidor en busca de señales de ataque.
- Informe final. Qué se actualizó, qué quedó pendiente y qué conviene hacer después, en lenguaje de negocio.
Plazo orientativo: 72 horas.
