Otro día, otra vulnerabilidad

Ayer 21 de octubre, PHP anunció (y publicó correcciones para) dos vulnerabilidades críticas que pueden permitir ejecutar código (ACE o RCE) en un servidor sin ningún tipo de autenticación. Quienes tengan o administren sitios o aplicaciones web que funcionen con PHP deben prestar mucha atención: Desde un blog con WordPress hasta una aplicación desarrollada a medida son vulnerables. Es un problema serio, que tiene solución, pero puede que nos obligue a revisar una parte del código de la web, dependiendo de la edad del código.

Y es que antes de ejecutar nuestro código, PHP recibe y procesa los datos que llegan al servidor. El ataque demostrado muestra cómo una solicitud especialmente preparada puede agotar la memoria del servidor y dejarla en un estado tal que PHP permite el ataque al utilizar los datos almacenados en esa memoria. Pero todo ocurre antes de que nuestra aplicación pueda ejecutar su primera línea, por lo que no es una error en nuestro código, ni tampoco es posible validar información o comprobar permisos para bloquear solicitudes. El defecto está en el motor que ejecuta el programa. Por eso mismo, actualizar WordPress (o Joomla, o la plataforma que usemos) no corrige estas fallas.

Y si, la inteligencia artificial participó en el hallazgo. Según OpenAI, investigadores de Calif identificaron una de las fallas con ayuda de GPT‑5.6 Sol, mientras que Wiz Research descubrió y reportó ambas de forma independiente. Luego, investigadores comprobaron los resultados y desarrolladores prepararon las correcciones. La IA ayudó a encontrar el problema, pero resolverlo requirió trabajo humano y coordinación.

Pero que no cunda el pánico (a menos que seas responsable de un sitio web de altísima visibilidad o valor): No es el fin del mundo ni el día que la internet se rompió. Este tipo de vulnerabilidades son muy serias, requieren atención inmediata y no podemos bajar la guardia, pero al momento de escribir esto no hay ataques exitosos reportados y se cree que los atacantes principalmente estarán buscando robar datos como claves de servicios de IA. Un sitio web institucional no corre tanto riesgo.

La solución completa es instalar una versión corregida de PHP y reiniciar los servidores. Hay filtros de tráfico que pueden reducir la exposición en el ínterin, pero no reemplazan el parche. Muchos optaron por restringir directamente el acceso a sus sitios web, porque no hay alternativa a actualizar PHP. Sin embargo, en un hosting compartido, es el proveedor quien debe aplicar la actualización, no hay nada que el dueño de un sitio web pueda hacer.

En cualquier caso, la actualización también puede necesitar trabajo del desarrollador. Especialmente si el desarrollo había sido hecho en una versión antigua, es frecuente que actualizar la versión de PHP traiga incompatibilidades que exigen reescribir parte del código o actualizar componentes. Esto nos recuerda que mantenernos actualizados, al menos dentro de lo posible, y hacer pruebas de compatibilidad forman parte del mantenimiento regular. Dejemos de esperar que el hosting elimine la versión de PHP (años más tarde) para ver cómo, de emergencia, migramos.

En Foxtrot no usamos PHP en ningún servicio, por lo que estas vulnerabilidades no nos afectan directamente. Sin embargo, si tenés integrada una tienda WooCommerce, posiblemente sí necesite revisión, dependiendo, como mencionamos, del proveedor de hosting.

Publicado el

en

, ,

¿Querés seguir la conversación?