PHP2Shell: dos fallas críticas en PHP y por qué actualizar hoy no es opcional

El 21 de octubre de 2026 la PHP Foundation publicó una actualización de emergencia para corregir dos vulnerabilidades críticas en el motor de PHP. En redes ya circulaba con el apodo PHP2Shell, y no es exagerado: PHP corre una parte enorme de la web (WordPress, Drupal, WooCommerce, Wikipedia y un largo etcétera), y las dos fallas permiten ejecución remota de código (RCE) sin necesidad de usuario ni contraseña.

Si tienes un sitio en PHP, o te lo administra alguien, este es el momento de preguntar qué versión está corriendo.

Qué se encontró

Son dos CVE, ambos con severidad 9.2 según la PHP Foundation:

• CVE-2026-109618, corrupción de memoria por falta de memoria (OOM). Una petición que llega al memory_limit en el momento equivocado puede dejar estructuras internas a medio inicializar, que PHP después trata como válidas. En Apache con mod_php, una petición sin autenticar puede dispararlo antes de que se ejecute una sola línea de código de la aplicación, y se demostró RCE con configuración por defecto. También se confirmó RCE en PHP-FPM a través de rutas de código de la aplicación.
• CVE-2026-109619, estado global obsoleto. Un error fatal en el punto equivocado puede dejar el estado interno apuntando a memoria de una petición anterior, que luego usa otra petición en el mismo worker. Se confirmó un use-after-free y la caída del worker, y se demostró RCE contra una aplicación real en Apache con mod_php.

En términos prácticos: un atacante puede tomar control del servidor, modificar archivos o robar datos, sin pasar por el login de tu sitio.

Cómo se descubrió

Lo llamativo es el origen. Según la PHP Foundation, un desarrollador del núcleo de PHP vio las primeras señales del problema de OOM en 2024. Después llegaron reportes sobre la misma causa raíz desde Calif, Wiz y OpenAI, y Trail of Bits también estaba auditando PHP. La IA tuvo un rol importante en encontrar errores que llevaban más de una década en código muy revisado: es una señal de que la ventana entre "alguien encuentra un fallo" y "alguien lo explota" se está acortando.

Cómo se filtró

Los identificadores CVE empezaron a circular el 20 de octubre, sin detalles técnicos. Luego Calif publicó por error un video con una prueba de concepto funcionando contra varios objetivos, y las copias se difundieron en redes antes de la liberación coordinada. La PHP Foundation indicó que, al momento de la divulgación pública, no había identificado exploits funcionales circulando, pero también que las pruebas de concepto estaban apareciendo. Ese es justo el escenario donde conviene moverse rápido.

Qué hacer ahora

1. Actualiza PHP a una versión corregida: 8.5.12, 8.4.27, 8.3.36 u 8.2.35. Los detalles por sistema están en el anuncio oficial en php.net.
2. Si tu hosting es compartido o administrado, escríbele a tu proveedor y pídele confirmación explícita de que ya aplicó el parche. No asumas que es automático.
3. Si usas Docker, reconstruye la imagen con una base actualizada; reiniciar el contenedor no alcanza.
4. Si estás en una rama de PHP ya sin soporte, no hay parche para ti: planifica la migración a una rama vigente cuanto antes.
5. Revisa accesos y logs de los últimos días por si hubo actividad rara, y confirmá que tus respaldos recientes estén sanos y fuera del servidor (tenemos una guía de respaldos si necesitas un punto de partida).
6. Mantén actualizado todo lo demás: WordPress, temas y plugins son la otra puerta de entrada de siempre.

La parte incómoda es la fragmentación: millones de sitios, sobre todo de pymes y organizaciones con poco soporte técnico, tardan semanas o meses en parchear. Los atacantes lo saben.

Cómo lo trabajamos en brauliotapia.cl

Un parche de emergencia es una buena noticia, pero la seguridad no se agota en reaccionar a cada alerta. Lo que hacemos en cada proyecto y sitio que tenemos a cargo es reducir la superficie de ataque antes de que aparezca la próxima falla:

• Menos piezas expuestas. Cuando el proyecto lo permite, preferimos arquitecturas estáticas o con backend mínimo. Este mismo sitio es estático y corre sobre Cloudflare Pages: no hay un PHP de por medio que parchear.
• Cabeceras de seguridad y CSP estricta en el sitio: Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, una política de contenido que limita desde dónde se puede cargar código y permisos del navegador reducidos al mínimo.
• Secretos fuera del código. Claves de API y credenciales viven como variables de entorno en la plataforma, nunca en el repositorio.
• Formularios protegidos con verificación anti-bot del lado del servidor.
• Dependencias al día. Revisamos y actualizamos lo que usa cada proyecto, en lugar de dejar que se acumule deuda técnica.
• Hardening en WordPress cuando es la herramienta correcta: actualizaciones, permisos mínimos, 2FA y respaldos verificados. Escribimos una guía de hardening de WordPress con los pasos concretos.

Nada de esto es mágico ni nos hace inmunes. Lo que sí hace es que, cuando sale un PHP2Shell, la pregunta no sea "¿estamos expuestos?" sino "¿qué falta por parchear?", y que la respuesta sea corta.

¿Tu sitio corre en PHP y no sabes en qué versión?

Es una pregunta que se responde en minutos y conviene hacerla hoy. Si quieres que revisemos tu sitio, tu hosting o tu WordPress, escríbeme y lo vemos.

Fuentes

• PHP Foundation: Today's PHP security release and how we're strengthening PHP security
• NVD: CVE-2026-109618 y CVE-2026-109619