If your Rails master.key leaks, assume everyone who holds the matching credentials.yml.enc can read it, including past versions in Git. Generate a new key and credentials file, rotate every secret that was inside, change secret_key_base, and expect users to sign in again.
Why history matters
The Rails security guide says the encrypted credentials file can be stored in version control as long as the master key is safe. That works until the key is exposed. Every earlier commit of the encrypted file is then readable by whoever has the key. Removing the key from the repository later does not undo that.
So the question is not only what is in the file today. It is every secret that has ever been in it.
Triage steps
- Confirm what leaked and where: a commit, a log, a chat, a backup, a ticket.
- Cut off further exposure by removing the key from the place it sits.
- List every secret in current and past credentials files.
- Create a new credentials file with a new master key. Rails can generate these when you run
bin/rails credentials:editwith no existing key. - Rotate each external secret at its source: database password, API keys, webhook secrets, third party tokens.
- Change
secret_key_base. Usebin/rails secretto generate a new one. - Deploy with the new
RAILS_MASTER_KEY. - Review access logs and the provider logs for use of old secrets.
The secret_key_base consequences
The guide says that changing secret_key_base expires currently active sessions and requires everyone to log in again. Encrypted cookies, signed cookies and Active Storage files may also be affected. That is acceptable after a leak, because it also invalidates anything an attacker forged with the old base.
For non-urgent changes the guide describes cookie rotation, which lets old cookies be read and rewritten under a new configuration. That is for planned changes. After a leak, you want the old material to stop working, so do not keep it around.
Who needs to know
| Group | What to tell them |
|---|---|
| Engineering | New key distribution path, deploy window |
| Support | Users will be signed out |
| Security or compliance | Timeline, scope, secrets rotated |
| Vendors whose tokens changed | New credentials in place |
Afterwards
Write down how it leaked, and fix the path. Common causes are a key committed by mistake, a CI log that printed environment values, and a shared drive. Add a check so a file named master.key cannot be committed. Split credentials by environment so one leak does not reach production.
Quick check
Is deleting the commit enough?
No. Others may have cloned it, and caches may hold it. Rotate the secrets.
Do I need to rotate secrets that are not in the file?
Only if they could be reached through what was exposed. Start with the file contents, then follow where those secrets grant access.
Safeguard's compliance and evidence automation can keep a dated record of an incident response like this. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
