ActiveSupport, part of the popular Rails framework, helps developers keep sensitive data safe by handling encrypted files. But in 2023, a serious security issue was discovered: CVE-2023-38037. If you use ActiveSupport::EncryptedFile, your secrets might not be as secret as you hoped. In simple terms, it was possible for other users on the same computer to read your temporary files—even those supposed to be encrypted.

Let's break down what happened, look at some code, and show you how bad actors could take advantage. We’ll also give you simple ways to fix or avoid this issue.

What Is This Vulnerability?

When you edit an ActiveSupport::EncryptedFile, the tool writes the unencrypted contents to a temporary file so you can edit them. But there’s a catch: the file permissions depend on your system’s "umask" and weren’t explicitly set to be private.

What’s the risk? If your system is used by more than one person, someone else could open your temporary file while you’re working, and read secrets like API keys, passwords, or private messages.

Why Does This Happen? (With Code Example)

Normally, a temporary file should be readable only by you. Here’s some code that shows what the old behavior looked like:

# Example snippet based on affected logic

temp_file = Tempfile.new('secrets')
temp_file.write(decrypted_contents)  # decrypted_contents is your secret stuff!
temp_file.rewind

# temp_file gets permissions like 644 (-rw-r--r--), unless your umask is strict.

If your system's umask is set to the common default of 022, files created like this are readable by other users on the system (permissions rw-r--r--). That’s not good for secrets!

How Could an Attacker Exploit This?

Imagine "Alice" and "Bob" have accounts on the same server. Alice is editing her encrypted secrets; Bob is curious (or malicious). Here's how Bob might grab Alice’s secrets:

1. Monitor the /tmp directory (or wherever temporary files are stored).

As Bob

ls -l /tmp
cat /tmp/secrets20230609012345-123 # If permissions allow

`

If the file permissions let Bob read the file before Alice finishes editing, Bob can see all the secrets clear as day.

Official References

- Original CVE Report
- ActiveSupport Advisory
- Rails Security Releases

1. Upgrade Rails and ActiveSupport

The best solution is to update to the latest versions. Rails and ActiveSupport shipped patches that force the temp file to have restrictive permissions like 060 (owner can read/write, no one else):

# Newer, safer way
Tempfile.create('secrets', mode: 060) do |f|
  f.write(decrypted_contents)
end

As a quick workaround, manually set your umask before running the tools

umask 077
rails credentials:edit  # or however you edit the encrypted file

Or, in your own Ruby scripts, make sure to explicitly set the mode on temporary files.

Why This Matters for You

Even if you trust your coworkers or users, it's risky to assume they can’t make mistakes or be compromised. Secret leaks can lead to:

Summary

CVE-2023-38037 is a good reminder: never trust defaults for sensitive data. Always set file permissions directly for secrets. If you use ActiveSupport::EncryptedFile, update today or set your umask to the strictest setting. Don't let your secrets become an open book!

Further Reading & Official Resources

- CVE-2023-38037 at NVD
- Rails Security Advisories
- Tempfile Documentation

Timeline

Published on: 01/09/2025 01:15:07 UTC