pl4tyz/cve-2025-53652-jenkins-git-parameter-analysisCVE-2025-53652: Análisis de Git Parameter de Jenkins
Esta vulnerabilidad surge porque la entrada controlada por el usuario procedente de los parámetros de build de Jenkins se inyecta de forma insegura en el comando de checkout de Git.
La entrada del usuario se proporciona como parámetro de build (p. ej., gitParameters), que puede contener comandos shell maliciosos.
Este parámetro se envuelve en un GitParameterValue (que extiende StringParameterValue), cuyo método buildEnvironment() lo expone como variable de entorno en el contexto del build sin saneamiento.
Durante el proceso de checkout del SCM, Jenkins carga las variables de entorno del build mediante build.getEnvironment().
El nombre de rama utilizado para el checkout (localBranchName) se obtiene de estas variables de entorno.
A continuación, el nombre de rama se pasa directamente al método CheckoutCommand.branch().
Finalmente, CheckoutCommand.execute() invoca el comando subyacente de la CLI de Git, que concatena el nombre de rama sin validación ni escape.
Esto permite la inyección de comandos, lo que posibilita que un atacante ejecute comandos shell arbitrarios en el host de build de Jenkins.
El método createValue que gestiona la entrada del usuario (p. ej., desde la carga útil JSON del POST HTTP), aquí es donde Jenkins acepta los valores de parámetros proporcionados por el usuario a través de la solicitud (por ejemplo, "selected": "master; rm -rf /").
La entrada se envuelve en un GitParameterValue, que extiende StringParameterValue, sin saneamiento ni validación de la entrada.
Esto significa que los datos en bruto del usuario se aceptan como parámetro de build y se almacenan como instancia de ParameterValue.
La clase GitParameterValue que extiende StringParameterValue, GitParameterValue hereda de StringParameterValue pero no añade saneamiento.
La cadena de constructores implica que la entrada del usuario queda ahora almacenada en un objeto que Jenkins utilizará más adelante para construir las variables de entorno.
Esto propaga la entrada maliciosa a las variables de entorno del build de Jenkins.
"
La clase StringParameterValue y su método buildEnvironment, este método es crucial — expone el parámetro como variables de entorno en el contexto del build al hacer
"
env.put(name, value);
env.put(name.toUpperCase(Locale.ENGLISH), value);
Dado que el valor es una entrada de usuario sin saneamiento, permite que la entrada maliciosa entre en las variables de entorno de Jenkins, haciéndola accesible a procesos posteriores como los comandos de Git.
El método _checkout del plugin GitSCM, este método llama a build.getEnvironment(listener), que recopila las variables de entorno, incluida la maliciosa establecida anteriormente.
Utiliza estas variables para obtener el nombre de rama (mediante localBranchName), que luego se pasa al CheckoutCommand.
La variable de entorno del parámetro malicioso fluye directamente al proceso de checkout.
La creación del CheckoutCommand y el establecimiento de la rama/ref con la entrada del usuario, CheckoutCommand.branch(localBranchName) utiliza la variable de entorno sin saneamiento.
Dado que localBranchName proviene de variables de entorno controladas por el usuario, inyecta comandos arbitrarios en el checkout, esto prepara el terreno para la inyección de comandos cuando se llama a execute().
ElCheckoutCommand.execute()` que ejecuta el comando de la CLI de Git, este es el paso final en el que la cadena de rama inyectada se pasa directamente a la CLI de Git del sistema sin escape ni saneamiento, como resultado, la carga útil maliciosa se ejecuta como comandos shell, lo que permite la ejecución remota de código en el host de Jenkins.
Este análisis revela cómo el plugin Git Parameter de Jenkins, combinado con el plugin Git SCM, puede dar lugar a una vulnerabilidad crítica de inyección de comandos. Al exponer de forma insegura los valores de parámetros controlados por el usuario como variables de entorno y pasarlos posteriormente directamente a los comandos de la CLI de Git sin el saneamiento adecuado, los atacantes pueden ejecutar comandos arbitrarios en el servidor de build de Jenkins.
Esta cadena de ruptura de confianza—desde la carga útil JSON maliciosa inicial hasta la ejecución final del shell—destaca la importancia de una validación estricta de la entrada y de un manejo seguro de los parámetros de build en los sistemas de integración continua.
Los usuarios y administradores deben asegurarse de ejecutar versiones actualizadas de Jenkins y de todos los plugins, y auditar cuidadosamente cualquier parámetro que influya en los comandos shell. Mitigaciones como el saneamiento de la entrada, la lista blanca de ramas permitidas o el aislamiento de los entornos de build pueden reducir el riesgo.
Comprender este flujo proporciona a los profesionales de la seguridad y a los desarrolladores la visión necesaria para detectar, prevenir y remediar vulnerabilidades de inyección similares en Jenkins o en plataformas CI/CD comparables.
método