# PHP2Shell: dos fallos críticos en PHP, riesgos y soluciones > PHP2Shell: descubre las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, las versiones vulnerables de PHP y las medidas urgentes para proteger tus sitios y aplicaciones. Web y ciberseguridad ## PHP2Shell: dos fallos críticos en PHP, riesgos y soluciones Dos fallos críticos afectan al propio motor PHP. Aquí explicamos sus mecanismos, las versiones vulnerables, los sistemas expuestos y los pasos que debes seguir para corregir y comprobar tus aplicaciones. ![PHP2Shell-Runtime-Under-Attack.webp](https://sdx-development.com/media/News/PHP2Shell-Runtime-Under-Attack.webp?v=1792605446) [Web y ciberseguridad](https://sdx-development.com/es/noticias/web-ciberseguridad)Publicado el 21 de octubre de 2026 a las 20:00 El 21 de octubre de 2026, el equipo de seguridad de PHP publicó cuatro versiones correctivas para dos vulnerabilidades críticas del motor: **CVE-2026-109618** y **CVE-2026-109619**, también conocidas como **PHP2Shell**. En determinadas configuraciones, podrían permitir que un atacante no autenticado ejecute código en un servidor web. El problema va más allá de un CMS, un framework o un proveedor de alojamiento: afecta al **motor PHP del lado del servidor**. Tanto si ejecuta WordPress, Drupal, PrestaShop, Laravel, Symfony o una aplicación desarrollada a medida, cualquier sitio que utilice una versión vulnerable debe evaluarse y corregirse. El nivel real de exposición dependerá después de la configuración, los procesos PHP y los accesos de red. Lo esencial ## Dos fallos críticos, una corrección prioritaria **9,2/10 (CVSS v4.0)** para cada vulnerabilidad. Las versiones corregidas de PHP publicadas el 21 de octubre de 2026 son **8.2.35, 8.3.36, 8.4.27 y 8.5.12**. No existe una solución provisional completa: solo la aplicación de una corrección adecuada cubre todas las vías de explotación conocidas. **En este artículo** [La alerta](https://sdx-development.com/es/noticias/web-ciberseguridad/php2shell-dos-fallos-criticos-php-riesgos-soluciones#alerte-php) [Los dos fallos](https://sdx-development.com/es/noticias/web-ciberseguridad/php2shell-dos-fallos-criticos-php-riesgos-soluciones#mecanismes-php) [¿A quién afecta?](https://sdx-development.com/es/noticias/web-ciberseguridad/php2shell-dos-fallos-criticos-php-riesgos-soluciones#applications-exposees) [Versiones corregidas](https://sdx-development.com/es/noticias/web-ciberseguridad/php2shell-dos-fallos-criticos-php-riesgos-soluciones#versions-php) [Comprobar la exposición](https://sdx-development.com/es/noticias/web-ciberseguridad/php2shell-dos-fallos-criticos-php-riesgos-soluciones#audit-php) [Plan de corrección](https://sdx-development.com/es/noticias/web-ciberseguridad/php2shell-dos-fallos-criticos-php-riesgos-soluciones#plan-correction) [Medidas temporales](https://sdx-development.com/es/noticias/web-ciberseguridad/php2shell-dos-fallos-criticos-php-riesgos-soluciones#mesures-temporaires) [Preguntas frecuentes](https://sdx-development.com/es/noticias/web-ciberseguridad/php2shell-dos-fallos-criticos-php-riesgos-soluciones#faq-php) [Fuentes](https://sdx-development.com/es/noticias/web-ciberseguridad/php2shell-dos-fallos-criticos-php-riesgos-soluciones#sources-php) ## ¿Por qué es excepcional esta alerta de PHP? El 20 de octubre, el equipo de PHP anunció una publicación urgente de seguridad. El 21 de octubre, publicó las correcciones y dio a conocer los detalles técnicos. CERT-FR y CERT-EU recomiendan una remediación inmediata, e incluso aislar los servicios expuestos a Internet cuando no sea posible aplicar una corrección rápidamente. Las dos vulnerabilidades pertenecen a la categoría **RCE** (*Remote Code Execution*, o ejecución remota de código). A diferencia de un error que afecta a una extensión concreta de WordPress o a una página de una aplicación, estas vulnerabilidades se encuentran dentro del runtime de PHP, que interviene en el procesamiento de solicitudes HTTP, formularios, memoria y estado de los procesos. **«Sin autenticación» no significa «compromiso automático».** El ataque no requiere necesariamente una cuenta de usuario, pero su viabilidad varía según el modo de ejecución y la configuración. La gravedad reside en el potencial de acceder al sistema antes de que los controles habituales de la aplicación puedan actuar. ## Entender las dos vulnerabilidades Los defectos tienen algo en común: se utilizan datos internos cuando su estado en memoria ya no es fiable. Sin embargo, explotan **dos mecanismos distintos**. CVE-2026-109618 · corrupción de memoria ### Una interrupción durante una asignación de memoria Cuando se alcanza un límite de memoria (*out-of-memory* u OOM), PHP utilizaba una salida abrupta basada en ` longjmp() `. Si la interrupción se produce durante la inicialización de estructuras vinculadas a una solicitud, el proceso de limpieza posterior puede interpretar datos incompletos como si fueran válidos. Esta corrupción puede abrir la puerta a la ejecución de código. CVE-2026-109619 · use-after-free ### Un estado interno persiste tras una solicitud anterior Algunos estados globales (errores, sesiones, extensiones u objetos) pueden conservar una referencia a una zona de memoria que ya se ha liberado. Si el mismo proceso PHP atiende después otra solicitud antes de reinicializar ese estado, puede reutilizar la referencia obsoleta. Se trata de un defecto de tipo *use-after-free*. ### Por qué importan los formularios y las solicitudes HTTP En el primer fallo, el procesamiento de ciertas solicitudes multipart, como las que se utilizan para formularios y archivos enviados al servidor, puede provocar una presión inesperada sobre la memoria. En el segundo, un error fatal o ciertos diagnósticos pueden dejar un estado que se utilizará en una solicitud posterior. Los avisos técnicos de PHP detallan estas categorías de escenarios, aunque no siempre es necesario que haya un formulario vulnerable en el código de la aplicación. Para **Apache con ` mod_php `**, el equipo de PHP considera que el riesgo es especialmente elevado: una demostración muestra que una solicitud no autenticada puede alcanzar la vía vulnerable antes de que se ejecute el código de la aplicación. **PHP-FPM tampoco está fuera de peligro**: el procesamiento de errores y las vías de explotación son distintos, pero PHP también lo incluye entre los entornos afectados. Una explotación satisfactoria puede permitir actuar con los privilegios del proceso PHP: leer archivos a los que tenga acceso el servicio, obtener secretos de la aplicación, comprometer una base de datos si se dispone de sus credenciales, modificar contenido o interrumpir el servicio. El alcance de las consecuencias depende de los permisos, el aislamiento y la arquitectura del servidor. ## ¿Qué sitios, aplicaciones y entornos están afectados? El ámbito afectado no se limita a los sitios que muestran visiblemente «PHP». Una aplicación puede utilizar PHP detrás de un proxy, una CDN, un contenedor o una plataforma gestionada. CERT-EU cita las principales interfaces web que ejecutan PHP: ` mod_php `, PHP-FPM, ` php-cgi `, FrankenPHP y LiteSpeed. | Entorno | Qué comprobar | | --- | --- | | WordPress, Drupal, PrestaShop, Magento | El runtime PHP real del servidor, independientemente de la versión del CMS | | Symfony, Laravel, aplicación PHP personalizada | El runtime de las instancias web, las API, los workers y los despliegues afectados | | Apache + mod\_php | Actualización prioritaria: la vía crítica puede activarse antes de que se ejecute el código de la aplicación | | Nginx + PHP-FPM, php-cgi, LiteSpeed, FrankenPHP | Versión del runtime que realmente cargan los procesos del servicio | | Docker, Kubernetes, imágenes CI/CD | Imagen base, contenedores efectivamente redesplegados y réplicas que aún estén activas | | Alojamiento compartido o plataforma gestionada | Versión corregida o parche retroportado confirmado por el operador | **Importante:** actualizar WordPress, una extensión o una dependencia de Composer no corrige el motor PHP. A la inversa, un sitio con código de aplicación bien escrito puede seguir expuesto si su intérprete no ha recibido la corrección. ## Versiones vulnerables y versiones corregidas CERT-FR considera afectadas las ramas antiguas y todas las versiones anteriores a las siguientes versiones corregidas: | Rama | Versiones que deben corregirse | Versión correctiva de PHP | | --- | --- | --- | | PHP 8.5 | 8.5.0 a 8.5.11 | 8.5.12 | | PHP 8.4 | 8.4.0 a 8.4.26 | 8.4.27 | | PHP 8.3 | 8.3.0 a 8.3.35 | 8.3.36 | | PHP 8.2 | 8.2.0 a 8.2.34 | 8.2.35 | | PHP 8.1 y anteriores | Ramas sin soporte oficial | Hay que comprobar si el proveedor ofrece una migración o un parche retroportado | El proyecto PHP ya no publica versiones oficiales para PHP 8.1 ni para las ramas anteriores. No obstante, algunos proveedores de Linux y servicios de soporte de larga duración ofrecen **parches retroportados**, sin cambiar de versión mayor o menor. Por tanto, un número de versión antiguo no demuestra por sí solo que falte la corrección: hay que consultar los boletines de la distribución y el estado del paquete instalado. PHP también ha proporcionado retroportaciones mínimas de código fuente para las ramas 7.4, 8.0 y 8.1; esto no significa que vuelvan a contar con soporte estándar. **PHP 8.2 llega al final de su ciclo de vida el 31 de diciembre de 2026**: lo ideal es acompañar la corrección inmediata con un plan de migración. ## ¿Cómo saber si un sitio utiliza una versión vulnerable? Un problema habitual es comprobar la versión de PHP equivocada. En una misma máquina, la versión que se ejecuta en el terminal puede diferir de la que utilizan Apache, PHP-FPM, un contenedor o un subdominio. Por tanto, la verificación debe centrarse en **el servicio web que está realmente en producción**. Primera comprobación ### Inventario y versión Inventariar los dominios, las API, los pools de PHP-FPM, las versiones de los paquetes, las imágenes de contenedor y las tareas en segundo plano. Comprobar las versiones efectivas mediante la administración de la plataforma, los comandos del sistema o una comprobación temporal protegida desde la aplicación. Segunda comprobación ### Estado real de la corrección Comparar la información con el aviso de PHP o el boletín del proveedor. Tras aplicar la corrección, comprobar que se hayan reiniciado los servicios o desplegado los nuevos contenedores. Confirmar que ningún worker antiguo siga recibiendo tráfico. Algunos comandos de diagnóstico, que deben adaptarse al sistema: ``` php -v php --ini ``` ` php -v ` y ` php --ini ` describen el entorno CLI, **no necesariamente el que procesa las solicitudes HTTP**. Para PHP-FPM, comprueba el binario del pool correspondiente, sus archivos de configuración y el servicio que se está ejecutando. En Docker o Kubernetes, comprueba tanto la imagen reconstruida como los contenedores o pods activos. No dejes nunca una página ` phpinfo() ` accesible públicamente para realizar esta comprobación. ## Plan de corrección: ocho acciones que emprender 1. **Inventariar.** Enumerar las aplicaciones PHP expuestas e identificar sus versiones, modos de ejecución y responsables. 2. **Priorizar.** Empezar por los servicios accesibles desde Internet, en especial las instancias de Apache ` mod_php ` y las aplicaciones que contengan datos sensibles. 3. **Hacer una copia de seguridad.** Conservar las configuraciones, los datos y las imágenes de despliegue, y preparar un plan de reversión que no implique volver de forma permanente a una versión vulnerable. 4. **Corregir.** Instalar una versión segura de PHP o los paquetes retroportados que haya validado expresamente el proveedor. 5. **Reiniciar o redesplegar.** Renovar todos los procesos afectados: workers de Apache o FPM, contenedores, pods y demás instancias. 6. **Verificar que la corrección se haya aplicado efectivamente.** Comprobar la versión o la referencia del paquete que realmente atiende las solicitudes en todas las instancias. 7. **Probar los recorridos esenciales.** Comprobar la autenticación, los formularios, las cargas de archivos, las API, los posibles pagos, las tareas programadas y los registros de errores. 8. **Supervisar y documentar.** Vigilar las anomalías, conservar las pruebas de la corrección e investigar indicios de compromiso anteriores a la actualización. Si existen indicios sólidos de compromiso, una actualización no elimina necesariamente un acceso malicioso ya obtenido. En ese caso, hay que aislar el sistema afectado, preservar los registros, examinar los archivos y secretos expuestos y aplicar un procedimiento de respuesta a incidentes adecuado. ## ¿Qué hacer si no es posible actualizar de inmediato? PHP insiste en este punto: **ninguna medida provisional ofrece una protección completa**. CERT-EU recomienda considerar el aislamiento temporal de los servicios públicos cuya corrección no pueda aplicarse y verificarse. Precaución ## Un firewall de aplicaciones no sustituye a un runtime corregido Las reglas de WAF, la limitación de solicitudes multipart o la desactivación de ciertas funciones pueden reducir la exposición a escenarios documentados, pero no eliminan las dos vulnerabilidades. Además, algunas protecciones pueden bloquear formularios o cargas legítimas de archivos: evalúa sus consecuencias antes de implementarlas. A modo de ejemplo, CERT-FR menciona desactivar el seguimiento del progreso de las cargas de sesión mediante ` session.upload_progress.enabled=Off ` y, según el caso, filtrar el tráfico multipart. El proyecto PHP también cita ajustes de ` memory_limit ` para limitar algunas vías del primer fallo. Estas medidas son parciales y, en ocasiones, difíciles de aplicar de forma segura: debe decidirlas el administrador responsable, verificarse en todos los procesos y retirarse o reevaluarse después de instalar las correcciones. No concluyas que no hay riesgo simplemente porque haya un WAF activo, un escáner externo no detecte nada o los errores de PHP no aparezcan en el navegador. Ninguno de estos indicios demuestra que se haya corregido la memoria del runtime. ## Preguntas frecuentes para propietarios de sitios ### Mi sitio de WordPress está actualizado: ¿estoy protegido? No necesariamente. WordPress y sus extensiones son componentes distintos del motor PHP. Hay que actualizar cada uno de estos niveles y, en particular, comprobar la versión de PHP que realmente utiliza el sitio. ### Mi sitio utiliza Nginx y PHP-FPM: ¿estoy menos expuesto? La vía de explotación demostrada con ` mod_php ` resulta especialmente preocupante, pero PHP también incluye PHP-FPM entre los entornos que deben corregirse. El nivel de riesgo varía según la arquitectura; no debe confundirse «menos directamente demostrado» con «no vulnerable». ### Uso alojamiento compartido: ¿quién debe actuar? El operador suele gestionar el motor PHP, pero las responsabilidades dependen del contrato y del servicio contratado. Pide confirmación de que se haya aplicado la corrección, consulta los avisos de mantenimiento y realiza pruebas funcionales en tu sitio. ### Mi aplicación está en Docker: ¿basta con actualizar el servidor? No, si PHP está incluido en las imágenes de la aplicación. Hay que reconstruirlas a partir de una imagen base corregida, redesplegar todas las réplicas y comprobar que no quede ninguna instancia antigua en producción. ### ¿Ya se están produciendo ataques? El 21 de octubre, CERT-EU indicó que circulaban públicamente pruebas de concepto, lo que aumenta la probabilidad de ataques. Esto no permite afirmar que un sitio concreto haya sido comprometido. Para los servicios expuestos, la prioridad sigue siendo aplicar rápidamente la corrección y vigilar los registros. ### ¿Basta con ejecutar un comando de actualización? Es un paso, no una prueba definitiva. Hay que comprobar que se utiliza la fuente de paquetes adecuada, que se han actualizado todas las instancias, que los procesos se han reiniciado correctamente y que la aplicación funciona después del despliegue. ## Qué cambia esta alerta en la seguridad de las aplicaciones web PHP2Shell recuerda una realidad que suele pasarse por alto: la seguridad de un sitio no depende únicamente de la calidad del código de la aplicación, de las extensiones instaladas o del framework. También depende del motor que ejecuta ese código, de la gestión de su memoria y de la disciplina con que se actualizan los entornos de producción. La estrategia adecuada es concreta: **inventariar, corregir, redesplegar, verificar y supervisar**. Las organizaciones que no puedan aplicar rápidamente las correcciones deben decidir expresamente si mantienen sus servicios expuestos a Internet. ## Fuentes y documentación de referencia *Artículo basado en los boletines públicos del 21 de octubre de 2026. Los mantenedores y proveedores de las distribuciones pueden ampliar las instrucciones de remediación.* Consultar los avisos oficiales 5 referencias - [PHP — aviso de seguridad del 21 de octubre de 2026 y versiones corregidas](https://www.php.net/index.php#2026-10-21-1). - [PHP / GitHub — CVE-2026-109618, corrupción por desbordamiento de memoria](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w). - [PHP / GitHub — CVE-2026-109619, estado global obsoleto](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp). - [CERT-FR — alerta y medidas para reducir la exposición](https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-014). - [CERT-EU — aviso de seguridad 2026-018](https://cert.europa.eu/publications/security-advisories/2026-018/). WEB Y CIBERSEGURIDAD ## Una base web fiable se prepara antes de que ocurra un incidente. La auditoría del código, las dependencias y las rutas sensibles convierte una alerta técnica en un plan de acción controlado. - Prioridades y riesgos claramente definidos - Correcciones probadas con un plan de reversión - Mantenimiento organizado a largo plazo [Solicitar una auditoría](https://sdx-development.com/es/contacto)[Ver servicios](https://sdx-development.com/es/servicios) --- [Consultar la página HTML](https://sdx-development.com/es/noticias/web-ciberseguridad/php2shell-dos-fallos-criticos-php-riesgos-soluciones)