La vulnerabilidad wp2shell permite ejecución remota de código en WordPress sin autenticación. Afecta a versiones…
La Gran Guerra de PHP: crónica bélica de php2shell, las dos vulnerabilidades que han puesto en armas a media web
Fuente oficial: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 Released, anuncios de seguridad de php.net del 21 de octubre de 2026. Cobertura técnica de Sansec y Huntress.
Hoy, a las 14:00 hora de Greenwich, el mando aliado de PHP ha lanzado la mayor ofensiva de parches de su historia reciente: cuatro versiones a la vez para tapar dos agujeros que permiten ejecutar código en cualquier servidor web del planeta sin usuario ni contraseña. Como todo conflicto mundial, este también tiene un atentado que lo desencadena, un tratado roto, potencias que se movilizan, una línea defensiva que no aguanta y una retaguardia de veteranos a los que nadie va a enviar refuerzos. Vayamos por frentes.
Operación php2shell: parte de guerra
Dos vulnerabilidades, CVSS 9,2 cada una. Afectado: todo PHP desde la versión 5.4 de 2012. Es decir, tres cuartas partes de la web.
El atentado de Sarajevo: un post en Hacker News
Las guerras mundiales empiezan por un detalle. Esta, por un mensaje en Hacker News la mañana del 20 de octubre que afirmaba que dos vulnerabilidades críticas de PHP estaban a punto de salir a la luz. El post se borró en minutos. Las capturas, no. A las pocas horas, los investigadores de watchTowr confirmaron que el archiduque efectivamente había sido alcanzado: las vulnerabilidades eran reales, y lo resumieron con la resignación de quien ve caer un tratado: “se suponía que todos íbamos a esperar hasta el jueves a las once”.
El embargo diplomático, pactado para el jueves 22, saltó por los aires. El equipo de seguridad de PHP publicó esa misma tarde un aviso de movilización general: habría parches el miércoles 21 a las 14:00 UTC, un día antes de lo previsto, y se reservaba el derecho a adelantarlo más “si los detalles se hicieran públicos o apareciesen pruebas de explotación activa”. Las dos cosas ocurrieron antes del amanecer.
Las dos potencias del Eje: CVE-2026-109618 y CVE-2026-109619
No son dos ejércitos independientes, sino una alianza. Las dos vulnerabilidades son fallos de memoria que se activan igual: una petición provoca un error fatal, típicamente agotando el límite de memoria, en mitad del procesamiento. PHP se interrumpe con sus datos internos a medio inicializar y, en el siguiente turno, el mismo proceso trabajador reutiliza ese estado corrupto como si fuera legítimo. Toda la ofensiva entra por el mismo paso fronterizo: las peticiones multipart/form-data, es decir, el formulario de subida de archivos que tiene cualquier web.
| Parte de guerra | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| Nombre en clave | Corrupción por falta de memoria | Estado global zombi |
| Táctica | Use-after-free en el deserializador del progreso de subida de sesión | Use-after-free en las trazas de error fatal, con confusión de tipos vía OPcache |
| Puerta de entrada | session.upload_progress, activo por defecto | fatal_error_backtraces, nuevo en PHP 8.5 |
| Potencia de fuego | CVSS v4.0: 9,2 (crítica) | CVSS v4.0: 9,2 (crítica) |
| Resultado | Lectura de memoria y ejecución remota de código | Ejecución remota de código |
| Quién dio la alarma | Calif, el 11 de agosto | Wiz Research, el 24 de agosto |
El arma combinada se llama php2shell, un exploit que encadena las dos vulnerabilidades en un único ataque sin autenticación. Y como en toda guerra moderna, el terreno importa: bajo Apache con mod_php, un error fatal durante el arranque de la petición deja al trabajador vivo y reutilizable, lo que lo convierte en el frente más expuesto. Con PHP-FPM el trabajador muere al fallar el arranque, pero sobrevive si el error llega después, por ejemplo al deserializar o al iniciar sesión. Nadie está en terreno seguro; algunos solo tienen mejores trincheras.
Los Aliados
- El equipo de seguridad de PHP: cuatro parches simultáneos, 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y un comunicado sin matices.
- Cloudflare: desplegó reglas de cortafuegos para todos sus clientes, incluido el plan gratuito, a las 07:43 UTC, antes incluso de que existiera el parche. Su CTO, Dane Knecht, avisó de ataques tempranos.
- watchTowr, Sansec y Huntress: la inteligencia militar. Reprodujeron el fallo, documentaron el vector y publicaron las señales que delatan un ataque.
- Calif y Wiz Research: los exploradores que avisaron en agosto, dos meses antes de que nadie disparase.
El Eje y sus satélites
- Los dos CVE, operando en alianza bajo la bandera php2shell.
- El filtrador anónimo de Hacker News, que rompió el pacto y acortó el plazo de todo el mundo en un día.
- Quien subió un vídeo de explotación que duró lo justo para que lo vieran las personas equivocadas.
- Los escáneres automáticos que, desde la madrugada del 21, prueban formularios de subida en medio internet esperando encontrar un servidor sin parchear.
Los países afectados: prácticamente todos
El mapa del conflicto es el mapa de la web. Sansec enumera el frente oriental y el occidental con sus últimas versiones: WordPress 7.1.2, Magento 2.4.9, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 y WHMCS. No hay bando neutral: la vulnerabilidad está en PHP, no en la aplicación, así que ningún plugin, actualización de tema o parche de framework la cierra. Suiza no existe en esta guerra.
No existen mitigaciones completas; actualizar es la única opción segura. Se recomienda encarecidamente a todos los usuarios de PHP que actualicen de inmediato.
Comunicado del alto mando, php.net, 21 de octubre de 2026
La Línea Maginot: las mitigaciones que no bastan
Como en 1940, hay una línea defensiva impresionante que se puede rodear. Desactivar session.upload_progress cierra una de las dos puertas. Subir memory_limit a infinito evita el error fatal que lo desencadena todo, a cambio de dejar el servidor a merced de cualquier petición glotona. Bloquear las peticiones multipart en el servidor web funciona, si tu negocio no necesita que nadie suba nunca un archivo. Gina Peter Banyard, desarrolladora del núcleo de PHP, lo dejó claro: “desactivar upload_progress por sí solo no es suficiente”. Son trincheras para resistir unas horas mientras llega el parche, no una frontera.
Actualiza PHP en todos los servidores ahora.
Sansec, con la concisión de un telegrama de guerra
Los veteranos sin refuerzos: PHP 8.1 y anteriores
Toda guerra tiene su retaguardia olvidada. El proyecto PHP solo ha parcheado las ramas con soporte, de la 8.2 a la 8.5. Los servidores con PHP 8.1, 8.0, 7 o 5, que son más de los que cualquiera admitiría en voz alta, están igual de expuestos y no recibirán munición oficial. Les quedan los parches retroportados de algunas distribuciones Linux y proveedores de soporte extendido, o la rendición: desconectar, poner detrás de una VPN o migrar de una vez. Y una fecha para el calendario: PHP 8.2 firma su propio armisticio el 31 de diciembre de 2026, fecha en la que deja de recibir parches de seguridad. Hoy es su última gran batalla.
Órdenes para la tropa: qué hacer esta misma tarde
- Inventario. Localiza cada instalación de PHP, incluidas las escondidas en paneles de control, aplicaciones de proveedores y software de Windows. Huntress recuerda que las que no sabes que tienes son las que te van a comprometer.
- Parchea por orden de exposición. Primero lo que mira a internet. Si tu hosting es compartido, pregúntale al proveedor qué versión sirve y a qué hora la actualiza. Si hoy no sabe responder, cambia de hosting mañana.
- Vigila los procesos hijos. Florian Roth lo resume: la explotación aparecerá como procesos sospechosos lanzados por PHP. Un trabajador de php-fpm o apache que arranca una shell, un intérprete o una herramienta de descarga es la señal de que el enemigo ya está dentro.
- Busca señales de ataque: peticiones multipart raras, errores de memoria repetidos, oleadas de HTTP 500, cookies PHPSESSID enormes y trabajadores de PHP que se reinician sin motivo.
- Si sospechas, aísla y conserva. Logs del servidor web y de PHP, archivos nuevos en la raíz web, tareas programadas y cuentas recién creadas. No limpies antes de mirar.
Ficha técnica para quien prefiera los hechos sin metáforas bélicas
El 21 de octubre de 2026 PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, todas de seguridad, para corregir CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades de corrupción de memoria con puntuación CVSS v4.0 de 9,2 que permiten ejecución remota de código sin autenticación en cualquier despliegue que atienda peticiones web (PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed). El desencadenante es un error fatal, habitualmente por límite de memoria, durante una petición multipart; el estado corrupto sobrevive y lo reutiliza la siguiente petición del mismo proceso. Las rutas de ataque confirmadas pasan por session.upload_progress y, en PHP 8.5, por fatal_error_backtraces. Afecta a PHP desde la 5.4.0. No hay mitigación completa salvo actualizar. PHP 8.1 y anteriores no reciben corrección oficial. PHP 8.2 llega al final de su vida el 31 de diciembre de 2026.
Las guerras mundiales dejan dos lecciones que esta repite en miniatura. La primera: los pactos de silencio funcionan hasta que alguien decide que no, y entonces todo el mundo tiene un día menos. La segunda: la infraestructura que nadie mira porque “siempre ha estado ahí” es exactamente la que sostiene todo lo demás. PHP mueve tres de cada cuatro webs con lenguaje de servidor conocido, y lo hace con tan poca gloria que la mayoría de sus usuarios no sabe qué versión tiene. Hoy es un buen día para averiguarlo. Y para actualizar, claro. El alto mando ha sido explícito: es la única opción segura.
