¿Qué hacer con una web que tiene una versión obsoleta de PHP o de Node.js?

La respuesta breve es esta: un sitio web con una versión obsoleta de PHP o de Node.js tiene tres caminos — adaptar el código a un lanzamiento con soporte, reconstruir el sitio web desde cero o mantenerlo durante un tiempo en una plataforma que todavía retroporta parches de seguridad al runtime antiguo, y mientras tanto planificar el paso con calma. El cuarto camino — dejarlo todo como está, porque el sitio web al fin y al cabo funciona — en realidad no existe, porque las ramas de PHP 8.1 y anteriores ya no reciben parches del proyecto PHP, la línea de lanzamiento 18 y la 20 de Node.js tampoco, y octubre de 2026 mostró en los dos casos qué significa eso en la práctica.

Un sitio web con una versión obsoleta de PHP no suele ser ni una excepción ni una negligencia particular. Se desarrolló hace cinco u ocho años, el desarrollador que lo construyó hace tiempo que trabaja en otra parte, y el sitio web ha servido todos estos años sin grandes problemas: ha aceptado solicitudes, ha mostrado precios y ha enviado facturas. Según los datos de W3Techs, en octubre de 2026 el 26,8 % de los sitios web que usan PHP funcionaba sobre PHP 7 y otro 7,7 % sobre PHP 5, de modo que más de un tercio de ellos usa un PHP que llegó al fin de vida hace varios años. La pregunta suele aparecer solo cuando el proveedor de hosting envía un aviso o cuando alguna vulnerabilidad llega a las noticias.

Cuándo una versión de PHP o de Node.js pasa a ser antigua

«Antigua» aquí no es una cuestión de gusto, porque tanto PHP como Node.js publican un calendario en el que se indica hasta qué fecha cada rama o cada línea de lanzamiento recibe parches. PHP da a cada rama dos años de soporte activo y otros dos años en los que salen solo correcciones de seguridad, y después la rama llega al fin de vida y deja de mantenerse de cualquier forma. Las líneas de soporte a largo plazo de Node.js terminan en la fase Maintenance LTS y, cuando esa fase acaba, la línea de lanzamiento ya no recibe ningún lanzamiento, tampoco cuando una vulnerabilidad nueva la afecta precisamente a ella.

En la tabla están las ramas y las líneas de lanzamiento con las que hoy hay que encontrarse con más frecuencia, y su estado en octubre de 2026. Las fechas están tomadas de la lista de fin de vida de PHP y del calendario de lanzamientos de Node.js, y las dos fuentes hay que volver a consultarlas también más adelante, porque cada año aparecen en ellas filas nuevas.

Merece la pena leer otra vez dos filas de esta tabla. PHP 8.2 llegará al fin de vida el 31 de diciembre de 2026, de modo que un sitio web que en el otoño de 2026 parece actual, en enero de 2027 estará en la misma situación que un sitio web con PHP 7.4, y el paso conviene planificarlo ya ahora, mientras se puede hacer sin prisa. La línea de lanzamiento 20 de Node.js todavía en el otoño de 2024 era la línea de soporte a largo plazo activa, Active LTS, sobre la que se empezaron muchos proyectos nuevos, pero el 30 de abril de 2026 llegó al fin de vida. El envejecimiento no ocurre de forma gradual: en un día concreto el runtime pasa de «recibe parches» a «no recibe nada», y en el sitio web en ese momento no cambia nada que se pudiera notar.

Por qué una web que funciona sigue estando en riesgo

Una versión sin soporte no se vuelve peligrosa el día en que llega el fin de vida, sino el día en que se publica una vulnerabilidad que también la afecta. El parche de seguridad para las ramas con soporte sale junto con la descripción y, en cuanto es público, los atacantes pueden comparar el código corregido con el no corregido y entender dónde está el agujero. Node.js lo dice de forma directa en su página sobre el fin de vida: si una vulnerabilidad afecta también a una línea de lanzamiento sin soporte, para esa línea no saldrá un lanzamiento nuevo, y quienes permanecen en una línea así quedan de inmediato desprotegidos frente a los ataques que explotan la vulnerabilidad publicada.

En octubre de 2026 ocurrió exactamente eso en las dos plataformas, casi al mismo tiempo. El 21 de octubre PHP publicó parches de emergencia para dos vulnerabilidades críticas conocidas con el nombre PHP2Shell, y lanzamientos oficiales los recibieron solo las ramas de la 8.2 a la 8.5, mientras que para las ramas 7.4, 8.0 y 8.1 el equipo de seguridad preparó, con carácter excepcional, solo correcciones mínimas del código fuente para quienes compilan PHP por su cuenta. Ese mismo día Node.js publicó parches para diez vulnerabilidades, y las líneas de lanzamiento 18 y 20 no recibieron ninguno del propio proyecto. Los dos casos los hemos descrito con más detalle por separado: en el artículo sobre PHP2Shell y en el artículo sobre la actualización de seguridad de Node.js.

