Un archivo da control sobre 52 millones de proyectos: la popular librería protobuf.js entregó a los atacantes una vulnerabilidad de 9,4 puntos

Un archivo ordinario de descripción de datos puede convertirse repentinamente en un medio para comprometer un servidor. Especialistas de Endor Labs encontraron en la popular biblioteca protobuf.js una vulnerabilidad que permite ejecutar código ajeno con muy poco esfuerzo si una aplicación carga un archivo de esquema falsificado.

Protobuf.js es una de las bibliotecas más difundidas para trabajar con el formato Protocol Buffers en JavaScript. Este formato lo utilizan millones de servicios, incluidas soluciones basadas en la plataforma en la nube Google Cloud y la plataforma Firebase. El paquete se descarga aproximadamente 52 millones de veces por semana, y con frecuencia llega a proyectos como dependencia oculta.

El ataque en sí es más sencillo de lo que parece. Basta con que un atacante suministre a la aplicación un archivo de esquema protobuf malicioso. Estos archivos a menudo se cargan desde fuentes externas: servicios asociados, almacenes compartidos o servidores de terceros. Tras la carga, basta con un mensaje ordinario: la biblioteca procesará los datos y ejecutará el código malicioso integrado sin autorización ni intervención del usuario.

El problema está relacionado con la forma en que protobuf.js procesa los esquemas. La biblioteca no se limita a leer la descripción de los datos, sino que genera a partir de ella código JavaScript y lo ejecuta de inmediato mediante un mecanismo similar a eval. Además, los nombres de tipos del esquema se insertan en el código tal cual, sin verificación. Si un atacante introduce en el nombre construcciones de JavaScript, la biblioteca las ejecutará como código completo.

La vulnerabilidad recibió el identificador GHSA-xq3m-2v4x-88gg y una puntuación de 9,4 en la escala CVSS. Afectó a las versiones de protobuf.js anteriores a la 8.0.0 y a la 7.5.4 inclusive. Las correcciones ya se publicaron en las versiones 8.0.1 y 7.5.5. Hasta ahora no se han registrado ataques públicos, pero explotar la vulnerabilidad es técnicamente sencillo.

El riesgo es más amplio de lo que parece. Muchos servicios cargan esquemas automáticamente "en caliente" —por ejemplo, mediante mecanismos de autodescripción en gRPC o desde registros internos. En esos escenarios, basta una fuente comprometida para ejecutar código en el servidor, obtener acceso a tokens, datos de usuarios y servicios internos.

Se recomienda a los desarrolladores actualizar urgentemente la biblioteca y revisar las dependencias, especialmente si el proyecto utiliza gRPC, Firebase o bibliotecas cliente de servicios en la nube. Debe prestarse especial atención a los puntos donde la aplicación carga esquemas desde el exterior. Esos archivos ya no pueden considerarse descripciones inocuas: en la práctica se convierten en código ejecutable.