Resumen del debate: Vulnerabilidad MUY grave de PHP

PHP crítico: parche de urgencia y millones de webs sin red​

Una vulnerabilidad de PHP calificada de muy grave obliga a actualizar hoy mismo. El aviso circula desde primera hora: la actualización se publica a las 16:00 y, según se advierte, el fallo ya está siendo explotado. No es un ejercicio teórico de laboratorio. Quien tenga un proyecto que tire de PHP —y eso incluye desde un WordPress de barrio hasta la trastienda de una tienda online— tiene una ventana de horas para reaccionar.

El vector del ataque tiene nombre técnico y una explicación que cabe en un folio. PHP incorpora desde hace años la función session.upload_progress, pensada para que el navegador pueda consultar el avance de una subida de archivos. Para hacerlo, el servidor crea un fichero de sesión sin exigir autenticación. Basta un POST con el campo adecuado para que escriba un fichero con contenido que controla el atacante, en un directorio del que el propio sistema se fía.

Qué es el envenenamiento de sesiones y por qué importa​

Ese fichero, por sí solo, suele ser basura inofensiva. El problema aparece cuando la web tiene cualquier inclusión local: una LFI, un include con parámetro, un plugin viejo de WordPress, un unserialize mal puesto. Entonces la basura pasa a ser ejecución de código. Es el clásico session file poisoning, una técnica vieja que vuelve a morder porque la función sigue activa por defecto en instalaciones que nadie revisó.

De ahí que la mitigación provisional más repetida sea desactivar la función en el php.ini: session.upload_progress.enabled = Off. Se pierde la barra de progreso en las subidas, un mal menor mientras llega el parche. También se apunta a que Cloudflare ha aplicado alguna regla, aunque nadie se fía de una capa intermedia como única defensa.

El agujero que deja el soporte: solo hay parche para PHP 8​

Aquí está la letra pequeña que convierte un susto en un problema estructural. El parche se publica para la rama 8. Las versiones anteriores están fuera de soporte, pero siguen sosteniendo una parte enorme del tejido digital: aplicaciones en PHP 7, y hasta en 5, que nadie migró porque actualizarlas era un trabajo de meses y el negocio funcionaba. Esas webs se quedan sin red.

El argumento que circula es razonable y demoledor: para un fallo de esta gravedad debería haberse publicado un parche también para las ramas antiguas. La alternativa —migrar de urgencia un CMS con plugins de hace una década— no es una opción realista en una tarde.

La broma del parche de cinta aislante​

En el tramo final de la conversación aparece el humor de trinchera. Un mensaje resume el estado de ánimo con sorna: «Aplicando el parche. De cinta aislante». Otro celebra que el parche ya esté aplicado en el sitio desde el que se escribe. Y una referencia al ZX Spectrum de marca blanca cierra el círculo: hay quien gestiona infraestructura crítica con la misma filosofía que un taller de barrio.

La pregunta que queda en el aire es cuántas de esas webs sin parche aguantarán el fin de semana. El aviso dice que el fallo ya se explota. Los plazos no son negociables. Y el que no actualice hoy, mañana reza.