En resumen: Quien todavía opera PHP 8.1 o anterior ya no recibe actualizaciones oficiales de seguridad del proyecto PHP, tampoco para PHP2Shell. Por eso, actualizar PHP 8.1 a una versión con soporte no es algo opcional, sino la verdadera solución. Revisamos sus aplicaciones, probamos en una copia, migramos de forma controlada y protegemos el tiempo hasta entonces.
Por qué PHP 8.1 y anteriores es ahora un riesgo agudo
Las vulnerabilidades de PHP2Shell CVE-2026-109618 y CVE-2026-109619 permiten ejecutar código sin autenticación. Están corregidas en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para PHP 8.1 y anteriores ya no hay actualizaciones oficiales, solo backports mínimos de código fuente para 7.4, 8.0 y 8.1. Según la prensa especializada, están afectadas casi todas las versiones hasta PHP 5.4.
Algunas distribuciones y proveedores de hosting incorporan backports propios. Si su sistema está entre ellos debe confirmarlo el proveedor para el estado concreto de su paquete. Sin esa confirmación, debe partir de la base de que el servidor está abierto. Qué significa esto en detalle se describe en PHP 8.1 y anteriores: qué rige ahora.
Actualizar PHP 8.1: ¿qué versión de destino?
El destino debe ser una versión que el proyecto PHP siga soportando y que su aplicación autorice. El estado actual del soporte lo publica php.net en la página de versiones con soporte. PHP 8.2 termina el 31/12/2026; pasar a 8.2 sería, por tanto, solo un paso intermedio con un proyecto posterior próximo.
Qué versión de PHP admite su CMS o su sistema de tienda lo comprobamos con los requisitos del sistema del fabricante, por ejemplo en wordpress.org, shopware.com o typo3.org, y no de memoria. A menudo hay que actualizar primero el propio CMS. Las tiendas antiguas son un caso típico; véase Shopware 5: tiendas antiguas con una versión antigua de PHP.
¿Cómo ayuda PHP SOS en concreto?
- Inventario y protección: registramos todas las aplicaciones, su versión de PHP, el estado del CMS, las extensiones y el código propio. En paralelo aplicamos las medidas provisionales de php.net para que el riesgo baje hasta la migración; detalles en WAF y parcheo virtual.
- Comprobar la compatibilidad: contrastamos los requisitos del sistema de los fabricantes, revisamos las dependencias con Composer y buscamos funciones obsoletas en el código propio. Cómo es esto con las dependencias se describe en Revisar las dependencias de Composer en busca de vulnerabilidades.
- Prueba en una copia: la aplicación se ejecuta primero en un entorno de pruebas con la nueva versión de PHP. Los errores los corregimos allí o los documentamos para su agencia.
- Cambio con vía de retorno: el cambio en producción se hace en una ventana de mantenimiento acordada, con una copia de seguridad actual y una vía de retorno definida.
- Control posterior: revisamos los registros de errores y las funciones centrales tras el cambio y eliminamos la versión antigua de PHP cuando ya no se necesite.
Una mirada inofensiva para ver qué sitios web usan qué versión de PHP es posible en muchos sistemas a través de los pools de FPM en ejecución:
# mostrar los master y pools de PHP-FPM en ejecución
ps -eo pid,cmd | grep -E "php-fpm: (master|pool)" | grep -v grep
# versiones de PHP instaladas (Debian/Ubuntu)
ls /etc/php/
Actualizar a una versión nueva de PHP no elimina el software malicioso que se haya introducido antes. Si el servidor estuvo desprotegido en la red desde el 17/10/2026, debe incluirse una revisión de rastros.
Obstáculos típicos de la actualización
La mayoría de los problemas al cambiar de versión de PHP son previsibles si se sabe dónde buscar:
- Extensiones obsoletas: los plugins o módulos que ya no se mantienen suelen no funcionar en versiones más recientes de PHP. Necesitan un sustituto o una adaptación.
- Código propio: las funciones que PHP ha marcado entretanto como obsoletas o ha eliminado provocan avisos o interrupciones. Las comprobaciones de tipos más estrictas sacan a la luz antiguos errores de programación.
- Dependencias: las bibliotecas incluidas mediante Composer exigen a veces por sí mismas versiones nuevas y arrastran más cambios.
- Extensiones de PHP en el servidor: no toda extensión que estaba instalada con la versión antigua está disponible automáticamente para la nueva.
- Tareas cron y línea de comandos: el sitio web ya funciona con la versión nueva, pero las tareas programadas siguen llamando a la versión antigua de PHP.
Quien comprueba estos puntos antes acorta el cambio y evita sorpresas en producción.
Lo que recibe y lo que necesitamos
Recibirá una vista general de todas las aplicaciones con versión de partida y de destino, un plan de migración con el orden y los riesgos, un protocolo de pruebas, la documentación del cambio y una lista de puntos que aún debe resolver su agencia o su desarrollador.
De usted necesitamos:
- acceso al servidor o al panel y acceso a los backends del CMS
- acceso al código fuente y al repositorio en caso de desarrollos propios
- contacto con la agencia o el desarrollador que conocen la aplicación
- un entorno de pruebas o la autorización para crear uno
- ventanas de mantenimiento y una persona de contacto para la aceptación
Lo que no prometemos
No prometemos que toda aplicación antigua funcione sin cambios en una versión nueva de PHP. En sistemas sin desarrollo posterior puede ser necesaria una reforma mayor o un cambio; lo decimos con franqueza en cuanto se perfile. Las afirmaciones de compatibilidad las basamos en los datos de los fabricantes. Y las medidas provisionales no sustituyen a la migración, solo cubren el tiempo. Los riesgos a largo plazo de las versiones obsoletas se describen en Fin de vida de PHP: riesgos de las versiones obsoletas.
Preguntas frecuentes
¿Está PHP 8.1 afectado por PHP2Shell?
Según la prensa especializada, están afectadas casi todas las versiones hasta PHP 5.4. Para PHP 8.1 y anteriores el proyecto PHP no ofrece actualizaciones oficiales, solo backports mínimos de código fuente para 7.4, 8.0 y 8.1. Algunas distribuciones incorporan backports propios; eso debe confirmarlo cada proveedor.
¿A qué versión de PHP debo actualizar?
A una versión que el proyecto PHP siga soportando activamente y que el fabricante de su aplicación autorice en los requisitos del sistema. PHP 8.2 llega el 31/12/2026 al fin del soporte y, por eso, solo es un destino razonable de forma limitada.
¿No puedo simplemente cambiar la versión de PHP en el panel de hosting?
Técnicamente suele poderse con un clic. Que la aplicación siga funcionando después depende de la versión del CMS, de las extensiones y del código propio. Sin una prueba se arriesga a caídas o a funciones defectuosas, por ejemplo en la caja de una tienda.
¿Y si mi CMS no admite la nueva versión de PHP?
Entonces hay que actualizar primero el CMS, en su caso a una versión principal nueva. En sistemas sin desarrollo posterior puede ser necesario un cambio. Hasta entonces protegemos el servidor con medidas provisionales.