SSRF en Google Cloud Apigee-X puede filtrar tokens de cuenta de servicio (CVE-2026-2264)
Una vulnerabilidad en la policy SetIntegrationRequest de Apigee recibió un 9,2 en el CVSS y permite exfiltrar tokens de cuenta de servicio, pero depende de una configuración insegura previa en el proxy de API.
Google Cloud ha corregido una vulnerabilidad de server-side request forgery en Apigee-X, su plataforma de gestión de APIs, capaz de filtrar tokens de acceso de cuentas de servicio. La CVE-2026-2264, divulgada el 26 de mayo en el boletín de seguridad gcp-2026-034, recibió una puntuación de 9,2 en el CVSS 4.0, con una advertencia importante incluida en el propio aviso.
La vulnerabilidad y su condición de entrada
El problema radica en la policy SetIntegrationRequest de Apigee. Según el registro de Google Cloud, un atacante remoto puede usarla para ejecutar una SSRF (CWE-918) y exfiltrar tokens de acceso de cuentas de servicio, las credenciales que utiliza el proxy de API para comunicarse con otros servicios de Google Cloud. Con estos tokens, el atacante hereda los permisos de la cuenta de servicio, lo que suele significar acceso a recursos mucho más allá de la puerta de enlace.
La advertencia está escrita en el aviso y no debe eliminarse apresuradamente: para que la explotación funcione, un administrador debe haber establecido primero una configuración insegura en el proxy de API. El vector CVSS 4.0 refleja esto al marcar requisitos de ataque presentes (AT:P). En otras palabras, la vulnerabilidad no se activa por sí sola en ninguna instalación estándar; depende de una puerta dejada abierta en la configuración. Esto no la hace inofensiva, porque las configuraciones inseguras de proxy son comunes donde la prisa por entregar la integración ha superado la revisión de seguridad, pero ajusta la expectativa: el 9,2 mide el daño posible, no la facilidad universal.
Las versiones afectadas del runtime de Apigee-X son anteriores a la 1.14.4, a la 1.15.2 y a la 1.16.1. Al ser un servicio gestionado, la corrección de fondo es aplicada por Google en el runtime, lo que cambia la naturaleza de la respuesta del cliente en relación a un producto instalado localmente.
Lo que el cliente aún necesita hacer
Servicio gestionado no significa responsabilidad cero. Aun con el runtime corregido por Google, es responsabilidad del cliente identificar los proxies que utilizan la policy SetIntegrationRequest y revisar si alguno de ellos tiene la configuración insegura que abre la brecha. También es necesario evaluar el alcance de las cuentas de servicio vinculadas a Apigee: cuanto más amplios sean los privilegios de estas cuentas, mayor será el premio que representa un token filtrado. El principio de menor privilegio, aquí, es la diferencia entre un incidente contenido y un desvío para el resto del proyecto en la nube. La propia nota de versión ofrece el mapa de auditoría: los runtimes anteriores a la 1.14.4, a la 1.15.2 y a la 1.16.1 llevan el defecto, y confirmar en cuál de ellos cada entorno opera es el primer ítem de la verificación.
Lo que cambia para Brasil
Apigee ocupa un lugar específico en el mercado brasileño: es una de las capas de gestión de API utilizadas por bancos y fintechs para exponer las interfaces reguladas del Open Finance Brasil. A través de gateways de este tipo circulan consentimientos, datos de cuentas e inicios de pago entre instituciones. Una SSRF que filtre credenciales de cuenta de servicio precisamente en esta capa es sensible por definición, porque el gateway se encuentra exactamente sobre el flujo de datos que la regulación manda proteger.
La lectura para el CISO de una institución financiera brasileña tiene dos aspectos. El primero es la buena noticia: al ser gestionado, Apigee-X no requiere una carrera de parches a medianoche como lo haría un servidor instalado internamente. El segundo es el trabajo que queda: auditar la configuración de los proxies que exponen APIs reguladas y confirmar que ninguna cuenta de servicio haya acumulado permisos más allá de lo necesario. La configuración insegura que requiere la vulnerabilidad no nace de mala fe; nace de proxies montados hastapresurosamente para cumplir con plazos regulatorios, y es ahí donde debe intervenir la revisión.
La lección que atraviesa el caso es menos sobre esta CVE y más sobre el punto ciego del modelo gestionado. Mover la infraestructura a un servicio operado por el proveedor transfiere el parche, no la responsabilidad por la configuración. La parte que sigue en manos del cliente, la de cómo se montó el proxy y cuántos privilegios lleva la cuenta de servicio, es precisamente la que esta vulnerabilidad exige.