Recuperar secretos GitHub Actions: hex dump y métodos

Si alguna vez guardaste una API key o un certificado en GitHub Actions y después te diste cuenta de que era la única copia que te quedaba, sabés lo que es ese frío en la nuca. GitHub no te deja ver el valor de un secreto después de guardarlo — solo podés sobrescribirlo. Pero si tenés acceso de escritura a los workflows del repo, recuperar secretos de GitHub Actions es posible con un par de trucos que evaden el enmascaramiento. El método más confiable es volcar el secreto en hexadecimal porque GitHub no registra esa representación, ni siquiera desde que también enmascara base64.

GitHub Actions Secrets es el mecanismo oficial para almacenar credenciales, tokens y claves que tus workflows necesitan en tiempo de ejecución. La plataforma los protege reemplazando cualquier coincidencia exacta del valor en los logs con ***, y también registra y enmascara automáticamente su versión en base64. El objetivo es que ni siquiera un volcado accidental exponga el secreto en texto plano — pero justamente por eso, recuperar uno que diste por perdido requiere conocer los puntos ciegos del sistema de masking.

¿Por qué GitHub Actions oculta los secretos en los logs?

El mecanismo es simple pero efectivo. Cuando definís un secreto en la configuración del repositorio — digamos MY_SECRET —, GitHub lo almacena cifrado y solo lo desencripta dentro del runner durante la ejecución del workflow. Cualquier línea de log que contenga el valor exacto del secreto se modifica antes de mostrarse: el texto coincidente se reemplaza por ***.

Esto aplica a coincidencias literales. Si tu secreto es password123 y hacés echo $MY_SECRET, el output será ***. Hasta ahí, todo bien.

El problema — o la solución, según cómo lo mires — es que el enmascaramiento solo cubre las formas que GitHub puede anticipar. El sistema registra el valor original y también su versión en base64. Pero no registra representaciones derivadas como hexadecimal, la cadena invertida, ni la cadena con espacios entre caracteres. GitHub no va a precomputar infinitas transformaciones de cada secreto — sería inviable y carísimo computacionalmente.

¿Qué métodos comunes fallan para recuperar un secreto?

Antes de ir a lo que funciona, repasemos lo que no. Porque cualquiera que haya googleado “recuperar secretos github actions” se topó primero con estos intentos fallidos. Más contexto en nuestra comparativa de CI/CD 2026.

echo directo: el clásico echo ${ secrets.MY_SECRET } devuelve ***. GitHub detecta la coincidencia exacta y la enmascara. No hay sorpresa acá.

base64: durante años, el bypass estándar fue echo ${ secrets.MY_SECRET } | base64. El resultado era una cadena distinta al secreto original, así que GitHub no la enmascaraba. Copiabas el base64, lo decodificabas localmente y listo. Pero GitHub se avivó. Ahora el sistema también calcula la versión base64 de cada secreto y la enmascara automáticamente. Si hacés el truco de base64 hoy, el output sigue siendo *** (o una cadena enmascarada equivalente).

Ojo: algunos foros viejos todavía recomiendan base64 como si funcionara. No les des bola. Eso caducó.

¿Cómo recuperar un secreto usando un hex dump?

El método que funciona y que el artículo de TheAxCode documenta en detalle es convertir el secreto a hexadecimal. GitHub no registra esta representación, así que pasa derechito al log sin máscara.

El workflow es así de simple:

• Almacenás el secreto en una variable: S="${ secrets.MY_SECRET }"
• Lo convertís a hex: echo "hex: $(printf %s "$S" | od -An -tx1 | tr -d '\n')"
• Ejecutás el workflow y copiás el output hexadecimal
• Decodificás localmente: echo '70 61 73 73 77 6f 72 64' | xxd -r -p te devuelve password

En el ejemplo del artículo fuente, el secreto password se vuelca como 70 61 73 73 77 6f 72 64. Eso pasa limpio por el enmascaramiento, lo copiás a tu terminal, y con xxd -r -p (o cualquier herramienta que decodifique hex) recuperás el valor original. Sin magia, sin dependencias externas, solo herramientas estándar de Linux que ya están en el runner.

El artículo también recomienda incluir un chequeo de longitud con wc -c como sanity check — si el largo coincide con lo que esperabas, es porque el valor se capturó completo y no hubo truncamiento silencioso.

Métodos alternativos: rev, spaced y otras transformaciones que evaden el masking

