Radio Online
El equipo de PHP publicó este miércoles, a las 11 de la Argentina, parches de emergencia para dos fallas críticas que permiten tomar el control de un servidor web sin usuario ni contraseña.
El equipo de PHP publicó este miércoles, a las 11 de la Argentina, parches de emergencia para dos fallas críticas que permiten tomar el control de un servidor web sin usuario ni contraseña.
Las versiones corregidas son la 8.5.12, la 8.4.27, la 8.3.36 y la 8.2.35. Todo sitio que corra una versión anterior queda expuesto, y cientos de miles de servidores con PHP viejo no van a recibir ningún arreglo oficial.
Un lenguaje que está detrás de millones de sitios
PHP es el lenguaje con el que se arman muchísimas páginas web: blogs, tiendas online, foros, portales de noticias y sistemas internos de empresas. Cuando alguien entra a uno de esos sitios, es PHP el que arma la página en el servidor antes de enviearla al navegador.
La firma de seguridad Phoenix Security contó 2,23 millones de servidores que muestran públicamente que usan PHP, y otros 740.000 que lo ocultan. Por eso una falla en el propio lenguaje, y no en un sitio puntual, tiene un alcance enorme.
Dos fallas, un mismo resultado: el atacante ejecuta su código
Las dos fallas recibieron una gravedad de 9,2 sobre 10 y se pueden explotar a distancia, sin iniciar sesión. Alcanza con enviarle un pedido web armado a propósito al servidor. En la jerga, permiten "ejecución remota de código": el atacante hace que el servidor corra sus propias instrucciones.
Por dónde entra el ataque
Cuando a PHP se le acaba la memoria durante un pedido, la deja en un estado inválido que se puede corromper.
Un pedido que agota la memoria mientras PHP lee los datos enviados
PHP guarda datos de un pedido después de liberarlos, y el pedido siguiente los vuelve a usar. La función que informa el progreso de las subidas de archivos, y los reportes de errores fatales
El punto más delicado está en Apache con mod_php, una de las formas más comunes de instalar PHP. Según el aviso oficial, esa configuración es vulnerable "de manera incondicional" a la primera falla: el ataque funciona antes de que se ejecute una sola línea del sitio, sea cual sea el sitio.
Una filtración apuró los tiempos
Las fallas iban a hacerse públicas con calma, pero los detalles se filtraron antes de tiempo y el equipo de PHP adelantó el anuncio.
Mientras tanto, el CERT-EU, el equipo de respuesta a incidentes de las instituciones europeas, emitió la alerta 2026-018. Pedía identificar los sitios con PHP y aislar de internet los que no se pudieran actualizar.
PHP publica las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, con los detalles técnicos
El 20 de octubre, cuando se filtran los detalles. Benjamin Harris, CEO de la firma watchTowr, confirma las fallas y el investigador Florian Roth las difunde en redes.
En la misma jornada, PHP anuncia una actualización de seguridad urgente para el día siguiente y se reserva adelantarla si aparecen ataques
Hasta la publicación de los parches no se habían detectado ataques reales. Pero watchTowr ya había logrado reproducir una de las fallas en su laboratorio, y con los detalles técnicos ahora públicos, el margen para actualizar se achica
El agujero más grande: los servidores con PHP viejo
Solo las ramas 8.2, 8.3, 8.4 y 8.5 recibieron parches oficiales. PHP 8.1 y todas las anteriores ya no tienen soporte, así que no hay actualización oficial para ellas.
El proyecto publicó en GitHub correcciones mínimas para 7.4, 8.0 y 8.1, pero hay que aplicarlas a mano y recompilar PHP, algo que pocos administradores hacen. Para PHP 5 y las versiones 7 anteriores a la 7.4 no hay nada.
El problema no es menor. Según el relevamiento de Phoenix Security, unos 884.000 servidores (el 59% de los que informan su versión) corren ramas sin soporte, y casi 700.000 siguen en PHP 5 o PHP 7. Esos sitios no tienen un parche al que pasarse: la única salida completa es migrar a una versión con soporte.
El aviso oficial de PHP es claro: actualizar es la única solución completa. Los ajustes de configuración sirven para ganar tiempo, pero no cierran las fallas.
Quienes administren un sitio o un servidor:
Revisar qué versión de PHP corre cada sitio.
Si se usa en una versión sin soporte, planificar la migración a PHP 8.2 o superior. Mientras tanto, PHP recomienda estas medidas parciales:
Desactivar el progreso de subidas: session.upload_progress.enabled = 0.
Fijar memory_limit = -1 desde la configuración del servidor, para que el sitio no pueda cambiarlo. Es la medida principal contra la primera falla, aunque no la cubre del todo.
Bajar post_max_size, es decir, el tamaño máximo de los datos que un visitante puede enviar.
En PHP 8.5, apagar fatal_error_backtraces.
Si no se puede actualizar ni aplicar esas medidas, se debeb seguir el consejo del CERT-EU: sacar el sitio de internet hasta poder corregirlo.
Si es usuario o se tiene un sitio en un hosting: no hay nada que instalar porque la falla está en los servidores. Si se posee una página alojada en un proveedor, consultar qué versión de PHP usa y si ya aplicó la actualización.
Una carrera contra el reloj
Con los parches publicados, cualquiera puede compararlos con las versiones anteriores y deducir cómo funciona el ataque.
Desde ahora corre una carrera entre los administradores que actualizan y los atacantes que buscan servidores sin parchear. Los que corren PHP viejo, sin arreglo oficial a la vista, son los que llegan peor parados.
PHP, sitio oficial: anuncio y versiones publicadas
Aviso oficial CVE-2026-109618 (GitHub de PHP)
Aviso oficial CVE-2026-109619 (GitHub de PHP)
CERT-EU, alerta de seguridad 2026-018
Phoenix Security: cronología y servidores expuestos