El segundo riesgo es menos visible, pero a largo plazo es mayor. Un runtime antiguo no deja actualizar nada de lo que está por encima de él: los plugins de WordPress, los paquetes de Composer y de npm y el propio framework dejan poco a poco de dar soporte, en sus lanzamientos nuevos, a PHP y Node.js antiguos, y por eso el sitio web tampoco puede recibir los parches de esos componentes. El propio WordPress recomienda PHP 8.3 o más reciente y, sobre las ramas más antiguas, escribe que su soporte oficial ha llegado al fin de vida y que pueden dejar el sitio web desprotegido. Así el runtime antiguo deja de ser un problema aparte y pasa a ser la capa que impide resolver todos los demás.

Cuando algo ocurre, el coste es bastante más alto que el de una actualización planificada. Un sitio web hackeado significa limpieza, restauración desde una copia de seguridad, cambio de contraseñas y de claves y, si se han visto afectados datos personales de clientes, también una valoración de si hay que notificar la brecha de datos personales a la autoridad de control, y todo ello ocurre con prisa, mientras el sitio web no funciona o muestra a los visitantes un contenido ajeno. El paso en esta situación hay que darlo de todos modos, solo que ahora toca hacerlo después del ataque y no antes, y sin la posibilidad de comprobarlo todo con calma en un entorno de prueba.

Por qué una versión obsoleta de PHP no se cambia sin más en el panel de hosting

En el panel de hosting el paso a una versión de PHP más reciente ocupa un solo clic, y precisamente por eso es traicionero: si el código no está preparado, el sitio web deja de funcionar al segundo siguiente, a menudo con la pantalla en blanco o con un mensaje de error. Al pasar a la siguiente versión mayor, PHP retira de forma deliberada funciones que durante muchos años habían quedado obsoletas. PHP 7.0 retiró la extensión mysql antigua, sobre la que se apoyaban muchos sitios web más antiguos, y PHP 8.0, en su lista de cambios incompatibles, retiró entre otras las funciones each() y create_function(), que en el código más antiguo siguen apareciendo.

En el mundo de Node.js el ejemplo clásico es la línea de lanzamiento 17, en la que el runtime pasó a OpenSSL 3.0. En el anuncio del lanzamiento Node.js advirtió de que una aplicación que, ella misma o a través de sus módulos, usa un algoritmo o una longitud de clave que OpenSSL 3.0 ya no permite de forma predeterminada, recibirá el error ERR_OSSL_EVP_UNSUPPORTED, y como solución temporal ofreció el parámetro de arranque --openssl-legacy-provider. El error a menudo no lo provocaba el código del propio proyecto, sino alguna de sus dependencias, y por eso hubo que corregirlo en un código que el equipo del proyecto ni siquiera había escrito.

Por eso el paso es trabajo de desarrollo, no un ajuste. Hay que comprobar el código contra el runtime nuevo, sustituir las funciones obsoletas, actualizar las dependencias hasta lanzamientos que lo soporten y probarlo todo en un entorno de prueba antes de que lo vean los clientes. Para un sitio web pequeño sobre una plataforma mantenida puede ser un trabajo de unas horas, pero para un sistema cuyo framework llegó al fin de vida hace varios años el paso a menudo significa también cambiar el framework, y entonces ya es un proyecto con su presupuesto y su calendario, no una tarea que se pueda hacer entre otros trabajos.

Tres caminos: actualizar, reconstruir o mantenerlo protegido

El camino lo deciden dos cosas: cuánto se ha quedado atrás el código respecto de una versión con soporte y cuánto tiempo tiene que seguir sirviendo el sitio web. Si de todos modos se prevé sustituir el sitio web por uno nuevo dentro de un año, no merece la pena hacer un gran paso en el código antiguo, pero si es la herramienta del trabajo diario de la empresa y se va a usar al menos cinco años más, una solución temporal solo aplaza lo inevitable y lo encarece. En la tabla están los tres caminos que de verdad existen, y qué resuelve cada uno y qué no.