El hex dump es el método más confiable, pero no es el único. Si por algún motivo necesitás una alternativa (o querés verificar el resultado con un segundo método), hay un par de transformaciones que también sobreviven al enmascaramiento. Esto se conecta con lo que analizamos en el análisis real entre Jenkins y GitHub Actions.

Cadena invertida con rev: echo "$S" | rev. GitHub no invierte automáticamente tus secretos para enmascararlos. Si tu secreto es password, el log mostrará drowssap. Lo copiás, lo invertís de nuevo localmente y listo.

Caracteres espaciados con sed: echo "$S" | sed 's/./& /g'. Esto convierte password en p a s s w o r d. Al tener espacios entre cada letra, no coincide con el literal original ni con ninguna representación que GitHub tenga precomputada. Para recuperarlo, simplemente eliminás los espacios.

Solo la longitud con wc -c: echo "$S" | wc -c. Esto no te da el valor, pero te confirma cuántos caracteres tiene. Sirve como verificación adicional: si sabés que tu API key debería tener 32 caracteres y el output dice 33 (suma el newline), podés dormir tranquilo sabiendo que no perdiste bytes en el camino.

¿Funcionan siempre estos métodos? Probablemente sí, pero tomalo con pinzas. GitHub podría en algún momento agregar heurísticas para detectar patrones de inversión o espaciado, aunque por ahora no lo hace. El hex dump es más robusto porque es una transformación puramente numérica sin patrón textual evidente.

Tabla comparativa de métodos para recuperar secretos

Método	¿Funciona hoy (2026)?	Complejidad	Riesgo de detección futura
echo directo	No — devuelve ***	Ninguna	N/A
base64	No — también enmascarado	Baja	N/A
Hex dump (od)	Sí	Baja	Muy bajo
rev (invertir)	Sí	Mínima	Medio — si GitHub invierte automáticamente
sed (espaciado)	Sí	Mínima	Medio — si GitHub detecta espaciado
wc -c (longitud)	Sí — pero no revela el valor	Mínima	Nulo — no expone el contenido
OpenSSL (cifrado)	Sí — solo repo privado	Media	Bajo — pero solo para privados

¿Cómo recuperar secretos de forma segura con OpenSSL?

Si tu repositorio es privado y querés una capa extra de protección al recuperar un secreto, el método con OpenSSL es una opción. La idea es cifrar el secreto antes de imprimirlo, usando una contraseña que solo vos conocés. Así, aunque alguien accediera a los logs del workflow (improbable en un repo privado, pero posible), no podría descifrar el valor sin esa contraseña.

Los pasos son:

• Definís una contraseña de cifrado como variable de entorno en el workflow
• Cifrás el secreto con echo "$S" | openssl enc -aes-256-cbc -pbkdf2 -pass pass:$ENCRYPTION_PASSWORD -a
• El output es un blob cifrado en base64 que no coincide con ningún valor registrado
• Lo copiás a tu máquina local y descifrás con echo "blob" | openssl enc -aes-256-cbc -pbkdf2 -a -d -pass pass:tuPassword

La advertencia importante: esto solo es seguro en repositorios privados. En un repositorio público, los logs de workflows son visibles — y aunque el blob esté cifrado, dejás expuesto un cifrado que alguien con suficiente motivación podría intentar romper. No es el escenario más probable, pero la palabra clave acá es “podría”. Mejor no tentar a la suerte. Complementá con la guía de SEO internacional con hreflang.

¿Cómo enmascarar secretos dinámicos para prevenir exposición?

Hasta ahora hablamos de recuperar secretos que ya diste por perdidos. Pero también está la otra cara de la moneda: evitar que información sensible llegue a los logs en primer lugar. Para eso existe ::add-mask::. Podés registrar un valor dinámico como enmascarado en tiempo de ejecución imprimiendo ::add-mask::valor-sensible en el log. GitHub procesa ese comando y, de ahí en más, trata ese valor igual que un secreto definido en la UI: lo reemplaza con *** cada vez que aparece.

Esto es útil cuando generás tokens o credenciales dentro del mismo workflow — por ejemplo, un token efímero que obtenés de una API y necesitás pasar a otro paso sin que quede registrado. Hacés echo "::add-mask::$TOKEN" apenas lo recibís y te asegurás de que, incluso si un paso posterior hace un volcado accidental, el valor no aparezca en texto plano. ¿La limitación? El comando solo afecta el output posterior; si el token ya se imprimió antes del add-mask, fuiste.

Buenas prácticas para evitar la fuga de secretos en workflows

Los patrones más comunes por los cuales los secretos terminan expuestos sin que nadie se dé cuenta son:

