Un secreto que ejecutaba código: postmortem de una vulnerabilidad en mi gestor de secretosA secret that ran code: post-mortem of a vulnerability in my own secrets manager

Una línea que parecía inofensiva#

Acabo de publicar un aviso de seguridad de gravedad alta, con una puntuación CVSS de 8,7, contra una herramienta mía: Vaultic, un gestor de secretos para equipos escrito en Rust. Todo el fallo cabía en estas líneas de la versión 1.4.2:

"github" => {
    if mask {
        println!("echo \"::add-mask::{value}\"");
    }
    println!("echo \"{key}={value}\" >> \"$GITHUB_ENV\"");
}
"gitlab" => {
    println!("export {key}=\"{value}\"");
}

Parecen inofensivas: imprimen una variable de entorno por línea, con su valor entre comillas. De hecho, es la misma sintaxis que enseña la documentación de GitHub para definir variables en un workflow. Y la documentación de Vaultic decía que se usaran así:

eval "$(vaultic ci export --env prod --format github)"

Si ya ves el problema, vas por delante. Si no, esta entrada es para ti: lo reproducimos con los binarios reales, vemos quién podía explotarlo y cómo se arregló, repasamos los fallos más pequeños que aparecieron detrás y contamos cómo se publicó.

Vaultic en dos minutos#

Vaultic nace de algo que he visto en casi todos los equipos en los que he trabajado: archivos .env con contraseñas y claves de API que se pasan por chat o por correo. En su lugar, Vaultic los cifra y los guarda en el propio repositorio, junto al código, y viajan con Git como cualquier otro archivo. Lo usamos en nuestro equipo en proyectos reales, con varios entornos y varias personas.

El cifrado es asimétrico y usa age. Cada persona tiene su par de claves, y .vaultic/recipients.txt guarda las claves públicas de todo el equipo. Al cifrar, el contenido se cifra una sola vez a partir de una clave de archivo aleatoria (con ChaCha20-Poly1305), y esa clave de archivo se cifra por separado para cada destinatario (con X25519). Esta es la cabecera real de un .env.enc de pruebas con dos destinatarios, una vez decodificada:

age-encryption.org/v1
-> X25519 NbUtRsMs0VKh++9Kv//IWVvFeUJ5iTlGho2sqk16FDk
bAFsWhFNKwB4LDBTyNokqs9OmctUG0Jumi+knI44RDA
-> X25519 kkSyhB9UFk+741ADe+2W9hjdtWb28EFV07CU70M8LS8
TwSKydQdVI+dESQD4MLWYVeE9YlxlNlJYS7I/KhXQlU
-> g1z8y-grease
XbknbG4IWhrYPriLmcTaFVwMvfxf+QUsHqmJ7ChzBu5L+bpnM8TXMYlrmjjZAQg8
fjmtUZv7FXVkhf9Rrd4DeWp8ke7o+PzF00vH2IXW
--- XKQxc+r/6LZzS3RE…

Cada bloque -> X25519 es la clave de archivo cifrada para una persona: quien descifra busca la suya y la abre con su clave privada. El tercero, grease, es relleno aleatorio que la biblioteca de age añade a propósito, para que los programas que leen el formato se acostumbren a ignorar tipos de destinatario que no conocen. Después de la línea --- empieza el contenido cifrado.

De ahí sale una propiedad que importa para el resto de la historia: las claves públicas no son secretas. Con una clave pública solo se puede cifrar, nunca descifrar, así que tenerlas en el repositorio es seguro. Es como la ranura de un buzón: cualquiera puede echar una carta, pero solo quien tiene la llave puede leerla. Quédate con eso: cualquiera puede echar una carta.

El fallo: datos que se convierten en código#

vaultic ci export descifra un entorno dentro de un pipeline de CI y lo imprime como comandos de shell, para que eval los ejecute y las variables queden definidas. El problema es que dentro de comillas dobles el shell sigue interpretando cosas: $VARIABLE, $(comando), las comillas invertidas y la barra invertida. El valor de un secreto dejaba de ser un dato y pasaba a ser código.

Para comprobarlo, compilé la 1.4.2 y la 1.4.3 desde sus etiquetas en el repositorio y cifré un entorno de pruebas con estos dos valores:

DB_PASSWORD=Kx9$$fT2w
API_TOKEN=tok_$(echo "  [!] esto se ha ejecutado" >&2)

Esto es lo que imprimía la 1.4.2 con --format gitlab:

export DB_PASSWORD="Kx9$$fT2w"
export API_TOKEN="tok_$(echo "  [!] esto se ha ejecutado" >&2)"

