Un admin de organización puede agregar cualquier usuario existente como administrador sin pasar por el flujo de invitación, saltando todas las verificaciones de seguridad del sistema RBAC.
Una vulnerabilidad de severidad alta (CVE-2026-100623) en Capgo, plataforma de distribución de actualizaciones over-the-air para aplicaciones móviles, permite a un administrador de organización elevar privilegios de cualquier cuenta existente en el sistema sin requerir la aceptación del usuario afectado. El fallo radica en la exposición directa de una tabla heredada de membresías a través de la API de Supabase PostgREST, con políticas de seguridad a nivel de fila que verifican únicamente los derechos del atacante pero no la legitimidad del flujo de incorporación. Al momento de la publicación del CVE por parte del National Vulnerability Database, todas las versiones de Capgo permanecían afectadas y no existía parche disponible.
Cómo una tabla legacy bypasea el sistema de roles completo
La raíz del problema está en public.org_users, una tabla heredada que Capgo expone directamente a través de la interfaz PostgREST de Supabase. Las políticas de row-level security configuradas en esa tabla — «Allow org admin to insert» y «Allow org admin to update» — validan únicamente que el usuario que ejecuta la operación tenga derechos de administrador en la organización objetivo mediante public.check_min_rights(‘admin’, …). No exigen ninguna otra condición: ni la existencia de una invitación pendiente en tmp_users, ni la aceptación de un token de invitación a través del endpoint /private/accept_invitation, ni la participación activa del usuario que se está agregando.
En la práctica, esto significa que un administrador autenticado puede ejecutar un INSERT o UPDATE directo contra org_users para agregar cualquier cuenta existente de public.users como miembro activo de su organización, asignándole user_right=’admin’ en una sola operación SQL. El sistema de control de acceso basado en roles (RBAC) de Capgo implementa verificaciones de consistencia de membresía, anti-escalation y validación de tokens en su flujo normal de invitación y asignación de roles — pero todas esas capas quedan completamente omitidas cuando se accede a la tabla heredada de forma directa.
Qué puede hacer un atacante con acceso directo a org_users
Durante las pruebas documentadas en el reporte del CVE, una cuenta sin acceso previo a la organización ni a sus aplicaciones pudo, tras un INSERT directo en org_users, leer tanto la organización como la aplicación asociada y pasar exitosamente las verificaciones de check_min_rights. Esto confirma que la membresía fraudulenta es reconocida por el resto del sistema como válida: el usuario elevado obtiene permisos reales de administrador sobre recursos que antes le estaban vedados, sin que el propietario legítimo de la organización haya emitido invitación alguna ni el usuario objetivo haya consentido su incorporación.
El vector de ataque requiere que el atacante ya sea administrador de al menos una organización en Capgo — no es explotable por un usuario sin privilegios — pero una vez cumplida esa condición, puede agregar a cualquier otra cuenta registrada en la plataforma. En entornos donde múltiples organizaciones comparten la misma instancia de Capgo (escenario común en plataformas SaaS multi-tenant), un administrador malicioso o comprometido puede incorporar cuentas de terceros a su organización para luego delegar acciones bajo esa identidad, complicando la atribución de actividad sospechosa y facilitando movimientos laterales si esas cuentas tienen acceso a otras organizaciones.
Por qué persiste una tabla heredada con políticas insuficientes
La existencia de public.org_users como tabla expuesta sugiere que Capgo migró en algún momento su modelo de membresías hacia un sistema RBAC más robusto, pero mantuvo la tabla original accesible — probablemente por compatibilidad con código legacy o integraciones externas. Las políticas de row-level security aplicadas a esa tabla reflejan un modelo de control de acceso más simple, anterior a la implementación de flujos de invitación con validación de token y verificaciones anti-escalation. Supabase PostgREST, por diseño, expone todas las tablas y vistas configuradas en el esquema público a través de su API REST automática, a menos que se restrinjan explícitamente mediante políticas RLS o se excluyan del esquema expuesto.
El problema no es una falla de Supabase en sí — la plataforma está funcionando según su especificación — sino una configuración insegura en Capgo: las políticas RLS de org_users no fueron actualizadas para reflejar las restricciones del nuevo flujo de invitación, y la tabla no fue movida a un esquema privado ni se deshabilitó su acceso directo vía PostgREST. Este tipo de deuda técnica de seguridad es común en aplicaciones que evolucionan su modelo de autorización sin auditar exhaustivamente todos los puntos de acceso a datos heredados.
Impacto en organizaciones latinoamericanas que usan Capgo
Capgo es utilizado por equipos de desarrollo móvil en América Latina para distribuir actualizaciones de aplicaciones Capacitor e Ionic sin pasar por las tiendas de aplicaciones — un caso de uso particularmente relevante en sectores como fintech, salud digital y gobierno electrónico, donde la capacidad de parchear vulnerabilidades o desplegar funcionalidades críticas en horas (en lugar de días de revisión en tiendas) es operacionalmente valiosa. La ausencia de parche disponible al momento de la publicación del CVE deja a estas organizaciones en una posición de riesgo no mitigable mediante actualización: cualquier administrador de organización en su instancia de Capgo — ya sea un empleado interno con acceso legítimo o una cuenta comprometida — puede elevar privilegios de cuentas arbitrarias.
En el contexto regional, donde muchas organizaciones operan con equipos distribuidos y contratan desarrolladores externos o consultores con acceso temporal a plataformas internas, la posibilidad de que un administrador agregue cuentas sin consentimiento del usuario objetivo amplifica el riesgo de acceso no autorizado persistente: un contratista cuyo acceso fue revocado formalmente podría ser re-agregado de forma encubierta por un insider, y el propietario de la cuenta afectada no recibiría notificación de invitación ni tendría registro del evento en su historial de aceptaciones. Esto complica la auditoría post-incidente y la detección de movimientos laterales en investigaciones forenses.
Nuestro análisis
CVE-2026-100623 es un caso representativo de cómo la exposición de tablas heredadas con políticas de seguridad desactualizadas puede anular por completo un sistema de autorización moderno. Capgo implementó un flujo de invitación con validación de token, verificaciones de consistencia y anti-escalation — pero dejó abierta una ruta de acceso directo a la tabla de membresías que predataba ese flujo. El resultado es que el sistema RBAC completo se convierte en opcional: un atacante con conocimiento de la estructura de datos puede simplemente ignorarlo y escribir directamente en la tabla subyacente. Este patrón no es exclusivo de Capgo — cualquier aplicación que migre su modelo de autorización sin auditar y restringir todos los puntos de acceso a datos sensibles enfrenta el mismo riesgo.
La severidad alta asignada por NVD refleja que, aunque el ataque requiere privilegios de administrador previos, el impacto es la elevación arbitraria de privilegios sin consentimiento ni auditoría, lo que en un entorno multi-tenant puede comprometer la segregación entre organizaciones. La ausencia de parche al momento de la publicación sugiere que la remediación no es trivial — probablemente requiere refactorizar el acceso a org_users, migrar código legacy que depende de escritura directa, y validar que ninguna integración externa se rompa al restringir la tabla. Mientras tanto, las organizaciones que usan Capgo no tienen mitigación técnica disponible más allá de monitoreo de logs de Supabase en busca de INSERT/UPDATE anómalos en org_users, lo que presupone capacidad de observabilidad que no todas las implementaciones tienen configurada. ¿Cuántas otras tablas heredadas en aplicaciones SaaS latinoamericanas están expuestas de forma similar, esperando que alguien lea el esquema de base de datos y encuentre la ruta de bypass?