Esta semana ha salido php2shell, el nombre con el que se conocen dos vulnerabilidades de PHP que dan ejecución remota de código sin autenticarse. Los parches son del 21 de octubre y ya hay explotación real, así que me parecía buen momento para dejarlo escrito con calma.
Aviso: no he probado el exploit ni lo he reproducido. Esto es lo que cuentan las fuentes que enlazo abajo y lo que haría yo con ello.
Qué ha pasado
Son dos CVE, CVE-2026-109618 y CVE-2026-109619, y el equipo de seguridad de PHP las puntúa con un 9.2 en CVSS v4.
CVE-2026-109618: si PHP se queda sin memoria justo cuando los datos de la petición están a medio inicializar, la limpieza posterior se fía de datos que no son válidos.
CVE-2026-109619: un use-after-free. Algo que pertenecía a una petición sigue apuntando a memoria ya liberada, y la siguiente petición que atienda ese mismo worker lo puede usar.
Lo que más me ha llamado la atención es que no hace falta cuenta, ni plugin raro, ni una configuración especial. Con mod_php, según PHP, una sola petición sin autenticar puede disparar el ataque antes de que se ejecute nada de la aplicación.
A quién afecta
A casi todo el mundo. PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Los investigadores de Calif dicen que el código afectado más antiguo que han encontrado viene de PHP 5.4.0, y que han confirmado ejecución remota antes de autenticar contra versiones concretas de WordPress, Drupal, Joomla y Magento.
Las versiones corregidas:
PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35
De 7.4 a 8.1 no hay versión oficial, solo backports mínimos del código fuente
De 5.4 a 7.3 son EOL y PHP no va a sacar nada
Si estás en una rama sin parche oficial, lo normal es tirar del paquete de tu distribución o de tu proveedor LTS, que recibieron los parches antes de que se hiciera público.
Ya se está explotando
Amazon vio un intento de explotación en sus honeypots el 17 de octubre, cuatro días antes de que se publicara nada. Nadie sabe cómo consiguió el atacante esa información. El 21 siguieron más intentos y, por los payloads y la infraestructura, parece que ya son varios grupos. watchTowr también lo ha reproducido y ve ataques.
Hay PoC circulando por ahí, pero de momento nadie ha verificado que funcionen. Yo no me fiaría de ninguno, ni para probarlo ni para descartar que estés expuesto.
Qué haría
Actualizar. Es lo único que lo arregla de verdad. Mientras tanto, PHP da dos ajustes que ayudan algo:
ini
; CVE-2026-109618: sin límite de memoria y que la app no pueda cambiarlo
memory_limit = -1
; CVE-2026-109619
session.upload_progress.enabled = 0
; solo en PHP 8.5
fatal_error_backtraces = 0
Después hay que reiniciar todos los workers de PHP, si no el cambio no se aplica. Y ojo, que esto es un parche provisional, no una solución. Un límite de memoria del contenedor o del cgroup tampoco lo cubre del todo, según PHP.
Para ver qué versión tienes:
terminal
php -v
Ese número no es fiable por sí solo. Muchas distribuciones aplican el parche sin cambiar la versión, así que puedes ir parcheado con un número "viejo" o al revés. Mira el aviso de seguridad de tu distro.
El escáner
Searchlight Cyber ha publicado un escáner open source, php2shell-scanner. En vez de fiarse de la versión, hace tres comprobaciones en orden: intenta provocar un error de memoria, mira si aparece un HTTP 500 vacío (señal de que ha muerto un worker de PHP-FPM) y solo al final lee la versión que anuncia el servidor.
Por cómo lo describen, la primera prueba intenta forzar un error de memoria, así que no lo lanzaría contra producción de nadie sin permiso por escrito y sin avisar antes.