PHP2Shell: dos RCE críticas en PHP y cómo parchear hoy

Este artículo se escribió el 21 de octubre de 2026, el mismo día de los parches. La situación sigue cambiando, así que contrasta los datos con el aviso oficial de PHP.

El 20 de octubre se filtraron los detalles de dos vulnerabilidades críticas de ejecución remota de código en PHP, antes de la divulgación coordinada. El 21 de octubre salieron los parches. Las llaman PHP2Shell y son CVE-2026-109618 y CVE-2026-109619.

Si tienes PHP en producción, esto va primero en tu lista de hoy. Si solo escribes Python, sigue leyendo: en la última sección te dejo qué revisar de tu lado.

Qué pasó

Según el análisis de Tenable, ambas fallas tienen un CVSS v4.0 de 9.2 y permiten ejecución remota de código sin autenticación:

• CVE-2026-109618: un problema en el manejo de errores de memoria agotada (OOM). Una petición interrumpida deja datos a medio inicializar.
• CVE-2026-109619: PHP conserva estado propio de la petición después de que la memoria que lo respalda ya fue liberada (use-after-free).

Lo que lo hace grave es el alcance. Afecta a los SAPI que sirven peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. De todos, mod_php es el de mayor riesgo, porque existe un exploit que dispara el ataque con una sola petición no autenticada antes de que se ejecute código de tu aplicación. Eso significa que no importa si tu WordPress, tu Laravel o tu código a medida está bien escrito.

Según Tenable, Calif afirma haber confirmado RCE previa a la autenticación contra versiones específicas de WordPress, Drupal, Joomla y Magento. Cloudflare reporta ataques tempranos y watchTowr dice que ya observa intentos de explotación. Ten en cuenta que el código de exploit circula públicamente, pero la propia Tenable no pudo verificar que funcione, y la PHP Foundation dijo que no identificó exploits funcionales al momento del lanzamiento. Mi recomendación es asumir que sí funciona.

Versiones corregidas

Las ramas 7.4, 8.0 y 8.1 ya no tienen soporte oficial, pero el equipo de seguridad de PHP publicó backports mínimos en código fuente. Las distribuciones Linux y los proveedores LTS recibieron los parches antes del lanzamiento público, así que lo más práctico es revisar el aviso de tu proveedor.

Para las ramas 5.4 a 7.3 no hay ninguna corrección. Calif indica que el código afectado más antiguo que encontró viene de PHP 5.4.0. Si sigues ahí, tienes un problema más grande que este CVE.

Qué hacer, en orden

1. Averigua qué versión corres realmente. php -v en el host no basta: en contenedores y en servidores con varias versiones, el SAPI que atiende tráfico puede ser otro. Revisa también phpinfo() en un entorno controlado, no en producción abierta.
2. Actualiza. Es la única corrección completa. Prioriza los servidores con mod_php, luego el resto de SAPI expuestos a internet.
3. Usa paquetes de tu distribución si dependías de repositorios voluntarios. El repositorio rpms.remirepo.net anunció que no tendrá actualizaciones el día de la publicación, según Help Net Security.
4. Reinicia los workers de PHP después de cualquier cambio de configuración o de versión.

Si no puedes parchear hoy

Tenable lista mitigaciones parciales. Ninguna reemplaza la actualización:

• Para CVE-2026-109618: fija memory_limit=-1 de forma que las aplicaciones no puedan sobrescribirlo.
• Para CVE-2026-109619: session.upload_progress.enabled=0 y, en PHP 8.5, fatal_error_backtraces=0.
• Un límite de memoria a nivel de contenedor o cgroup ayuda como frontera de disponibilidad, pero no es una mitigación completa.
• Cloudflare desplegó reglas WAF para los vectores conocidos, incluso en el plan gratuito. Solo cubren el tráfico que pasa por Cloudflare y la propia empresa las llama un parche temporal.
• El NCSC del Reino Unido sugiere considerar dejar fuera de línea los sistemas que no puedas corregir. CERT-EU recomienda aislar las aplicaciones expuestas a internet hasta verificar el parche.

Y si eres de Python

Escribo sobre todo Python, y la tentación es decir "esto no me toca". No es tan simple.

CPython también es un runtime escrito en C, y también publica correcciones de seguridad. Hoy mismo, la página de descargas de python.org muestra las versiones 3.15.1, 3.14.9 y 3.13.17, todas del 21 de octubre, y 3.12.15 del 30 de septiembre. No encontré notas de seguridad específicas para esas versiones, así que no afirmo que corrijan nada concreto. Lo que sí aparece en esa página es un aviso de seguridad: el CA raíz de emSign fue removido de certifi, y piden actualizar certifi, pip, uv y sigstore.

Lo útil aquí no es comparar quién tiene más CVE. Es revisar tu propia superficie:

• ¿Qué versión de Python corre en tu imagen base y cuándo la actualizaste por última vez?
• ¿Tu servidor depende de certifi o pip desactualizados dentro de un contenedor viejo?
• ¿Tienes un proceso para enterarte de un parche el día que sale, o te enteras por Twitter?

Si quieres ordenar lo último, te dejo cómo manejar dependencias en Python para que actualizar sea una tarea rutinaria y no una emergencia.

Also available in English.

Resumen

• PHP2Shell son dos RCE críticas (CVSS 9.2) que afectan a cualquier PHP que sirva peticiones web.
• Corrige con 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o con el backport de tu proveedor si estás en 7.4 a 8.1.
• mod_php primero. Reinicia los workers.
• Hay intentos de explotación reportada por varias firmas de seguridad, aunque la verificación del exploit público no es unánime.
• Esta historia avanza rápido: revisa el aviso oficial de PHP antes de tomar decisiones.

Fuentes: Tenable, Help Net Security, Qualys, watchTowr, python.org.