Y este script carga los secretos como decía la documentación, primero con una versión y después con la otra:

#!/bin/sh
# sh cargar.sh   (con vaultic-1.4.2 y vaultic-1.4.3 en la misma carpeta)
# Carga los secretos como decía la documentación, con cada versión
for v in 1.4.2 1.4.3; do
  echo "--- vaultic $v"
  eval "$(./vaultic-$v -q ci export --env dev --format gitlab)"
  echo "DB_PASSWORD=$DB_PASSWORD"
  echo "API_TOKEN=$API_TOKEN"
done

Esta es la salida real en mi equipo, con el sh de Git Bash en Windows 11:

--- vaultic 1.4.2
  [!] esto se ha ejecutado
DB_PASSWORD=Kx922537fT2w
API_TOKEN=tok_
--- vaultic 1.4.3
DB_PASSWORD=Kx9$$fT2w
API_TOKEN=tok_$(echo "  [!] esto se ha ejecutado" >&2)

Con la 1.4.2 pasan dos cosas, y las dos son malas:

• El valor de API_TOKEN se ejecuta. Aquí solo imprime un aviso, pero podría ser cualquier comando, y correría en el runner con los permisos del job, con acceso a todos sus secretos y tokens.
• La contraseña se corrompe sin que nadie ataque nada. $$ es una variable especial del shell, el PID del proceso, así que Kx9$$fT2w se convierte en Kx922537fT2w. Y las contraseñas generadas llevan $, comillas y barras constantemente.

En mis pruebas apareció un tercer caso: con una comilla invertida suelta en una contraseña, el eval entero falla con un error de sintaxis y no se carga ningún secreto del entorno.

Con la 1.4.3, los valores llegan intactos, contengan lo que contengan.

Vaultic está escrito en Rust y, como contamos en Por qué Rust sigue siendo el lenguaje más seguro en 2026, Rust elimina clases enteras de fallos de memoria. Pero este no es un fallo de memoria, sino de significado: ningún compilador sabe que un String va a acabar dentro de un shell.

¿Quién podía explotarlo?#

