Protobuf JS expone sistemas a una vulnerabilidad de ejecución remota de código

Una vulnerabilidad crítica de ejecución remota de código (RCE) ha salido a la luz en protobuf.js, la implementación en JavaScript de Protocol Buffers que usan miles de proyectos en Node.js. El problema llamó la atención después de que investigadores compartieran un proof-of-concept público y los mantenedores publicaran parches; dada la popularidad de la librería —que registra cerca de 50 millones de descargas semanales—, el hallazgo merece atención inmediata por parte de equipos de desarrollo y operaciones.

El fallo radica en cómo la librería genera código dinámicamente a partir de los esquemas. En lugar de construir estructuras seguras, protobuf.js concatena cadenas para formar funciones JavaScript y las ejecuta con el constructor Function(), aplicando muy poca o ninguna validación sobre los identificadores extraídos del esquema (nombres de mensajes, tipos, etc.). Un esquema manipulado por un atacante puede insertar código malicioso en esa cadena, de modo que cuando la función sintética se evalúa finalmente, el código inyectado se ejecuta en el contexto del proceso que carga el esquema.

Ese vector convierte un esquema malicioso en una puerta para acceder a variables de entorno, secretos, conexiones a bases de datos y otros recursos internos; también permite movimientos laterales si la aplicación está desplegada en infraestructura compartida. No es sólo un riesgo para servidores: si desarrolladores cargan y decodifican esquemas no confiables en sus máquinas locales, también pueden quedar comprometidos sus entornos de trabajo.

El problema fue descubierto por el investigador Cristian Staicu y documentado por la compañía de seguridad Endor Labs en un informe detallado; la vulnerabilidad está registrada en GitHub como GHSA-xq3m-2v4x-88gg y Endor Labs explica el mecanismo y muestra un PoC en su análisis (informe de Endor Labs). Aunque los autores del informe han señalado que la explotación es sencilla, por ahora no se ha confirmado actividad maliciosa extendida en entornos de producción.

La vulnerabilidad afecta a versiones de protobuf.js anteriores o iguales a 8.0.0 y 7.5.4. Los mantenedores publicaron correcciones que están disponibles en las ramas principales: la serie 8.x se corrigió con la versión 8.0.1 y la serie 7.x con la 7.5.5; los paquetes npm con los parches se publicaron en abril (actualizaciones para 8.x y 7.x en distintas fechas). Puede consultar el repositorio y las notas de seguridad en la página del proyecto en GitHub: protobuf.js en GitHub y sus releases.

La solución urgente que se aplicó en el parche consiste en sanitizar los nombres de tipo, eliminando caracteres no alfanuméricos para impedir que un atacante cierre la función sintética y agregue instrucciones maliciosas. Sin embargo, los expertos apuntan que una corrección más robusta pasa por dejar de usar por completo la generación dinámica de código con Function() para procesar identificadores que pueden venir de fuentes externas: evitar el “round-tripping” de identificadores a través de código generado es una reparación de diseño más segura y duradera.

Si tu proyecto depende de protobuf.js, actúa ya: actualiza a las versiones parcheadas, comprueba el grafo de dependencias en busca de versiones vulnerables (incluso como dependencias transitivas) y trata la carga de esquemas como entrada no confiable. Para equipos en producción, una práctica recomendada es emplear esquemas precompilados o estáticos en lugar de generar y evaluar código en tiempo de ejecución. Endor Labs también sugiere auditar dependencias transitivas y revisar pipelines de CI/CD que puedan introducir esquemas no verificados.

En términos prácticos, puedes verificar qué versión está instalada con comandos del gestor de paquetes (por ejemplo, inspeccionando package.json o usando herramientas como npm ls) y forzar actualizaciones a las versiones seguras (por ejemplo npm install protobufjs@^8.0.1 o la versión 7.5.5 según la rama que uses). Además, es recomendable incorporar escaneos automáticos de software en el pipeline y políticas que eviten la descarga y ejecución de esquemas procedentes de orígenes no controlados.

La divulgación pública incluyó un PoC en la propia asesoría de seguridad del proyecto, lo que facilita a equipos técnicos replicar el problema para validarlo en entornos controlados; la asesoría oficial en GitHub contiene el enlace a ese ejemplo y a la discusión técnica (asesoría en GitHub). Si necesitas más contexto sobre el hallazgo y recomendaciones técnicas, el análisis de Endor Labs está bien documentado y vale la pena leerlo detenidamente: informe de Endor Labs.

La lección para la comunidad de desarrollo es doble: por un lado, la gran conveniencia de generar código dinámicamente trae riesgos cuando las entradas no están bien validadas; por otro, la enorme dependencia en bibliotecas compartidas hace que una sola vulnerabilidad pueda tener un alcance amplio. Actualizar, auditar y reducir la superficie de exposición sigue siendo la mejor defensa.