# PHP 8.1 y anteriores: qué rige ahora > PHP 8.1 y anteriores no reciben actualización oficial contra PHP2Shell. Qué significan los backports de código fuente, cómo proteger su servidor y planificar el cambio. Fuente: https://phpsos.de/es/php2shell/php-8-1-und-aelter/ Actualizado: 25/10/2026 Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6 **En resumen:** Para la vulnerabilidad PHP2Shell en PHP 8.1 no hay actualización oficial. El proyecto PHP ofrece para 7.4, 8.0 y 8.1 solo backports mínimos de código fuente, no versiones terminadas. Quien opera estas versiones necesita un backport confirmado de su proveedor o medidas provisionales, y debería planificar ya el paso a una versión con soporte. ## ¿Hay una actualización contra la vulnerabilidad de PHP 8.1? No del proyecto PHP. El 21 de octubre de 2026 aparecieron correcciones oficiales solo para las ramas con soporte: 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y las versiones anteriores ya no reciben actualizaciones oficiales. Están afectadas de todos modos. Según la prensa especializada, las versiones vulnerables llegan casi de forma continua hasta PHP 5.4. Quien opera una de estas versiones accesible públicamente tiene, por tanto, una vulnerabilidad crítica con CVSS v4.0 de 9.2 sin un parche terminado. Para muchas empresas es una sorpresa, porque estos sistemas suelen funcionar durante años de forma estable y sin llamar la atención. Que una versión ya no reciba actualizaciones no se nota en el día a día hasta que aparece una vulnerabilidad como PHP2Shell. Los backports de código fuente para 7.4, 8.0 y 8.1 son una excepción y no una reanudación del mantenimiento regular. ## Qué significan los backports de código fuente Para 7.4, 8.0 y 8.1 hay backports mínimos de código fuente. Son correcciones en el código fuente que se han trasladado a esas ramas más antiguas. No son una versión oficial con número de versión, paquete probado y changelog. En la práctica significa: alguien debe adoptar el backport, recompilar PHP a partir de él, probarlo y desplegarlo. Eso puede ocurrir de tres maneras: - **Su distribución** incorpora la corrección en sus paquetes, por ejemplo en el marco de un mantenimiento a largo plazo. - **Su proveedor de hosting** construye paquetes de PHP propios e instala el backport. - **Usted mismo** o un prestador de servicios compila PHP desde las fuentes. Es exigente y hay que repetirlo con cada nueva vulnerabilidad. Si su sistema ha recibido un backport, compruébelo en el changelog del paquete: ```bash apt changelog php8.1-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # Debian/Ubuntu rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # familia RHEL ``` Los nombres de los paquetes varían según la distribución y el origen de los paquetes. Si falta una entrada, pregunte al proveedor. Cómo funciona la comprobación en detalle se explica en [Comprobar correctamente la versión de PHP y el estado del parche](https://phpsos.de/es/php2shell/php-version-pruefen/). ## Proteger el servidor antiguo hasta la migración Mientras no se ejecute ningún backport confirmado, rigen las medidas provisionales de php.net: `memory_limit=-1` no sobrescribible con límite de memoria mediante cgroup, `post_max_size` de 8M o 32M con `upload_max_filesize` por debajo y `session.upload_progress.enabled=0` en la configuración del servidor, y después reiniciar todos los workers. No son una protección completa. Detalles en [Medidas inmediatas si todavía no puede parchear](https://phpsos.de/es/php2shell/sofortmassnahmen-ohne-patch/). A ello se suman medidas que reducen la accesibilidad: áreas de administración solo mediante VPN o direcciones IP autorizadas, desactivar los sitios web que no se necesiten, limitar estrechamente los accesos al servidor. El BSI (Oficina Federal alemana para la Seguridad de la Información) recomienda desconectar temporalmente de la red los servidores sin actualización. Para una aplicación antigua y difícil de migrar, una solución aislada puede ser la respuesta más honesta que un funcionamiento en Internet abierto. > **Actuar de inmediato:** > Si un servidor con PHP 8.1 o anterior estuvo desprotegido en la red desde el 17 de octubre, tómelo en serio: el BSI esperaba una explotación rápida y a gran escala. Asegure los registros a partir del 20 de octubre y haga revisar el servidor en busca de rastros antes de migrar. ## Planificar la migración: ¿a qué versión? El destino es una versión que el proyecto PHP soporte y que su aplicación admita. PHP 8.2 cierra la vulnerabilidad desde 8.2.35, pero llega el 31/12/2026 al fin del soporte. Quien migre ahora debería, por tanto, ir a ser posible a 8.3 o superior, siempre que la aplicación lo permita. El estado actual lo indica php.net en la página de versiones con soporte. Qué versión de PHP admite su CMS o su tienda, compruébelo según los requisitos del sistema del fabricante, por ejemplo en wordpress.org, shopware.com o typo3.org. A menudo hay que actualizar primero la propia aplicación antes de poder cambiar PHP. Un caso típico son las tiendas antiguas, que describimos en la página [Shopware 5](https://phpsos.de/es/plattformen/shopware-5/). Encontrará antecedentes sobre las consecuencias de las versiones obsoletas en [Fin de vida de PHP: riesgos de las versiones obsoletas](https://phpsos.de/es/ratgeber/php-end-of-life-risiken/). | Paso | Contenido | |---|---| | Inventario | versión de PHP, aplicación, extensiones, adaptaciones propias | | Requisitos | versiones de PHP con soporte según el fabricante | | Entorno de pruebas | copia con la nueva versión de PHP, evaluar el registro de errores | | Cambio | ventana de mantenimiento planificada, vía de retorno preparada | | Trabajos posteriores | revisar los valores transitorios, configurar la vigilancia | ## ¿Cómo ayuda PHP SOS en concreto? Con la [migración de PHP 8.1 y anteriores](https://phpsos.de/es/leistungen/php-migration-legacy/) le llevamos de la versión antigua a una con soporte: - **Proteger de inmediato:** comprobar el estado del backport, aplicar medidas provisionales, reducir la accesibilidad. - **Revisar rastros:** asegurar los registros a partir del 20 de octubre y evaluarlos en busca de anomalías. - **Preparar la migración:** aclarar la compatibilidad según el fabricante, montar un entorno de pruebas, corregir errores. - **Cambiar y acreditar:** instalar la nueva versión de PHP, reiniciar todos los procesos, documentar el estado. ## 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, incluida PHP 8.1. El proyecto PHP ya no publica actualizaciones oficiales para 8.1, solo backports mínimos de código fuente. **¿Qué es un backport de código fuente?** Una corrección en el código fuente que se ha trasladado a una rama de versión anterior. No es una versión terminada: alguien debe adoptarla, recompilar PHP, probarlo y desplegarlo. Pueden encargarse su proveedor de la distribución, su proveedor de hosting o un prestador de servicios. **¿Basta con cambiar a PHP 8.2?** A corto plazo, PHP 8.2.35 cierra la vulnerabilidad. Pero PHP 8.2 llega el 31/12/2026 al fin del soporte. Quien migre de todos modos debería comprobar, por tanto, si según el fabricante la aplicación admite también 8.3 o superior. **Mi tienda solo funciona con PHP 7.4. ¿Y ahora qué?** Entonces hacen falta dos cosas en paralelo: proteger el servidor con medidas provisionales y aislamiento, y llevar la aplicación a una versión que admita una versión de PHP con soporte. Cuál es, consta en los requisitos del sistema del fabricante. ## Fuentes - [php.net: versiones con soporte](https://www.php.net/supported-versions.php) - [php.net: avisos de seguridad](https://www.php.net/) - [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released) - [Shopware](https://www.shopware.com/)