Aquí vuelve el buzón. Para meter un valor malicioso en un .env.enc no hace falta ninguna clave privada: bastan las claves públicas, que están en el repositorio. Así que cualquiera que pudiera llevar un .vaultic/*.env.enc modificado a una rama cuyo job de CI ejecute vaultic ci export con la clave privada (en la variable VAULTIC_AGE_KEY) podía ejecutar código en ese job.

Y hay un agravante: un archivo cifrado no se puede revisar. En un pull request, un cambio en dev.env.enc es un bloque de base64 que cambia entero. Quien revisa ve que se han actualizado los secretos, no un $(...) escondido dentro.

El vector CVSS del aviso lo resume así:

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N

Métrica a métrica:

PR:H es lo que impide que llegue a crítico: no lo puede explotar cualquiera desde fuera. S:C es lo que lo sube tanto: quien ejecuta el código ya no es Vaultic, es tu infraestructura de CI.

El arreglo: comillas simples#

Dentro de comillas simples, un shell POSIX no expande nada: ni variables, ni comandos, ni barras invertidas. El único carácter que hay que tratar es la propia comilla simple, que se cierra, se escapa y se vuelve a abrir. Esta es la función entera del arreglo:

/// Quote `s` for POSIX shells. Inside single quotes nothing is expanded,
/// so the only character to handle is the single quote itself.
fn shell_quote(s: &str) -> String {
    format!("'{}'", s.replace('\'', r"'\''"))
}

Con ella, --format gitlab imprime export API_TOKEN='tok_$(...)', y --format github pasa a usar printf en lugar de echo:

printf '%s\n' 'API_KEY=secret123' >> "$GITHUB_ENV"

printf '%s\n' imprime su argumento tal cual. echo no es tan predecible: según el shell, interpreta las barras invertidas o trata un -n como una opción.

Por qué '\''#

La parte más críptica del arreglo es cambiar cada ' por '\''. Dentro de comillas simples no se puede escapar nada, ni siquiera otra comilla simple, así que el truco consiste en salir de ellas un instante. Un valor como it's se convierte en 'it'\''s', que el shell lee como tres trozos pegados:

1. 'it': texto entre comillas simples.
2. \': una comilla simple escapada, fuera de las comillas.
3. 's': más texto entre comillas simples.

El shell une las palabras que van pegadas sin espacios, así que el resultado es exactamente it's. Y en ningún momento queda texto fuera de las comillas, salvo esa comilla escapada, que no puede hacer nada. El test shell_quote_escapes_single_quotes del arreglo comprueba este caso con a'b.

Además, con github y gitlab los nombres de variable tienen que ser identificadores de shell válidos; si no, la exportación falla antes de imprimir nada. Y lo que más me gusta del arreglo son sus tests: no comparan cadenas, sino que ejecutan de verdad el script generado con sh y comprueban que no se ha ejecutado nada:

#[cfg(unix)]
#[test]
fn github_does_not_execute_command_substitution() {
    let value = "p@$(echo PWNED)`echo PWNED2`\"'\\";
    let (env, stdout) = run_github_script(&format_github("PASS", value, false));
    assert_eq!(env, format!("PASS={value}\n"));
    assert!(!stdout.contains("PWNED"));
}

El segundo vector: saltos de línea en $GITHUB_ENV#

$GITHUB_ENV es un archivo que el runner de GitHub lee línea a línea: cada NOMBRE=valor define una variable para los pasos siguientes del job. Si un valor contuviera un salto de línea, lo que va detrás se leería como otra variable. Y hay variables peligrosas por sí mismas: LD_PRELOAD hace que cada proceso cargue una biblioteca, y BASH_ENV, que cada script de Bash ejecute antes un archivo. (NODE_OPTIONS sería otra, pero el runner de GitHub ya la rechaza en $GITHUB_ENV.)

Hoy el parser de .env de Vaultic lee línea a línea, así que un valor no puede traer un salto de línea real. Pero el formato de salida no debe depender de eso: el roadmap incluye parsers de YAML y JSON, que sí admiten valores de varias líneas. Para esos valores, GitHub define una sintaxis propia, NOMBRE<<DELIMITADOR, y su documentación avisa de que el delimitador no debe aparecer como línea dentro del valor. La 1.4.3 lo garantiza por construcción:

fn github_delimiter(value: &str) -> String {
    use sha2::{Digest, Sha256};
    let hash = format!("{:x}", Sha256::digest(value.as_bytes()));
    let mut delim = format!("VAULTIC_EOF_{}", &hash[..16]);
    while value.lines().any(|l| l == delim) {
        delim.push('_');
    }
    delim
}

El delimitador sale del hash del propio valor y, si aun así apareciera como línea, se alarga hasta que deje de aparecer. Un valor no puede cerrar el bloque antes de tiempo.

Los fallos pequeños que vinieron detrás#

Un fallo de inyección rara vez viaja solo. Al revisar el resto de caminos por los que pasan los secretos aparecieron cuatro más, de menor gravedad, que también arregla la 1.4.3.

1. Secretos que la máscara no tapaba#

--mask emite ::add-mask::valor, que pide al runner de GitHub que tape ese valor en los logs. Pero el runner decodifica %25, %0D y %0A en los datos de sus comandos, como se ve en su ActionCommand.cs. Un secreto que contuviera literalmente %0A se registraba con otro valor, y el original salía en claro en el log. El arreglo escapa % como %25 antes de enviarlo.

El mismo runner tiene otro detalle: lee la salida de cada paso con ReadLine de .NET, que también corta en un \r suelto. Un secreto con un \r dentro llegaba al log partido en dos líneas, y la máscara del valor completo no coincidía con ninguna. Ahora se enmascara cada trozo por separado.

2. Claves privadas legibles por otros usuarios#

Las claves privadas se escribían con los permisos por defecto del umask, normalmente 0644: legibles por cualquier usuario de la máquina. Ahora se crean con 0600, dentro de un directorio 0700, igual que los .env descifrados. Y vaultic status avisa si los permisos de tu clave son demasiado abiertos, con la misma comprobación que aplica ssh.

3. Un hash que confirmaba contraseñas#

El registro de auditoría, audit.log, se commitea con el repositorio y no guarda valores, solo metadatos. Pero al descifrar, la 1.4.2 guardaba el SHA-256 del archivo descifrado. Un hash no se puede invertir, pero sí se puede comprobar: si adivinas el contenido, calculas su hash y lo comparas. Y el contenido de un .env es muy adivinable, porque los nombres de las variables están en .env.template y muchos valores son predecibles. Esta es la entrada real que dejó la 1.4.2 en mi entorno de pruebas, con una identidad de git de pruebas, sin la fecha y formateada para leerla mejor:

{
  "author": "Ana",
  "email": "ana@example.com",
  "action": "decrypt",
  "files": ["prod.env.enc"],
  "detail": "2 variables decrypted to .env",
  "state_hash": "aed281bc6ec061b2e862e9dae6ba5a4726bc22a28b3b153b154f1e997aa4ca22"
}

Y este script, que solo usa ese hash, confirma la contraseña sin descifrar nada:

#!/bin/sh
# sh adivinar.sh   (en la raíz del proyecto, tras descifrar con la 1.4.2)
# El hash que la 1.4.2 dejaba en audit.log al descifrar (se commitea)
target=$(tail -1 .vaultic/audit.log | sed 's/.*"state_hash":"\([0-9a-f]*\)".*/\1/')
# Las claves salen de .env.template; solo falta adivinar la contraseña
for guess in 123456 password invierno2024 verano2024 qwerty; do
  h=$(printf 'PORT=5432\nDB_PASSWORD=%s\n' "$guess" | sha256sum | cut -d' ' -f1)
  [ "$h" = "$target" ] && echo "confirmada: DB_PASSWORD=$guess" && exit
