# CVE-2026-72824: falla crítica en plugin de Grav permite RCE con API keys de bajo privilegio

Una verificación de permisos mal implementada en el plugin API de Grav deja expuestos servidores con configuraciones específicas de Twig habilitadas.

El National Vulnerability Database clasificó como crítica una vulnerabilidad en el plugin API de Grav que permite a atacantes con claves de API de privilegios mínimos ejecutar código arbitrario en el servidor. El fallo, identificado como CVE-2026-72824, afecta todas las versiones del plugin getgrav/grav-plugin-api anteriores a la 1.0.13 y reside en una verificación de permisos que omite consultar los alcances definidos para cada clave de API. La explotación requiere una combinación específica de parámetros de configuración en el servidor objetivo, pero cuando esas condiciones se cumplen, el atacante obtiene capacidad de ejecución remota de código sin necesidad de credenciales administrativas completas.

Cómo una clave restringida puede habilitar procesamiento de plantillas

El núcleo del problema está en el método PagesController::guardTwigContent() del plugin. Este método debería verificar que una clave de API tenga los permisos necesarios antes de permitir que un usuario habilite el procesamiento de contenido Twig en una página. Sin embargo, la implementación utiliza una compuerta isSuperAdmin() que solo verifica si la cuenta que generó la clave tiene privilegios de superadministrador, sin consultar el campo api_key_scopes que define qué operaciones específicas puede realizar esa clave.

En la práctica, esto significa que un atacante puede generar una clave de API con alcance limitado únicamente a api.pages.write (escritura de páginas, sin permisos administrativos sobre configuración de Twig) desde una cuenta con privilegios de superadministrador. Esa clave, que en teoría solo debería permitir modificar contenido de páginas, puede activar el flag process.twig durante una operación de guardado de página. El permiso admin.pages_twig, que controla específicamente la capacidad de procesar Twig en contenido, queda intencionalmente fuera del alcance api.pages, pero la verificación defectuosa lo ignora.

Condiciones necesarias para la explotación y cadena de ataque

La vulnerabilidad solo es explotable cuando el servidor tiene dos parámetros de configuración específicos: security.twig_content.process_enabled debe estar en true (permitiendo que el motor Twig procese contenido embebido en páginas) y editor_enabled debe estar en false (deshabilitando el editor visual que normalmente sanitiza este tipo de entrada). Esta combinación no es la configuración por defecto en instalaciones nuevas de Grav, pero aparece en entornos donde administradores habilitan procesamiento de plantillas para funcionalidad dinámica mientras mantienen deshabilitado el editor por preferencias de flujo de trabajo o para reducir superficie de ataque en otros vectores.

Una vez que el atacante activa process.twig con la clave de API de alcance limitado, puede inyectar código Twig malicioso en el contenido de la página. Cuando el servidor procesa esa página, el motor Twig ejecuta el código embebido en el contexto del servidor, resultando en Server-Side Template Injection. Desde SSTI, la progresión a ejecución remota de código es directa: el atacante puede invocar funciones del sistema operativo a través de construcciones Twig que acceden a métodos de objetos PHP subyacentes.

Exposición en América Latina y dependencia de Grav en infraestructura educativa

Grav tiene adopción documentada en instituciones educativas y organizaciones sin fines de lucro de Argentina, Chile y México, sectores que frecuentemente priorizan sistemas de gestión de contenido livianos y sin base de datos por limitaciones de infraestructura. La configuración vulnerable (Twig habilitado con editor deshabilitado) aparece típicamente en entornos donde desarrolladores locales implementan funcionalidad dinámica personalizada para portales institucionales. Aunque no hay reportes públicos de explotación activa de CVE-2026-72824 en la región, la combinación de adopción en sectores con recursos limitados para monitoreo de seguridad y la criticidad de la falla representa un vector de riesgo estructural para infraestructura web educativa y gubernamental de nivel municipal en estos países.

Mitigación disponible y ausencia de workarounds efectivos

La versión 1.0.13 del plugin corrige el fallo modificando guardTwigContent() para que consulte explícitamente api_key_scopes antes de permitir cambios en el flag process.twig. No existen mitigaciones alternativas efectivas más allá de la actualización: deshabilitar completamente el plugin API elimina el vector pero rompe cualquier integración que dependa de él, mientras que cambiar security.twig_content.process_enabled a false bloquea la explotación pero también desactiva funcionalidad legítima de procesamiento de plantillas que puede ser crítica para el funcionamiento del sitio.

La única medida paliativa parcial es auditar todas las claves de API existentes y revocar aquellas generadas desde cuentas de superadministrador que tengan alcances limitados, bajo el supuesto de que esas claves pueden haber sido comprometidas o generadas con la intención de explotar esta vulnerabilidad. Sin embargo, esta acción no protege contra un atacante que tenga acceso legítimo a una cuenta super y pueda generar nuevas claves en cualquier momento antes de aplicar el parche.

Nuestro análisis

CVE-2026-72824 ejemplifica un patrón recurrente en sistemas de autorización basados en alcances: la desconexión entre verificaciones de identidad (quién generó la clave) y verificaciones de capacidad (qué puede hacer esa clave específica). El fallo no está en la arquitectura de scopes de Grav, que correctamente separa api.pages de admin.pages_twig, sino en una implementación puntual que cortocircuita esa separación al confiar en el estado de la cuenta origen en lugar del alcance explícito de la credencial. Este tipo de error aparece consistentemente en sistemas que agregan capas de autorización granular sobre modelos de permisos preexistentes basados en roles, donde código legacy asume que «ser admin» es suficiente sin considerar que la credencial en uso puede tener restricciones adicionales.

La severidad crítica asignada por NVD refleja el impacto potencial (RCE completo) más que la probabilidad de explotación en entornos arbitrarios. La necesidad de dos flags de configuración específicos reduce significativamente la superficie de ataque real comparada con vulnerabilidades que afectan configuraciones por defecto. Sin embargo, la ausencia de workarounds viables y la naturaleza silenciosa del bypass (un atacante con clave legítima de bajo privilegio no genera alertas al usarla dentro de su alcance aparente) hacen que la ventana entre divulgación pública y explotación oportunista sea particularmente estrecha para los sitios que sí cumplen las condiciones. ¿Cuántos sistemas de autorización basados en tokens en producción hoy están verificando el alcance de la credencial en cada punto de decisión, y cuántos asumen que el nivel de privilegio de la cuenta que la emitió es suficiente garantía?