Actualizar es la elección correcta si el sitio web se apoya en una plataforma mantenida, por ejemplo WordPress o Laravel, y lo separan uno o dos saltos grandes de una rama con soporte. Entonces el trabajo es previsible: hay que actualizar el framework y los plugins, corregir lo que encuentran las herramientas de comprobación y cambiar de PHP. Reconstruir es el camino más honesto si el propio framework está sin soporte, si el sitio web está escrito sobre PHP 5.x sin framework alguno o si ya nadie entiende el código, porque entonces el coste de la actualización se acerca enseguida al de un sitio web nuevo, y el resultado sigue siendo código antiguo.

El tercer camino se comenta menos. Un sitio web antiguo se puede mantener en una plataforma que todavía retroporta parches de seguridad a su runtime, lo aísla de los otros sitios web y bloquea patrones de ataque conocidos incluso antes del parche. No sustituye al paso, y el propio Node.js llama a un soporte así solución temporal, pero es una forma honesta de ganar tiempo: el paso se puede hacer a un ritmo planificado, y no en la semana que sigue a un aviso de seguridad. La palabra más importante aquí es «plazo», porque sin él la solución temporal se convierte en permanente.

Qué es un parche de seguridad retroportado y por qué el número de versión no dice nada de él

Una retroportación significa que alguien adapta un parche de seguridad desarrollado para un lanzamiento más reciente y lo incorpora a un lanzamiento más antiguo que el usuario ya está usando. Red Hat, que mantiene así los paquetes de sus distribuciones de Linux, escribe que solo por el número de versión el cliente no puede juzgar si su sistema es vulnerable, porque el parche cambia el paquete, pero no el número de versión. Precisamente por eso los escáneres de vulnerabilidades que miran solo el número suelen informar en estos sistemas, de forma errónea, de problemas que ya están resueltos.

En el caso de PHP y de Node.js lo hacen varios proveedores. Las distribuciones de Linux retroportan parches a sus paquetes de PHP y de Node.js durante todo el tiempo de soporte de la distribución. CloudLinux retroporta parches también a los paquetes alt-php de los servidores de hosting que funcionan con CloudLinux, incluidas las ramas cuyo soporte de PHP llegó al fin de vida hace tiempo: en el caso de PHP2Shell su página de estado anunció el 21 de octubre que preparaba paquetes corregidos para todas las ramas alt-php de la 5.2 a la 8.5, y durante la noche siguiente ya estaban disponibles. Esos paquetes forman ahora parte del soporte ampliado de la empresa TuxCare, en cuyos términos se cita como objetivo, para las vulnerabilidades de gravedad alta y crítica, un parche en un plazo de 14 días desde la publicación.

Para las líneas de lanzamiento de Node.js sin soporte el mismo servicio lo ofrecen socios comerciales a los que el propio Node.js nombra en su página de fin de vida: HeroDevs, NodeSource y TuxCare. Node.js añade enseguida que un soporte así ha de considerarse una solución temporal y que el objetivo ha de ser siempre el paso a una versión con soporte. Durante el lanzamiento de Node.js de octubre de 2026, CloudLinux retroportó parches también a sus paquetes de las líneas de lanzamiento 16, 18 y 20, que los clientes de hosting eligen en la sección Setup Node.js App de cPanel.

Comprobarlo por el número de versión no se puede. El comando php -v o node -v después de un parche retroportado muestra exactamente lo mismo que antes, y CloudLinux lo escribe con claridad en su aviso de Node.js: en las líneas sin soporte el número no cambia después de la actualización. Cambia el release number del paquete, que solo ve el administrador del servidor, así que en un hosting compartido la respuesta solo la puede dar el proveedor de hosting.

El límite hay que decirlo con la misma claridad. Un parche retroportado protege el propio PHP o Node.js, pero no protege un plugin de WordPress cuyo autor dejó de actualizarlo, un código propio con una inyección SQL ni un paquete de npm cuyos lanzamientos más recientes ya no soportan un Node.js antiguo. Además los proveedores retroportan los parches para cada línea de lanzamiento por separado, así que para cada una en concreto hay que comprobar si está en la lista, y TuxCare se reserva en sus términos el derecho a ofrecer, en lugar del parche, una medida que reduzca el riesgo.

Cuando lo antiguo no es el runtime, sino la propia plataforma

A veces el problema no está en el runtime, sino en la propia plataforma sobre la que está construido el sitio web, y entonces los parches de PHP retroportados solo ayudan en parte. El mejor ejemplo es Drupal 7: su soporte de seguridad terminó el 5 de enero de 2025, y desde entonces el propio proyecto Drupal ya no publica para él ni actualizaciones de seguridad ni de compatibilidad. Un sitio web en Drupal 7 puede funcionar sobre un PHP completamente corregido, pero su núcleo, sus módulos y su tema siguen con todas las vulnerabilidades que todavía se encuentren en ellos, porque ya nadie las corrige de forma gratuita.