done
echo "ninguna coincide"

Y su salida real:

confirmada: DB_PASSWORD=verano2024

Con una contraseña débil basta un diccionario; con una fuerte y aleatoria no hay nada que hacer. Pero una herramienta de secretos no debería regalar un oráculo para comprobar suposiciones. La 1.4.3 guarda el hash del archivo cifrado, que sigue sirviendo para detectar manipulaciones y no dice nada del contenido.

4. Archivos a medias#

Si encrypt --all se interrumpía a mitad de escribir un .enc, el archivo podía quedar truncado. Ahora todo se escribe de forma atómica: primero en un archivo temporal del mismo directorio, que se sincroniza con el disco y después se renombra sobre el original. Un corte deja el archivo viejo o el nuevo, nunca uno a medias.

Publicarlo#

Arreglarlo no basta: quien use una versión vulnerable tiene que enterarse. Estos fueron los pasos:

1. La versión 1.4.3, con los binarios verificables con SHA256 y firma minisign, publicada también en crates.io.
2. Un aviso de seguridad en GitHub, GHSA-5cfx-fmm5-7p2f, con el impacto, las versiones afectadas (de la 1.4.0 a la 1.4.2; la 1.3.0 aún no tenía ci export), el arreglo y alternativas para quien no pueda actualizar todavía. Cuando GitHub lo revise, pasará a su base de datos pública de avisos, de la que beben herramientas como Dependabot.
3. Una CVE, solicitada a GitHub, que es autoridad de numeración de CVE. Está en revisión; añadiré aquí el número cuando la asignen.
4. RustSec, la base de datos de avisos del ecosistema Rust que consulta cargo audit. Preparé el aviso en su formato y lo validé con su propio linter antes de enviarlo, pero un mantenedor cerró el PR: Vaultic no llega a su mínimo de popularidad, con 29 descargas recientes. El aviso era correcto; la regla es suya, y tiene sentido en una base de datos que mantienen voluntarios. La consecuencia práctica es que cargo audit no avisará de este fallo, así que los canales que cuentan son el aviso de GitHub y las notas de la versión.

La misma versión actualiza rustls, que usa la comprobación de actualizaciones, por cinco avisos de RustSec. Y el repositorio ejecuta ahora cargo audit cada semana y cada vez que cambian las dependencias.

Lo que me llevo#

• Nunca metas datos dentro de código que otro va a ejecutar. Si un valor acaba dentro de algo que se interpreta, necesita el escapado exacto de ese lenguaje. Para un shell POSIX, comillas simples.
• Documentar eval es una promesa fuerte. Si tu herramienta genera código para que el usuario lo ejecute, esa salida es superficie de ataque y merece tests que la ejecuten de verdad.
• Lo cifrado no se revisa solo. Trata los cambios en .vaultic/ como cambios de código: exige revisión, por ejemplo con CODEOWNERS, y que alguien con clave los descifre y compare antes de aprobar. Quien controla los secretos de un job controla su entorno.
• Quitar una clave no borra el pasado. Cuando alguien deja el equipo, vaultic keys remove y encrypt --all protegen las versiones nuevas, pero las antiguas siguen en el historial de Git, cifradas también para su clave. Hay que rotar los valores: contraseñas, tokens y claves de API.
• El hash de un secreto es un oráculo. Si necesitas detectar cambios, calcula el hash del texto cifrado, o usa un HMAC con una clave que no esté en el repositorio.
• Publica aunque tu proyecto sea pequeño. El aviso público es lo que permite a cada usuario saber si le afecta y qué hacer.

Si usas Vaultic#

Actualiza:

vaultic update            # o: cargo install vaultic --force

Si todavía no puedes, no uses eval con --format github ni con --format gitlab. Usa vaultic ci export --format generic > .env o vaultic decrypt --env <entorno> --stdout con un cargador de .env que no ejecute código, y revisa los cambios recientes en .vaultic/*.env.enc hechos por personas que no deberían controlar tu CI.