PHP2shell: por qué un fallo de memoria en PHP acaba en ejecución de comandos

Un fallo del motor, no de tu aplicaciónCuando una vulnerabilidad salta a los telediarios suele ser porque afecta a algo que todo el mundo usa. PHP2she...

Un fallo del motor, no de tu aplicación

Cuando una vulnerabilidad salta a los telediarios suele ser porque afecta a algo que todo el mundo usa. PHP2shell encaja en esa categoría: no depende de una función peligrosa mal implementada en tu web, ni de un plugin descuidado de WordPress, Joomla o Magento. El problema vive en el propio intérprete de PHP, antes incluso de que el script del usuario empiece a ejecutarse. Eso cambia por completo el modelo de defensa al que estamos acostumbrados los administradores de sistemas.

La buena noticia es que los parches oficiales ya existen y los CVE están publicados. La mala es que muchas infraestructuras en Barcelona, Lleida o Tarragona siguen corriendo versiones antiguas de PHP en servidores compartidos, contenedores sin actualizar o imágenes Docker congeladas desde hace meses. Entender la mecánica del fallo ayuda a priorizar la respuesta.

La grieta: memoria liberada que sigue pareciendo viva

La raíz no es nueva. PHP arrastra desde hace años una familia de errores relacionados con memory_limit, los bailouts y estados internos que sobreviven más de lo que deberían. Ya en 2004 se documentaron vulnerabilidades remotas ligadas a errores de memoria, y en 2020 apareció un bug donde un simple out-of-memory dejaba recursos sin limpiar correctamente. Una auditoría posterior del runtime volvió a tropezar con el mismo patrón, aunque sin llegar a una explotación completa.

La pieza que faltaba se encontró en 2026: algunos errores fatales no solo provocan un crash, sino que dejan estructuras internas en un estado intermedio. PHP libera memoria y, aun así, conserva punteros hacia esos bloques como si siguieran siendo válidos. Esa diferencia entre "memoria liberada" y "estado que aún cree que sigue vivo" convierte un OOM aparentemente inofensivo en una primitiva real de explotación.

De un crash a la ejecución de comandos

La cadena de ataque se construye manipulando cómo PHP parsea las peticiones multipart, cómo actualiza el progreso de subida de sesión, cómo limpia el heap del request y cómo reutiliza esa memoria en la siguiente petición. El recorrido, simplificado, es este:

Se fuerza un bailout mediante combinaciones de identificador de sesión, progreso de subida, avisos por límite de variables y un OOM controlado.
Algunos globales de sesión sobreviven al cierre abrupto con punteros que ya no deberían estar activos: quedan en estado stale.
La siguiente petición reclama exactamente esa zona de memoria mediante grooming (forzando tamaños y orden de asignaciones).
Se produce un use-after-free que permite filtrar direcciones del heap y de la biblioteca de PHP, resolviendo así el ASLR.
Con los offsets exactos, se redirige un destructor interno hacia la función que ejecuta comandos del sistema.

El detalle importante: el atacante no necesita conocer tu código. Le basta con enviar peticiones HTTP bien construidas contra un servidor vulnerable.

Qué significa para una pyme con servidores propios

Si gestionas infraestructura en España, este tipo de fallo obliga a replantear dos cosas. La primera es la disciplina de actualización: PHP no es un servicio que se instala y se olvida, y las ramas sin soporte activo son un riesgo directo. La segunda es asumir que el perímetro ya no está solo en el cortafuegos.

Un ataque como este se manifiesta primero como una ráfaga de peticiones anómalas, crashes repetidos y reinicios del proceso hijo de Apache o PHP-FPM. Si esos síntomas no se detectan ni se bloquean a tiempo, la ventana de explotación queda abierta. Aquí es donde el bloqueo proactivo de direcciones IP maliciosas marca la diferencia: cortar el origen del tráfico antes de que la cadena llegue a completarse reduce drásticamente la superficie de ataque.

Defensa en capas: parchear y, además, filtrar

Ninguna medida sustituye a la otra. La estrategia sensata combina:

Actualizar PHP a una versión con los parches aplicados y revisar todas las imágenes y contenedores del parque.
Limitar y monitorizar los errores fatales y los reinicios de workers, que suelen ser la primera señal.
Filtrar tráfico en el borde con reglas que detecten patrones de explotación y bloqueen IPs reincidentes.
Segmentar los servidores críticos para que un RCE en una máquina no abra la puerta al resto.

El problema es que, con varias máquinas, mantener reglas de bloqueo coherentes se vuelve un trabajo manual interminable. Cada servidor acumula su propia lista, las IPs bloqueadas en uno siguen entrando en otro y nadie tiene una visión global. Es justo el punto donde herramientas como Abuse Shield aportan valor: centraliza la protección, gestiona fail2ban en múltiples máquinas de forma automática y comparte un feed de reputación de IP entre todos los servidores. Si una IP maliciosa ataca el servidor de Lleida, el de Girona la bloquea antes de que lo intente.

Conclusión

PHP2shell recuerda algo que a veces olvidamos: la seguridad de servidores no se resuelve solo revisando el código de la aplicación. El motor, el runtime y el sistema operativo también forman parte de la superficie expuesta. Parchear rápido es imprescindible, pero no suficiente. Combinar actualización, monitorización y un bloqueo de IPs coordinado entre todas tus máquinas convierte un fallo crítico en un incidente contenido. Y eso, en un entorno con RGPD y LOPDGDD de por medio, no es un lujo: es responsabilidad operativa.

Relacionado

¿Tus servidores bajo ataque constante?

Centraliza fail2ban y la reputación de IPs en todos tus servidores. Descubre Abuse Shield de ALMC. Contáctanos para una demo personalizada.

Resultados sin salir de la página.