--- title: "PHP2Shell: ¿Actualizar PHP antiguo o migrar a Node.js?" canonical: https://wavect.io/es/blog/php2shell-legacy-php-upgrade-migration/ language: es description: "PHP2Shell en PHP 7.4, 8.0 u 8.1: parches, compatibilidad y migración a PHP con soporte o Node.js. Wavect ayuda a planificar e implementar el cambio." image: "https://wavect.io/img/blog/headers/header_php2shell-legacy-php-upgrade-migration.png" author: ["Kevin Riedl"] published: "2026-10-21" updated: "2026-10-21" reviewed: "2026-10-21" --- # PHP2Shell: ¿Actualizar PHP antiguo o migrar a Node.js? [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 min de lectura · 21 oct 2026 Última revisión 21 de octubre de 2026 [**Siguiente**](/es/blog/software-project-takeover-provider-change/) Resumen PHP2Shell reúne dos vulnerabilidades críticas corregidas en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 7.4, 8.0 y 8.1 cuentan con backports excepcionales y posibles paquetes de proveedores, aunque su soporte oficial habitual ha terminado. Primero verifica la corrección del entorno que atiende las peticiones. Después, resuelve la compatibilidad para actualizar PHP o planifica una migración gradual a Node.js u otra tecnología si tiene sentido para el negocio. Wavect ayuda a evaluar, implementar, probar y desplegar el cambio. **Ya hay un parche crítico para PHP. La pregunta difícil es qué hacer cuando la aplicación de tu empresa no puede funcionar con la versión corregida.** Si un framework antiguo, una extensión propia o un plugin abandonado mantiene a tu empresa en PHP 7.4, 8.0 u 8.1, cambiar una opción en el panel de alojamiento puede romper el producto. Necesitas una solución verificada para la exposición actual y un camino viable hacia un software que tu equipo pueda mantener. **Wavect ayuda a las empresas a actualizar aplicaciones PHP antiguas a la versión más reciente que tenga soporte y los parches necesarios.** Resolvemos problemas de compatibilidad, probamos los procesos esenciales y planificamos el paso a producción. Cuando un cambio más amplio tiene sentido para el negocio, también migramos aplicaciones PHP a Node.js/TypeScript,.NET, Java u otra tecnología adecuada que siga recibiendo mantenimiento. *Fuentes comprobadas: 21 de octubre de 2026. Las versiones indicadas estaban disponibles en esa fecha. Antes de aplicar un cambio, confirma cuál es el parche más reciente de una rama con soporte.* ## ¿Qué es la nueva vulnerabilidad PHP2Shell? **PHP2Shell agrupa dos vulnerabilidades críticas del entorno de ejecución de PHP, CVE-2026-109618 y CVE-2026-109619, publicadas junto con sus correcciones el 21 de octubre de 2026.** Pueden permitir que un atacante ejecute código en un servidor afectado sin iniciar sesión. El [aviso de CERT-EU sobre PHP](https://cert.europa.eu/publications/security-advisories/2026-018) pide aplicar los parches de inmediato e identifica como expuestas las instalaciones PHP que atienden peticiones web. | Vulnerabilidad | Qué falla | | --- | --- | | [CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) | PHP puede gestionar mal un fallo al reservar memoria y procesar después datos de una petición que nunca llegaron a inicializarse por completo. | | [CVE-2026-109619](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) | Una nueva petición puede acceder a un estado interno que quedó guardado después de liberar la memoria de una petición anterior. | El aviso oficial incluye Apache con `mod_php`, PHP-FPM, `php-cgi`, FrankenPHP y LiteSpeed. El equipo de PHP considera que `mod_php` presenta el mayor riesgo y ha demostrado que el fallo puede explotarse antes de que se ejecute el código de la aplicación. Las vías de ataque varían según la configuración. Una instalación con Nginx y PHP-FPM también requiere atención. Actualizar WordPress, Laravel, Symfony u otra aplicación no actualiza por sí solo el entorno PHP que la ejecuta. Comprueba ambas capas. ## ¿Qué versiones de PHP corrigen PHP2Shell? **Las primeras versiones estables corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.** Instala la actualización adecuada de una rama con soporte o un paquete del proveedor cuya corrección esté verificada. Un parche dentro de la rama con soporte que ya utilizas puede resolver el problema inmediato mientras preparas una actualización mayor. | Rama de PHP | Primera versión corregida | Fin del soporte de seguridad | | --- | --- | --- | | 8.5 | 8.5.12 | 31 de diciembre de 2029 | | 8.4 | 8.4.27 | 31 de diciembre de 2028 | | 8.3 | 8.3.36 | 31 de diciembre de 2027 | | 8.2 | 8.2.35 | 31 de diciembre de 2026 | | 8.1 y anteriores | Comprobar parches adaptados o actualizar | El soporte habitual del proyecto PHP ha terminado | Los plazos proceden del [calendario oficial de soporte de PHP](https://www.php.net/supported-versions.php). PHP 8.2 sí tiene una corrección para este incidente, pero su próximo fin de soporte lo convierte en un destino a corto plazo. Si quieres pasar a la versión estable más reciente, el destino verificado en la fecha de publicación es **PHP 8.5.12**, siempre que la aplicación sea compatible. Los [anuncios oficiales de versiones de PHP](https://www.php.net/) también incluyen PHP 8.6.0 RC4 con las correcciones, pero indican expresamente que es una versión de prueba que no debe utilizarse en producción. ## ¿Qué ocurre si todavía utilizas PHP 7.4, 8.0 u 8.1? **Estas ramas ya no reciben las versiones de seguridad habituales del proyecto PHP. Eso no significa que todas las instalaciones antiguas carezcan de una solución.** Ante la gravedad del problema, PHP ha publicado parches mínimos de código fuente adaptados a 7.4, 8.0 y 8.1. Las distribuciones y los proveedores de soporte a largo plazo también pueden ofrecer paquetes corregidos. Un parche adaptado, o *backport*, aplica una corrección a una base de código anterior. Puede servir de puente mientras se resuelven los problemas de compatibilidad. No devuelve a esa rama el soporte general del proyecto PHP. El [registro de versiones de PHP fuera de soporte](https://www.php.net/eol.php) sigue siendo la referencia para distinguir ambos casos. Pregunta al proveedor de alojamiento qué paquete exacto corrige **ambos CVE**, si está disponible en tu plan y quién lo instalará. Un paquete del proveedor puede conservar un número de PHP aparentemente antiguo. Por eso importan también la revisión del paquete y su aviso de seguridad. Un parche de código fuente necesita además a alguien que lo compile, pruebe, despliegue y mantenga. Si tu instalación no dispone de un paquete corregido y con soporte que pueda verificarse, ni de un backport viable, Wavect puede evaluar los obstáculos y llevar la aplicación a una rama de PHP corregida y con soporte. El trabajo incluye la aplicación y sus dependencias, además de la configuración del servidor. ## ¿Qué debería hacer una empresa de inmediato? 1. **Localizar todas las instalaciones PHP.** Incluye el portal de clientes, la web, las herramientas de administración, los subdominios antiguos, los contenedores y los productos de terceros. La [guía de inventario PHP2Shell de NCSC-NL](https://github.com/NCSC-NL/php2shell) destaca los programas y dispositivos que incorporan PHP. 2. **Confirmar qué PHP atiende las peticiones reales.** El comando `php -v` en una terminal puede mostrar una instalación distinta de la que utiliza PHP-FPM o Apache. Pide la versión que sirve la web, el origen del paquete y la compilación que está ejecutándose en cada instancia. Mantén privadas las páginas de diagnóstico. 3. **Aplicar y verificar la corrección.** Actualiza los paquetes o las imágenes correspondientes, reinicia o sustituye los procesos afectados y comprueba todas las instancias. Cambiar la etiqueta de una imagen sin volver a desplegar el servicio deja el trabajo incompleto. 4. **Probar el proceso de negocio.** Comprueba el inicio de sesión, los permisos, los pagos, las cargas de archivos, las tareas programadas y las integraciones que realmente utiliza la aplicación. 5. **Decidir cómo reducir la exposición si la actualización está bloqueada.** Sigue las recomendaciones oficiales de contención vigentes. CERT-EU recomienda valorar el aislamiento de las redes públicas cuando un servicio expuesto no puede corregirse con rapidez. Las medidas temporales de configuración de PHP cubren vías de ataque concretas. Una regla de WAF o un ajuste provisional no demuestra que el entorno PHP esté corregido. Si hay indicios de una intrusión, organiza una investigación además de aplicar el parche: actualizar no basta para demostrar que el sistema está limpio. ## ¿Por qué una actualización de PHP puede romper una aplicación antigua? **Actualizar una aplicación PHP antigua suele requerir trabajo de compatibilidad.** Las [notas de migración de PHP 7.4 a 8.0](https://www.php.net/manual/en/migration80.incompatible.php) documentan cambios de comportamiento y funciones eliminadas. La [guía de migración a PHP 8.5](https://www.php.net/manual/en/migration85.php) también pide probar las incompatibilidades antes del cambio en producción. Antes de elegir la versión de destino, comprobamos cinco obstáculos habituales: - **Soporte del framework y del CMS:** si la versión instalada, los temas y los plugins son compatibles con la versión de PHP prevista. - **Dependencias:** restricciones de Composer, paquetes abandonados y bibliotecas que necesitan sustitución. - **Extensiones y alojamiento:** controladores de bases de datos, tratamiento de imágenes, módulos propios y paquetes que el proveedor ofrece realmente. - **Funcionamiento del negocio:** cálculos, validaciones, sesiones, permisos e integraciones que deben seguir funcionando. - **Control del despliegue:** un entorno de pruebas útil, copias de seguridad, monitorización y un plan de reversión que proteja los datos nuevos. Para pasar de PHP 7.4 a 8.5, revisa también las guías de las versiones intermedias. Puedes probar esos cambios en entornos aislados sin publicar en producción cada versión intermedia obsoleta. ## ¿Conviene actualizar PHP o migrar a Node.js? **Mantén PHP si resulta viable mantener la aplicación sobre una versión con soporte. Valora una migración por etapas cuando el producto, las dependencias o los conocimientos del equipo justifiquen sustituirlo.** Resuelve la exposición actual antes de hacer que la respuesta urgente dependa de reconstruir todo el sistema. | Situación | Vía práctica | Qué debe demostrarse | | --- | --- | --- | | PHP con soporte y aplicación compatible | Aplicar el parche en la rama actual y planificar las próximas actualizaciones. | La compilación corregida funciona en todas las instancias y los procesos críticos superan las pruebas. | | PHP antiguo y aplicación viable | Usar un backport verificado si está disponible, corregir la compatibilidad y actualizar PHP. | El destino tiene soporte, las dependencias funcionan y la solución provisional tiene una fecha de finalización acordada. | | PHP antiguo y motivos más amplios para sustituirlo | Corregir el entorno actual y migrar las funciones por etapas. | Se conservan las reglas de negocio y los datos correctos, y se retiran de verdad las rutas PHP sustituidas. | Node.js/TypeScript puede encajar en un equipo que ya desarrolla aplicaciones JavaScript..NET o Java pueden encajar en un entorno empresarial existente. Otras tecnologías con mantenimiento pueden ser adecuadas tras evaluar las integraciones, el alojamiento, la experiencia del equipo y el coste operativo. Para Node.js, las [recomendaciones oficiales de versiones](https://nodejs.org/en/about/previous-releases) aconsejan utilizar Active LTS o Maintenance LTS en producción. **Eliminar PHP de un componente elimina la exposición de ese componente a estas vulnerabilidades concretas del entorno PHP.** Eso no hace que Node.js ni otra alternativa sean inmunes a sus propias vulnerabilidades. Un nuevo frontend en React, una API JavaScript delante de PHP o un WordPress headless siguen dejando componentes PHP que necesitan mantenimiento. Nuestro [servicio de desarrollo de aplicaciones web](/es/services/web-apps/) cubre la implementación tras esa decisión de arquitectura. La elección debe encajar con el producto que tu empresa necesita operar. ## Ejemplo: un portal de pedidos bloqueado en PHP 7.4 *Ejemplo ilustrativo, no un caso de cliente:* un distribuidor tiene un portal de pedidos con precios propios, permisos específicos por cliente y una integración con el ERP. Un módulo abandonado impide actualizar directamente. La primera tarea es obtener una corrección verificada para el entorno PHP o restringir el servicio expuesto mientras se prepara la solución. Después probamos si sustituir el módulo permite mantener la aplicación existente sobre PHP actual. Si funciona, actualizar PHP puede conservar años de comportamiento útil para el negocio. Si la empresa también necesita cambios más amplios en el producto, podemos trasladar una función bien delimitada a Node.js mientras el sistema PHP, ya corregido, sigue operativo. Cada paso necesita una responsabilidad clara sobre la escritura de datos, permisos compatibles y comprobaciones de pedidos perdidos o duplicados. La migración termina cuando se retiran las rutas PHP sustituidas y sus dependencias. La comparación útil es entre el coste de mantener el producto en PHP y el coste y valor de sustituirlo por etapas, incluido el periodo en el que ambos sistemas funcionan a la vez. ## Cómo ayuda Wavect con las actualizaciones y migraciones de PHP Ayudamos a empresas de Austria, la región DACH y otros países a convertir una actualización urgente de PHP en un plan que se pueda ejecutar. Nuestro [servicio de evaluación y toma de control de software](/es/services/software-takeover/) es el punto de partida cuando el código existente o la vía de actualización no están claros. | Trabajo | Qué recibe tu empresa | | --- | --- | | Evaluar la instalación | Inventario del entorno y las dependencias, exposición detectada, obstáculos de compatibilidad y una vía recomendada. | | Actualizar a PHP con soporte | Cambios en la aplicación y sus dependencias para la versión mantenida acordada, con los procesos críticos comprobados. | | Migrar desde PHP | Una implementación por etapas en Node.js/TypeScript u otra tecnología adecuada, con límites claros para los datos y las interfaces. | | Preparar producción | Un plan de despliegue probado, comprobaciones de copia y recuperación, monitorización y condiciones definidas de reversión. | | Entregar el resultado | Evidencias de versión y despliegue, resultados de pruebas, instrucciones de operación y la próxima fecha de mantenimiento. | Nuestro [servicio de calidad de software](/es/services/software-quality-assurance/) puede ayudar a verificar el despliegue frente al comportamiento de negocio acordado. Para el cambio más amplio de responsabilidad, consulta la [guía para tomar el control de un proyecto de software](/es/blog/software-project-takeover-provider-change/). El coste y el plazo dependen del framework, las dependencias sin soporte, las integraciones, la cobertura de pruebas y la ventana de mantenimiento aceptable. Acordamos el alcance después de revisar esos obstáculos. Un plan de reversión debe conservar las transacciones nuevas y no debe volver a exponer a internet un entorno con una vulnerabilidad conocida. ## ¿Qué demuestra que la actualización de PHP está completa? Pide estas evidencias antes de dar el trabajo por terminado: - **Prueba del entorno PHP:** versión exacta del proyecto PHP o paquete del proveedor, evidencias que cubran ambos CVE y comprobación de cada instancia que atiende peticiones web. - **Prueba del despliegue:** los procesos antiguos se han sustituido o reiniciado y los contenedores antiguos ya no reciben tráfico. - **Prueba del funcionamiento:** se han superado las pruebas acordadas de permisos, transacciones e integraciones necesarias, y se han revisado los errores relevantes tras el despliegue. - **Si se migra desde PHP:** un inventario que indique qué servicios PHP se han retirado y cuáles siguen corregidos y mantenidos, incluidos los paneles de administración y los backends de CMS. **Envíanos tu versión de PHP, framework o CMS, configuración de alojamiento y el proceso que debe seguir funcionando.** Si no conoces la versión, dinos quién aloja la aplicación. Podemos ayudarte a definir el alcance de la actualización o migración a partir de ahí. ## PHP2Shell y migración de PHP antiguo: preguntas frecuentes ### ¿Existe un parche de PHP2Shell para PHP 7.4 o PHP 8.1? Estas ramas sin soporte no reciben una nueva versión habitual del proyecto PHP. Como excepción, PHP ha publicado parches mínimos de código fuente para 7.4, 8.0 y 8.1, y algunos proveedores ofrecen paquetes corregidos. Verifica que cubran ambos CVE y planifica el paso a una rama con mantenimiento. ### ¿Cuál es la versión de PHP más reciente con el parche? A fecha de 21 de octubre de 2026, PHP 8.5.12 es la versión estable más reciente. PHP 8.4.27, 8.3.36 y 8.2.35 también corrigen ambas vulnerabilidades PHP2Shell. Comprueba el parche más reciente con soporte antes del despliegue; PHP 8.6 RC4 es una versión de prueba. ### ¿Están afectadas las instalaciones con Nginx y PHP-FPM? Sí. El aviso de PHP incluye PHP-FPM, además de mod_php, php-cgi, FrankenPHP y LiteSpeed. Las vías de ataque dependen de la configuración y del comportamiento de la aplicación. Utilizar Nginx no demuestra que el entorno PHP sea seguro. ### ¿Actualizar WordPress o Laravel corrige PHP2Shell? Actualizar la aplicación por sí sola no demuestra que se haya corregido el entorno PHP que la ejecuta. Confirma con el proveedor el paquete de PHP y su despliegue, y comprueba la compatibilidad de la aplicación como parte del cambio. ### ¿Deberíamos migrar de PHP a Node.js por PHP2Shell? Primero resuelve la exposición inmediata. Mantén PHP si una versión con soporte cubre las necesidades del producto. Valora una migración gradual a Node.js cuando las dependencias, los requisitos futuros o los conocimientos del equipo justifiquen el trabajo. Los servicios PHP que permanezcan también necesitan su propia corrección. ### ¿Puede ayudar Wavect si una aplicación PHP antigua falla tras actualizar? Sí. Wavect puede evaluar el fallo, resolver la compatibilidad del framework, las dependencias y las extensiones, probar los procesos de negocio y planificar un despliegue controlado. Si mantener PHP ya no es la opción adecuada, podemos definir una migración por etapas a otra tecnología. ### ¿Se puede migrar PHP sin interrumpir el servicio? Algunos cambios permiten un despliegue gradual o por etapas; otros requieren una ventana de mantenimiento. Los cambios de datos, las sesiones, las integraciones y las limitaciones del alojamiento determinan qué es posible. Acuerda las condiciones de cambio, recuperación y reversión antes de prometer un objetivo de disponibilidad. Arquitectura y plataformas ## Qué leer después Decisiones de frameworks, plataformas y sistemas con impacto a largo plazo. [Empieza aquí**Arquitectura Smart City: MQTT, LoRaWAN, Kubernetes y Terraform**](/es/blog/smart-city-architecture-best-practices-2026/) - [git-ai: fusiones concurrentes de agentes y verificación](/es/blog/git-ai-concurrent-agents-merge-verification/) - [Software empresarial: incorporar un especialista junto a tu integrador de sistemas](/es/blog/enterprise-software-specialist-system-integrator/) - [NVIDIA Run:ai open source: GPU y fábrica de software](/es/blog/nvidia-runai-open-source-gpu-software-factory/) - [GitButler para agentes de IA en paralelo: varias ramas, una compilación](/es/blog/gitbutler-parallel-ai-agents-one-workspace/) - [Vendo para SaaS: aislamiento de clientes y aprobaciones](/es/blog/vendo-saas-tenant-isolation/) [Artículo anterior**git-ai: fusiones concurrentes de agentes y verificación**](/es/blog/git-ai-concurrent-agents-merge-verification/) [Artículo siguiente**Software empresarial: incorporar un especialista junto a tu integrador de sistemas**](/es/blog/enterprise-software-specialist-system-integrator/) [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 min de lectura · 21 oct 2026 Última revisión 21 de octubre de 2026 [**Siguiente**](/es/blog/software-project-takeover-provider-change/)