Dos agujeros críticos en PHP, y cómo está este sitio
El 21 de octubre de 2026 el equipo de PHP publicó cuatro versiones nuevas —8.5.12, 8.4.27, 8.3.36 y 8.2.35— para tapar dos fallos graves. Los dos permiten que alguien de fuera ejecute el código que quiera en el servidor sin identificarse: lo que en la jerga se llama ejecución remota de código. Están catalogados como CVE-2026-109618 y CVE-2026-109619, llevan el apodo de «php2shell» y puntúan 9,2 sobre 10 en gravedad.
Qué se rompe
Los dos fallos viven en las tripas de PHP: en cómo reparte la memoria y en cómo trata los errores. Son dos sitios que toca casi cualquier petición, y eso es lo que los hace peligrosos. No hace falta que tu web use una función rara: basta con que PHP esté atendiendo visitas.
El primero se dispara cuando una petición llega justo al límite de memoria. Si ocurre en el momento exacto, PHP se queda con datos a medio construir y después los da por buenos. Con Apache y su módulo mod_php, una petición anónima puede provocarlo antes de que se ejecute una sola línea de la web, y hay una explotación completa demostrada con la configuración de serie.
El segundo es un resto mal limpiado. Un error fatal puede dejar al proceso apuntando a memoria de una petición anterior que ya se liberó, y la siguiente petición que caiga en ese mismo proceso puede leer y usar esos restos. Lo han demostrado contra una aplicación real.
Quién corre más riesgo
- Apache con mod_php: el más expuesto, con exploit demostrado y sin necesitar nada de la aplicación.
- php-fpm, php-cgi, FrankenPHP y LiteSpeed: también afectados. En php-fpm hay explotación confirmada, pero depende de lo que haga la aplicación.
- Cualquier PHP que atienda peticiones desde internet, con prioridad para lo que está expuesto a la intemperie.
Hasta el 23 de octubre, la agencia de ciberseguridad de Estados Unidos (CISA) decía que no tenía constancia de ataques reales. No es consuelo: el aviso se filtró dos días antes, ya circulan pruebas de concepto, y esto se mide en días, no en meses.
Qué hay que hacer
Actualizar. Los propios avisos dicen que la única corrección completa es subir de versión y que los apaños de configuración tapan solo una parte.
- Si puedes: pasa a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 y reinicia los procesos de PHP. No basta con actualizar el paquete si el proceso viejo sigue levantado con el fallo dentro.
- Si no puedes actualizar todavía: CISA recomienda apartar esos sistemas de internet hasta poder hacerlo.
- Si sigues en PHP 8.1 o anterior: esa rama ya no recibe parches del proyecto. O cambias de rama, o ese servidor no debería estar expuesto.
Cómo está este sitio
Aquí no hay Apache ni mod_php. Las páginas las sirve Caddy, que pasa el trabajo a php-fpm. Es el montaje que peor se presta a los exploits demostrados, aunque no es inmune.
Lo que importa es la versión. Este sitio corre PHP 8.5.12, la corregida, y el proceso que atiende las visitas se reinició después de esa actualización. No me he fiado de la línea de comandos: le he preguntado al propio servicio, con un fichero de prueba que borré después, y responde fpm-fcgi 8.5.12. Esa es la comprobación que vale, porque actualizar un paquete sin reiniciar el servicio deja al proceso viejo atendiendo igual que antes.
Además, este sitio no acepta subidas de ficheros, así que la función que abre esa ruta de ataque —el progreso de subida de sesiones— no sirve aquí para nada.
La parte incómoda
El primero de los fallos se detectó en 2024, durante una auditoría de seguridad. Se sabía que el problema estaba ahí y se ha tardado dos años en arreglarlo. Los propios responsables de PHP lo cuentan sin adornos: lo llaman fallo estructural, con decisiones que se atascaban y un equipo demasiado pequeño para el tamaño de lo que sostiene.
En el tramo final hubo además dos tropiezos. El aviso se filtró dos días antes de tiempo, con datos equivocados incluidos. Y un proveedor publicó sus imágenes con el parche seis horas antes de la fecha acordada, de modo que cualquiera pudo empezar a estudiar la corrección mientras los demás esperábamos la versión oficial.
Esto lo arregla gente que se paga con donaciones. PHP mueve una parte enorme de internet y su seguridad depende de un puñado de personas. Si tu negocio vive de PHP, el enlace del final es el sitio.
Fuentes
- El aviso de PHP: Critical Remote Code Execution Vulnerabilities, Update Now
- Los dos informes técnicos: RCE via OOM corruption y RCE via stale global state
- CISA: Critical Vulnerabilities in PHP Require Immediate Patching
- La crónica de la fundación: Today's PHP Security Release, and How We're Strengthening PHP Security
- Donar a la PHP Foundation