Dumping Jenkins Credentials — Don’t try this at 127.0.0.1, or try it!
Disclaimer: This content is for educational and informational purposes only. It is intended to raise awareness about security risks and best practices in Jenkins and DevOps environments. Unauthorized access, exploitation, or misuse of systems is illegal and unethical. Always follow your organization’s security policies and applicable laws.
I had a challenge these last days with one Jenkins instance because some of the secrets configured there were never documented; they existed only in Jenkins configuration. How could I get them if the Jenkins UI doesn’t show them?
Jenkins Packages
In jenkins, we have differente packages that serves different purposes.
hudson.util.Secret is a utility class used for encrypting and decrypting sensitive data, such as credentials stored in Jenkins. It is part of the hudson.util package.
Jenkins stores secrets (such as passwords, API keys) in an encrypted format using Secret.fromString().
When retrieving these values, Jenkins automatically decrypts them, but you can manually decrypt them using Secret.decrypt().
Retrieving the encrypted secrets
Luckily, there is an easy way to get them by inspecting the elements of the page in the developer mode when you are in the secrets page.
Go to Manage Jenkins >> Credentials >> Credentials you look for >> Update:
The secret will look like this:
{XXXXXXXXXXXXXXXXX=}Decrypting the Secret
Now that you have it, go to:
Manage Jenkins >> Script Console
Run the following:
println hudson.util.Secret.decrypt("{XXXXXXXXXXXXXXXXX=}")This line of code prints the decrypted value of the encrypted data, which is the plain text password that you want:
You can decrypt any Jenkins secret this way (if you have admin privileges).
I’m worried now. How do I protect my secrets?
Minimize Secrets Where possible
The best way to prevent credential leaks is to avoid storing secrets altogether. Many cloud providers, such as AWS, allow you to assign IAM roles to your infrastructure. By using identity-based access, your applications can securely authenticate without hardcoding credentials in Jenkins.
Secrets Should Be Dynamic, Not Static
A common mistake is storing long-lived credentials in Jenkins. Instead, use tools like AWS Secrets Manager or HashiCorp Vault to retrieve credentials at runtime. This ensures that credentials are short-lived and automatically rotated, reducing the risk of exposure.
Assume Secrets Are Plaintext
Jenkins is a build automation tool, not a secure vault. Anyone with access — devs, qa, even read-only users — can extract stored secrets. Instead of pretending Jenkins is secure, assume everything in it is visible and design your security model accordingly.
Want more insights on DevOps, security, and automation?
Don’t miss out — Follow me!
Connect with me on Linkedin!