• echo directo de secretos: el más obvio y el que más se repite. A veces queda de una sesión de debug, a veces alguien no sabía que el log es semi-público. Si el repo es público y hacés echo $SECRET, ese log queda accesible para siempre (sí, en serio).
• Artefactos que incluyen .env o configuraciones: generar un artefacto de build que por accidente incluye archivos de entorno es como dejar las llaves del auto en el capó. Si tu pipeline empaqueta un .env como parte del artefacto, cualquiera que descargue ese zip tiene acceso a todas las variables.
• Build tools en modo verbose: compiladores, bundlers y herramientas de despliegue que escupen variables de entorno cuando corren con flags como --verbose o --debug. No es que la herramienta tenga la culpa — es que le pediste que muestre todo y ella obedeció.
• pull_request_target desde forks: este evento es particularmente peligroso porque corre en el contexto del repo base con acceso a secretos, pero se dispara desde un PR de un fork. Un atacante puede modificar el workflow del fork para exfiltrar secretos del repo principal si no configurás restricciones.

La mitigación no es rocket science: usá OIDC en vez de secretos de larga duración cuando puedas, no incluyas archivos de entorno en artefactos, limitá el output de las herramientas de build, y revisá los logs de tus workflows cada tanto. Si tenés infraestructura en Latinoamérica y necesitás un entorno de CI/CD que integre bien con proveedores locales, servicios como donweb.com ofrecen opciones de cloud y VPS donde podés montar runners auto-hospedados sin depender de terceros.

Qué significa para equipos de desarrollo en Latinoamérica

Si trabajás en una startup o una software factory en Argentina, Colombia o México, probablemente GitHub Actions sea tu CI/CD por defecto. La combinación de repos privados (porque el código del cliente es confidencial) y la necesidad de rotar credenciales de infraestructura cloud hace que el tema de los secretos no sea teórico — es parte del día a día.

El dato concreto que muchos equipos pasan por alto: los logs de workflows en repositorios privados de GitHub solo son visibles para colaboradores, pero eso no significa que estén blindados. Un ex-empleado que todavía tenga acceso, un contractor con permisos mal configurados, o simplemente un integrante del equipo que comparte pantalla durante una videollamada pueden exponer información que pensabas que estaba a salvo. Recuperar un secreto con el método del hex dump es técnicamente posible — pero también es un recordatorio de que el sistema de enmascaramiento no es infalible.

Qué está confirmado y qué es especulación

• Confirmado: GitHub enmascara secretos en logs por coincidencia exacta y también enmascara su versión base64. El hex dump con od -An -tx1, la inversión con rev y el espaciado con sed evaden el enmascaramiento. El comando ::add-mask:: permite enmascarar valores dinámicos en tiempo de ejecución. Los métodos de recuperación dejan el secreto expuesto en logs, por lo que hay que borrar el workflow y sus ejecuciones después de usarlos.
• No confirmado: cuánto tiempo va a seguir funcionando el hex dump. GitHub no anunció planes de registrar representaciones hexadecimales, pero tampoco dijo que no vaya a hacerlo. La comunidad asume que es un cat-and-mouse game donde eventualmente GitHub podría cubrir más transformaciones, pero por ahora no hay indicios oficiales de que estén trabajando en eso.

Errores comunes al intentar recuperar secretos de GitHub Actions

Creer que base64 todavía funciona: si tu primera reacción al perder un secreto fue googlear “github actions recover secret base64”, no sos el único. Pero ese barco ya zarpó. GitHub enmascara base64. Si encontrás un tutorial viejo que lo recomienda, ignorá esa parte — el resto del artículo puede servir, pero el método está obsoleto. Te puede servir nuestra cobertura de cómo ejecutar agentes locales sin API.

Olvidarse de borrar los logs después de recuperar el secreto: este es grave. Ejecutaste el workflow, el secreto apareció en hex en el log, lo copiaste, lo decodificaste, y respiraste aliviado. ¿Y el log? Sigue ahí, con tu secreto expuesto para cualquiera que tenga acceso al repo. Borrá el workflow completo y sus ejecuciones apenas termines. No lo dejes para mañana — mañana te olvidás.

Asumir que el repo privado es un entorno seguro para recuperar secretos: sí, los logs de un repo privado no son públicos. Pero “privado” no es sinónimo de “blindado”. Si tu organización tiene 50 colaboradores, todos con acceso al repo, cualquiera puede ver el log. ¿Confías en los 50 por igual? Recuperar un secreto crítico en un repo con muchos colaboradores es jugar con fuego. Mejor hacerlo en un repo temporal con acceso mínimo.