También aquí hay una solución temporal de pago: la Drupal Association ha creado un programa de soporte de seguridad ampliado en el que proveedores verificados ofrecen soporte de pago, por ejemplo HeroDevs y Tag1 Consulting. Es el mismo principio que el de los parches de PHP retroportados, solo que una capa más arriba, y tiene las mismas limitaciones: aplaza el paso, pero no lo resuelve, y cada año sobre una plataforma antigua encarece el paso, porque crece la distancia hasta el lanzamiento actual y disminuye el número de desarrolladores que todavía conocen la plataforma antigua.

Por eso, antes de cualquier decisión, merece la pena comprobar todas las capas y no solo PHP: el runtime, la plataforma o el framework, los plugins o los módulos y el código propio. Si lo único anticuado es PHP, pero WordPress, Laravel u otra plataforma está mantenida, el paso suele ser un trabajo previsible. Si lo antiguo es la propia plataforma, la pregunta ya no es sobre la rama de PHP, sino sobre si trasladar el sitio web al lanzamiento nuevo de la plataforma o construirlo de nuevo, y es precisamente aquí donde la tarea de los parches retroportados es dar tiempo para tomar esa decisión sin prisa.

Cómo mantenemos en nuestro servidor un PHP y un Node.js antiguos

Nuestro hosting gestionado es un espacio en nuestro propio servidor, que funciona sobre CloudLinux, y la versión de PHP de cada sitio web se elige por separado en el panel de hosting. Ahora mismo hay PHP de la 5.4 a la 8.4, y para las aplicaciones de Node.js tanto las líneas de lanzamiento 22 y 24, que tienen soporte, como las antiguas 16, 18 y 20. Eso significa que un sitio web antiguo se puede trasladar aquí con el mismo PHP o Node.js con el que funciona ahora, y estabilizarlo primero, en lugar de cambiar también el código el día del traslado, que es la forma más segura de no romper nada durante el traslado.

Cómo funciona esto en la práctica lo pudimos medir nosotros mismos en octubre de 2026. Los parches de PHP2Shell salieron la tarde del 21 de octubre, y en nuestro servidor todas las ramas antiguas de PHP, de la 5.4 a la 8.1, funcionan ahora con paquetes que CloudLinux recompiló esa misma noche, menos de veinticuatro horas después del lanzamiento de PHP, y en los que el parche está retroportado. Las ramas de la 8.2 a la 8.4 pasaron a los lanzamientos oficiales corregidos 8.2.35, 8.3.36 y 8.4.27, y las líneas de lanzamiento 16, 18 y 20 de Node.js recibieron el 22 de octubre paquetes de CloudLinux con parches retroportados, aunque el propio proyecto Node.js no publicó parches para ellas. En las ramas antiguas el número no cambió, así que no lo comprobamos por el número, sino por el momento en que se recompilaron los ejecutables.

Eso no es todo lo que hace la plataforma. CloudLinux coloca cada cuenta de hosting en un entorno aislado propio, llamado CageFS, y en él los usuarios no ven a los otros usuarios del servidor ni siquiera sus nombres de usuario, lo que dificulta que un ataque se extienda de una cuenta a las demás. El cortafuegos de aplicaciones web (WAF) de Imunify360 empezó, en el caso de PHP2Shell, a bloquear los patrones de ataque conocidos el 21 de octubre, varias horas antes de la publicación del PHP corregido. Ninguna de estas capas vuelve invulnerable un sitio antiguo, pero juntas acortan el tiempo durante el que una vulnerabilidad conocida se puede explotar y limitan hasta dónde pueden llegar las consecuencias de un ataque.

Por eso recomendamos entender el traslado de un sitio web antiguo aquí como una solución temporal con un plazo, y no como el destino final. Trasladamos el sitio web con el mismo runtime, comprobamos que todo funciona igual que antes y después acordamos con usted hasta qué fecha y en qué orden pasa a una versión con soporte, para que la solución temporal no se vuelva permanente. Nuestro hosting gestionado empieza desde 45 € al mes, y los runtimes mantenidos, el account isolation y el cortafuegos forman parte de aquello por lo que se paga esa cantidad. Si usted tiene un sitio web con una versión antigua de PHP o de Node.js, envíenos la dirección y le diremos cuál de los tres caminos le conviene y por dónde empezar.

Cómo saber qué versión de PHP o de Node.js tiene su web

