Un investigador ha ganado un total de 148.337 USD de Google por descubrir un conjunto de fallos en el servicio de Integración de Aplicaciones de Google Cloud que escalaron hasta convertirse en una ejecución remota de código (RCE) en el entorno de producción de Google Cloud.

El error principal se rastrea ahora como CVE‑2026‑2031. El investigador Arvin Shivram ha documentado públicamente el problema bajo el título “StubZero: $148,337 RCE in Google Cloud Production” en el blog de BruteCat.

El CVE-2026-2031 es un fallo crítico de control de acceso en la Integración de Aplicaciones de Google Cloud que puede permitir la ejecución remota de código, con una puntuación CVSS de 10.0.

Google ha solucionado el problema restringiendo el acceso a los endpoints internos, corrigiendo debilidades de IDOR y reforzando los controles de seguridad RPC.

Según el propio análisis de Arvin Shivram en BruteCat.com, la cadena comenzó cuando una herramienta de fuzzing automatizada señaló la API interna cloudcrmipfrontend-pa.googleapis.com por devolver respuestas HTTP 200 en endpoints de depuración sospechosos.

Sondas posteriores revelaron un endpoint, v1/integrationPlatform/getProtoDefinition, que devolvía descriptores protobuf para mensajes y servicios internos arbitrarios, incluyendo YouTube y la infraestructura interna de CRM de Google.

Debido a que los servicios internos de Google dependen en gran medida de protobuf, esta filtración de estilo “req2proto como servicio” le dio al atacante una visión casi completa de los esquemas de la API interna, facilitando enormemente la investigación de caja negra.

La misma superficie de la API también expuso un endpoint listQuotaQueue que, al ser consultado con los parámetros correctos y X-Goog-Encode-Response-If-Executable: base64, filtraba una cola de ejecución de flujo de trabajo interno junto con un valor crucial de clientId (por defecto).

Vulnerabilidad de RCE en Producción de Google Cloud

Armado con el ID de cliente filtrado, el investigador pudo crear borradores de flujos de trabajo a través de createDraftWorkflow en el backend interno de Integración de Aplicaciones y comenzó a explorar las tareas visibles en el documento de descubrimiento.

El punto de inflexión llegó con un tipo de tarea interna llamada GenericStubbyTypedTaskV2, que el artículo de BruteCat identifica como un envoltorio genérico alrededor del framework RPC Stubby de Google dentro de los flujos de trabajo de Integración de Aplicaciones.

Al configurar GenericStubbyTypedTaskV2 con parámetros como serverSpec, serviceName y serviceMethod, el atacante podía activar llamadas RPC de Stubby arbitrarias desde el entorno de producción de Google, utilizando la identidad de servicio privilegiada de la plataforma de integración.

La documentación del Programa de Recompensas por Vulnerabilidades de Cloud de Google clasifica el acceso a nivel de Stubby como RCE en el entorno de producción porque proporciona un acceso amplio a servicios y datos internos, dependiendo de la RpcSecurityPolicy del objetivo.

Inicialmente, la publicación del flujo de trabajo estaba bloqueada por un requisito de aprobación de dos personas que impedía que una sola cuenta editara y publicara un flujo de trabajo.

El investigador explica en BruteCat.com que superó esta restricción abusando de un endpoint ACL interno, integrationPlatform/auth/setAcl, para añadir dos cuentas de Google controladas por el atacante a la ACL del flujo de trabajo, usando una como solicitante y la otra como aprobador.

En una colaboración posterior con otro investigador (“shrugged”), descubrieron que las mitigaciones iniciales de Google solo se habían implementado parcialmente en las instancias del backend detrás de un equilibrador de carga.

Al enviar repetidamente solicitudes createDraftWorkflow hasta dar con un backend que aún era vulnerable, preservaron la ruta de RCE justo antes de que el parche se propagara completamente, un detalle destacado tanto en el análisis de BruteCat como en discusiones posteriores en podcasts (Critical Thinking – Episodio 177).

Tres meses después, el mismo investigador identificó una segunda cadena de RCE en las APIs públicas de Integración de Aplicaciones que involucraba referencias directas inseguras a objetos (IDOR) y la función de “casos de prueba”.

La publicación de BruteCat detalla cómo un RPC de listado global de casos de prueba, combinado con una técnica de filtro de búsqueda binaria, permitió la reconstrucción de UUID de integración de las víctimas y el acceso entre inquilinos a definiciones completas de flujos de trabajo, incluidas aquellas operadas por equipos internos de Google.

Las reglas del VRP de Cloud de Google, publicadas en la página oficial del programa, describen pagos escalonados por el “Compromiso del Entorno de Producción de Google Cloud”, con niveles más altos para usuarios de producción privilegiados y acceso de nivel de administrador.

En consonancia con esto, Google otorgó 60.000 USD por la primera cadena, 75.000 USD por la segunda y otros 13.337 USD por una escalada de privilegios de un solo servicio remanente, para un pago combinado de 148.337 USD.