# PHP2Shell (CVE-2026-109618): qué es, a quién afecta y cómo saber si tu servidor está expuesto > PHP2Shell son dos fallas críticas de PHP (CVSS 9.2) que permiten tomar un servidor sin contraseña y ya se explotan. Versiones, parches y qué hacer hoy. Autor: Samuel Hinojosa (CEO & Founder, WITS) · Actualizada: 2026-10-25 · https://security.wits.mx/guias/php2shell-cve-2026-109618/ ## ¿Qué es PHP2Shell? PHP2Shell es el nombre de dos vulnerabilidades críticas de PHP, CVE-2026-109618 y CVE-2026-109619 (CVSS 9.2), que permiten ejecutar código en un servidor sin usuario ni contraseña. PHP publicó los parches el 21 de octubre de 2026 y ese mismo día se detectaron ataques reales. Si tu sitio o sistema corre en PHP, revisa hoy tu versión. La primera falla aparece cuando PHP se queda sin memoria a mitad de preparar una petición y deja datos internos a medio construir. La segunda deja estado viejo de una petición que el siguiente usuario atendido por el mismo proceso puede aprovechar. En los dos casos el resultado es el mismo: alguien de fuera puede correr sus propios comandos en tu servidor, según los [avisos oficiales de PHP](https://www.php.net/archive/2026.php). > **Lo urgente** Los detalles se filtraron en redes el 20 de octubre, antes de la fecha planeada. El 21 salió el parche y [watchTowr](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/) vio intentos de explotación en sus trampas ese mismo día. No es una falla teórica. ## ¿Qué versiones de PHP están afectadas? Todas las ramas que sirven páginas web están en riesgo, con PHP-FPM, Apache mod_php, php-cgi, LiteSpeed o FrankenPHP. PHP considera que el riesgo más alto es con Apache mod_php, porque el ataque puede funcionar antes de que corra el código de tu aplicación. | Rama | Afectadas | Versión corregida | |---|---|---| | 8.5 | antes de 8.5.12 | 8.5.12 | | 8.4 | antes de 8.4.27 | 8.4.27 | | 8.3 | antes de 8.3.36 | 8.3.36 | | 8.2 | antes de 8.2.35 | 8.2.35 (sin soporte desde el 31-dic-2026) | | 7.4, 8.0 y 8.1 | todas | sin versión oficial: paquete de tu distribución o backport mínimo de PHP | | 7.3 y anteriores | todas | no hay arreglo: hay que migrar | El caso más común en empresas mexicanas es un sistema hecho hace años que sigue en PHP 7.4 u 8.1 en un hosting o en un VPS. Ahí no basta con «actualizar PHP» desde un panel: hay que instalar el paquete corregido de la distribución, aplicar el backport o migrar a una rama con soporte. ## ¿Cómo saber si mi servidor está expuesto? Hay tres formas, de la más rápida a la más completa: 1. Desde fuera, sin tocar nada: el [chequeo gratis de Security OS](https://security.wits.mx/chequeo-php/) lee solo la respuesta pública de tu portada y te dice si anuncia una versión de PHP vulnerable o sin soporte. 2. Dentro del servidor: «php -v» en la terminal o «phpinfo()» en una página temporal que borras después. Revisa también la versión de PHP-FPM o del módulo de Apache, que puede ser distinta a la de la terminal. 3. Inventario completo: todos los servidores, contenedores y hostings donde corre PHP, empezando por los que dan a internet. Es el paso que casi nadie tiene hecho. > **Ojo con el resultado «no se ve la versión»** Que tu servidor no publique la versión de PHP es buena práctica, pero no significa que esté parchado. Solo quiere decir que desde fuera no se puede saber. Revisa dentro. ## ¿Qué hago hoy si mi PHP es vulnerable? 1. Actualiza a la versión corregida de tu rama (8.5.12, 8.4.27, 8.3.36 u 8.2.35) o al paquete actualizado de tu distribución. 2. Reinicia todos los procesos de PHP (PHP-FPM, Apache). Sin reinicio, el parche no aplica. 3. Si estás en 7.4, 8.0 u 8.1, usa el paquete de tu distribución o un proveedor de soporte extendido, o aplica el backport mínimo de PHP. Y planea la migración. 4. Si no puedes actualizar hoy, limita quién llega al servidor (firewall o WAF delante) mientras lo resuelves. PHP publicó medidas temporales que reducen el riesgo pero no lo eliminan: poner «memory_limit=-1» y un «post_max_size» bajo en la configuración del pool o de Apache (no en la aplicación), y apagar «session.upload_progress.enabled». Son para ganar horas, no para quedarse así. PHP es claro: la única solución completa es actualizar. ``` ; php.ini o pool de PHP-FPM — reiniciar todos los workers después memory_limit = -1 ; con php_admin_value, para que la app no lo cambie post_max_size = 8M ; 32M si tu sistema recibe archivos session.upload_progress.enabled = 0 ``` El 23 de octubre PHP avisó de una tercera falla, CVE-2026-115560, que solo aplica en una configuración poco común de sesiones y se corregirá en la siguiente versión. La misma línea «session.upload_progress.enabled = 0» la cubre mientras tanto. ## ¿Y después del parche? PHP2Shell no será la última. Lo que cambia el riesgo de una empresa no es reaccionar a cada noticia, sino saber qué tiene expuesto: qué versiones corren, qué puertos están abiertos y quién puede entrar. Es el mismo principio de [cerrar el puerto 22 y trabajar por capas](https://wits.mx/blog/puerto-22-abierto-seguridad-servidor-capas/), y si tu sistema vive en la nube, de [revisar la cuenta de AWS completa](https://wits.mx/blog/que-tan-expuesta-esta-tu-infraestructura-aws/). Además, PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026. Si tu sistema está en 8.1 o 8.2, la siguiente falla ya no tendrá parche oficial. Es buen momento para planear [la migración a 8.4 sin romper producción](https://security.wits.mx/guias/actualizar-php-8-4/). Y si usas Laravel o WordPress, revisa también [las alertas de esta semana](https://security.wits.mx/alertas/). > **¿Lo dejamos parchado esta semana?** En WITS hacemos [auditorías de seguridad informática](https://security.wits.mx/guias/auditoria-seguridad-informatica/) para empresas de todo México: inventario de dónde corre PHP, actualización o backport, reinicio de procesos y evidencia antes y después. Si tu sistema está en una versión vieja, también planeamos la migración. Chequeo pasivo: solo lee la respuesta pública de tu portada, igual que un navegador. Úsalo con dominios que te pertenecen o que administras. [Revisar mi PHP gratis](https://security.wits.mx/chequeo-php/) ## Preguntas frecuentes **¿Qué es PHP2Shell?** Es el nombre de dos vulnerabilidades críticas de PHP, CVE-2026-109618 y CVE-2026-109619, con CVSS 9.2. Permiten ejecutar código en el servidor sin iniciar sesión. Se corrigieron el 21 de octubre de 2026 y ya se explotan. **¿PHP 7.4 es vulnerable a PHP2Shell?** Sí. PHP 7.4, 8.0 y 8.1 están afectadas y no tienen versión oficial corregida. La salida es el paquete actualizado de tu distribución o de un proveedor de soporte extendido, el backport mínimo que publicó PHP, o migrar a una rama con soporte. **¿Cómo sé qué versión de PHP tiene mi servidor?** Dentro del servidor, con «php -v» o con «phpinfo()» en una página temporal. Revisa también PHP-FPM o el módulo de Apache, que pueden tener otra versión. Desde fuera, el chequeo gratis de security.wits.mx te dice si tu portada anuncia una versión vulnerable. **¿Basta con cambiar la configuración de php.ini?** No. PHP publicó medidas temporales (memory_limit=-1, post_max_size bajo y apagar session.upload_progress) que reducen el riesgo, pero dice claramente que ningún cambio de configuración lo elimina. La única solución completa es actualizar y reiniciar los procesos. **¿Mi sitio en WordPress está afectado?** Si tu hosting corre una versión de PHP afectada, sí: la falla es de PHP, no de WordPress. Pregunta a tu hosting qué versión usa y si ya aplicó el parche, o revísalo en el panel. **¿PHP2Shell está en el catálogo KEV de CISA?** Al 22 de octubre de 2026 no estaba en el catálogo de vulnerabilidades explotadas de CISA, aunque watchTowr ya reportaba explotación real. Que no esté en KEV no significa que no se explote. **¿Cuándo termina el soporte de PHP 8.2?** El 31 de diciembre de 2026. Después de esa fecha PHP 8.2 ya no recibe parches de seguridad, como ya pasa con 8.1 desde el 31 de diciembre de 2025. ## Fuentes - [PHP: avisos de seguridad del 20, 21 y 23 de octubre de 2026](https://www.php.net/archive/2026.php) - [GHSA-w8hw-w9fx-j79w (CVE-2026-109618)](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) - [GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) - [watchTowr: PHP CVE-2026-109618 FAQ](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/)