No verificar la longitud del valor recuperado: el hex dump puede truncarse si el log de GitHub Actions corta líneas muy largas (aunque en general no pasa con secretos de tamaño razonable). Siempre chequeá el output con wc -c para confirmar que la cantidad de bytes coincide con lo que esperabas. Perder la mitad de un secreto y no darte cuenta es peor que no recuperarlo — porque creés que lo tenés y cuando intentás usarlo falla de formas difíciles de debuggear.

Preguntas Frecuentes

¿Es legal recuperar un secreto de GitHub Actions con estos métodos?

Sí, siempre que tengas acceso legítimo de escritura al repositorio y a sus workflows. GitHub no prohíbe estos métodos en sus términos de servicio — de hecho, el sistema de enmascaramiento está diseñado para prevenir filtraciones accidentales, no para bloquear a un owner que necesita recuperar su propia credencial. No estás vulnerando nada, estás usando una herramienta que el runner provee (od, rev, sed) para leer un valor que ya es tuyo.

¿Funciona el hex dump en cualquier tipo de secreto?

Funciona con cualquier secreto de texto. Si tu secreto contiene caracteres binarios o no imprimibles, el hex dump sigue siendo válido — de hecho, es la representación más segura para ese caso. La única limitación real es el tamaño: secretos extremadamente largos (varios kilobytes) podrían dividirse en múltiples líneas de log, complicando la reconstrucción. Para secretos típicos como API keys, tokens JWT o contraseñas, no hay problema.

¿GitHub notifica a los administradores si alguien recupera un secreto?

No, GitHub no tiene un mecanismo de alerta para esto. La ejecución de un workflow queda registrada en el historial de Actions, pero no se genera ninguna notificación especial por el hecho de que un workflow haya leído un secreto (todos los workflows que usan secretos los leen). Lo único que podría levantar sospechas es si alguien revisa los logs y ve el hex dump — de ahí la recomendación de borrar todo apenas termines.

¿El método OpenSSL sirve para repositorios públicos?

Técnicamente funciona, pero no se recomienda. En un repositorio público, los logs de workflow son visibles para cualquiera. Aunque el secreto esté cifrado con AES-256, dejás un blob cifrado expuesto que, con suficiente tiempo y recursos, podría ser atacado. La recomendación de la comunidad es usar repositorios privados para cualquier operación de recuperación de secretos.

¿Cómo evito perder secretos en el futuro?

Usá un gestor de secretos externo como vault de HashiCorp o el administrador de secretos de tu proveedor cloud. GitHub Actions Secrets está pensado para CI/CD, no como almacenamiento primario de credenciales. Si generás una API key, guardala también en un password manager o en un vault corporativo. La redundancia no es paranoia cuando hablamos de credenciales de producción.

Conclusión

Recuperar un secreto de GitHub Actions es más fácil de lo que GitHub quisiera, y eso es un arma de doble filo. Por un lado, te salva cuando diste por perdida la única copia de una credencial — con un workflow de cinco líneas y od -An -tx1 lo recuperás en minutos. Por otro lado, deja en evidencia que el sistema de enmascaramiento es ingenuo: si alguien con acceso al repo quiere exfiltrar secretos, no va a usar echo directo ni base64; va a usar hex dump, rev, o cualquier transformación que GitHub no haya cubierto todavía.

Lo que cambió es que GitHub cerró el agujero más obvio (base64) y la comunidad respondió con métodos más esotéricos que son igual de efectivos pero más difíciles de tapar sin romper la funcionalidad de los runners. La lección de fondo no es técnica — es de procesos: si un secreto solo existe dentro de GitHub Actions Secrets, eventualmente vas a necesitar recuperarlo. Y cuando eso pase, más vale que sepas cómo funciona el juego del gato y el ratón entre los devs y el masking engine.

Fuentes

• TheAxCode – Read your own GitHub Actions secret back: artículo publicado el 28 de junio de 2026 que documenta el método del hex dump, rev y caracteres espaciados con ejemplos prácticos.
• remarkablemark – GitHub Actions mask secret: explica el mecanismo de enmascaramiento y el uso de ::add-mask:: para valores dinámicos (enero 2026).
• VibeDoctor – GitHub Actions secrets leaking in workflow logs: análisis de patrones de fuga de secretos y buenas prácticas de mitigación en pipelines CI/CD.
• DEV Community – How to recover secrets from GitHub Actions: método de recuperación con OpenSSL y AES-256-CBC para repositorios privados.