El camino más rápido es el panel de hosting. En un hosting cPanel con CloudLinux, la sección Select PHP Version muestra la versión elegida para toda la cuenta, mientras que MultiPHP Manager muestra la versión de cada dominio por separado y, si allí el dominio tiene indicada una versión propia, esa es la que manda. Para las aplicaciones de Node.js lo mismo lo muestra la sección Setup Node.js App, donde cada aplicación tiene su propia fila. Merece la pena mirar cada sitio web y no solo el principal, porque en una cuenta suele haber varios sitios web con ramas de PHP distintas, y una copia de prueba olvidada o una página antigua de una campaña a menudo sigue siendo accesible desde internet.

En un sitio web de WordPress también se puede ver en el panel de administración: en la sección Herramientas → Salud del sitio, en la pestaña Información, el bloque Servidor indica la versión de PHP sobre la que funciona el sitio web. Si no hay panel, se puede crear un archivo con la función phpinfo() y abrirlo en el navegador, pero después el archivo hay que borrarlo sin falta, porque muestra la configuración del servidor a cualquier visitante. El comando php -v aquí ayuda menos de lo que parece, porque muestra el PHP de la línea de comandos, mientras que las peticiones HTTP a menudo las atiende otra rama, elegida en el panel de hosting. En un proyecto de Node.js la línea de lanzamiento deseada la indican a menudo el campo engines de package.json o el archivo .nvmrc, pero eso es solo un deseo, y qué Node.js ejecuta de verdad la aplicación hay que mirarlo allí donde se arranca el proceso.

Si no hay acceso en absoluto, la pregunta hay que hacérsela al proveedor de hosting o al desarrollador que mantiene el sitio web. Una formulación que ahorra correspondencia: «¿Qué versión de PHP o de Node.js atiende nuestro sitio web? Si ha llegado al fin de vida, ¿recibe parches de seguridad retroportados, de dónde proceden y cuándo se actualizó el paquete por última vez? ¿Hasta qué fecha recomienda usted el paso?» La respuesta a la última pregunta dice mucho también del propio proveedor, porque si no hay fecha, normalmente tampoco hay un plan.

El paso a una versión con soporte: cómo hacerlo sin sorpresas

El paso empieza por el inventario, no por el cambio. Hay que anotar qué rama de PHP y qué extensiones necesita el sitio web, qué tareas programadas lo hacen funcionar en segundo plano, con qué sistemas externos se comunica y qué partes son críticas para el negocio, por ejemplo el formulario de pedidos, los pagos o el envío de facturas. La versión de destino conviene elegirla con margen: PHP 8.4 recibirá parches de seguridad hasta el 31 de diciembre de 2028, PHP 8.3 hasta finales de 2027, mientras que un paso a PHP 8.2, cuyo fin de vida llega ya a finales de 2026, significaría otro paso muy pronto. En el caso de Node.js el destino, en la mayoría de los casos, es la línea de lanzamiento 24.

El segundo paso es la comprobación del código, y para el código PHP se puede automatizar en gran medida. PHPCompatibility es un conjunto de reglas de PHP_CodeSniffer que comprueba si el código es compatible con una versión concreta de PHP, y Rector puede hacer de forma automática una parte de los cambios necesarios. Ninguno de los dos sustituye la comprobación de una persona, pero muestran enseguida si el volumen de trabajo se mide en horas o en semanas, y eso es precisamente lo que hace falta para decidir entre actualizar y reconstruir. En un sitio web de WordPress primero hay que actualizar los plugins y el tema, y solo después cambiar de PHP.

El tercer paso es un entorno de prueba, es decir, una copia del sitio web con el PHP o el Node.js nuevo, en la que se prueban todas las acciones críticas: formularios, pagos, envío de correo, importación y exportación. El registro de errores en esta fase es más importante que la comprobación visual, porque los avisos sobre funciones obsoletas aparecen allí mucho antes de que algo se detenga. El cuarto paso es el cambio en un momento de poca carga, con la posibilidad de volver atrás: en un hosting con elección de versión, el camino de vuelta es el mismo clic con el que se hizo el cambio, así que el riesgo es pequeño siempre que la copia de seguridad esté reciente y alguien siga el registro de errores durante la primera semana.

Para una aplicación de Node.js la lógica es la misma, solo que las herramientas son otras. El paso entre las líneas de lanzamiento grandes conviene hacerlo de una en una, ejecutando las pruebas de la aplicación después de cada una, y hay que prestar una atención particular a los paquetes con código compilado, porque se construyen para una línea de lanzamiento concreta y después del paso hay que reconstruirlos. Primero hay que actualizar las dependencias que todavía no soportan la línea nueva y solo después cambiar el propio runtime; de lo contrario los errores de los dos lados se mezclan y es difícil entender cuál de ellos provocó qué.