CVE-2023-38037

What it actually does

This vulnerability is a local information disclosure flaw in Rails ActiveSupport::EncryptedFile. When encrypted application secrets are decrypted for editing, the plaintext is written to a temporary file whose permissions are governed by the invoking user's current umask. If the umask is permissive, another local user with filesystem access to the same host can read the temporary plaintext file during the editing window. The primary impact is confidentiality loss of secrets such as credentials, API keys, database passwords, signing keys, or tokens; integrity and availability impact are secondary and depend on what the exposed secrets allow an attacker to do.

Why it matters to the business

An attacker who already has local access to a shared host, build runner, development workstation, or administrative server may be able to steal application secrets while they are being edited. Compromise of those secrets can lead to unauthorized access to production services, cloud resources, databases, payment systems, or third-party integrations. Although this is not remotely exploitable by itself and has low EPSS with no known KEV listing, the business risk can be high where Rails credentials are edited on multi-user systems or CI/CD infrastructure because a brief local exposure can become a broader credential compromise.

How an attack unfolds

An attacker first needs local access to the same operating system where a privileged user edits an encrypted Rails/ActiveSupport file. The attacker monitors temporary-file locations or filesystem activity while waiting for an administrator or developer to run a credentials or encrypted-file edit workflow. When ActiveSupport decrypts the encrypted content, it places the plaintext in a temporary file. If the editing user's umask produces group- or world-readable permissions, the attacker opens and copies the temporary file before it is re-encrypted and removed. The attacker then uses any recovered secrets, such as service credentials or signing keys, to access downstream systems or escalate the compromise outside the original host.

How to fix it

Upgrade Rails/ActiveSupport to a vendor-fixed version for the affected branch as soon as possible. If exact fixed package versions are not available from inventory metadata, consult the official Rails security advisory and update to the latest supported patch release for the deployed Rails branch. As an immediate mitigation, ensure sensitive encrypted-file editing is performed with a restrictive umask such as 077 so temporary files are readable only by the editing user. Avoid editing encrypted credentials on shared multi-user systems, CI runners, jump boxes, or hosts where untrusted users have shell or filesystem access. Restrict local account access, harden temporary-directory permissions, and consider rotating any secrets that may have been edited on exposed systems while vulnerable versions were in use.

How to confirm the fix worked

Confirm the installed Rails/ActiveSupport version is at or above the vendor-fixed release for the deployed branch. Reproduce the sensitive workflow in a non-production test environment by setting the same umask used operationally, running the encrypted-file or credentials edit command, and inspecting the resulting temporary file permissions while the editor is open. The fix or mitigation is effective when temporary plaintext files are not readable by group or other users. Also validate that operational procedures require a restrictive umask, and review shell profiles, CI job definitions, sudo policies, and automation scripts to ensure they do not set permissive umask values before secret-editing workflows.

Typical attack path

1. Obtain low-privileged local access to a shared system, developer workstation, build host, or application administration server.
2. Identify that the system is used to manage Rails or ActiveSupport encrypted configuration files.
3. Monitor temporary directories and process activity for Rails credential editing or encrypted-file editing workflows.
4. Wait for a legitimate user to edit encrypted credentials or another ActiveSupport::EncryptedFile-backed secret.
5. Read the plaintext temporary file if its permissions are group- or world-readable due to an unsafe umask.
6. Copy exposed secrets before the editor exits and the temporary file is removed or re-encrypted.
7. Use the stolen secrets to access databases, cloud services, application sessions, APIs, or other protected resources.

How to detect it

There are no reliable remote network indicators for this issue because exploitation requires local filesystem access and occurs during a short editing window. Review endpoint telemetry, auditd logs, EDR file access events, shell history, process accounting, and sudo logs on systems where Rails encrypted credentials are edited. Look for credential-editing commands followed by access to temporary files by a different local user, especially reads from /tmp, /var/tmp, or editor-specific temporary locations while an editor process is open. On Linux, audit rules for open/openat/read events on temporary directories and process executions of rails credentials editing commands can help identify suspicious access. Investigate cases where temp files containing decrypted secrets had permissions such as 0644, 0664, or other group/world-readable modes. If exploitation is suspected, treat any secrets edited during the exposure window as compromised and rotate them.

• rails credentials:edit
• bin/rails credentials:edit
• rails encrypted:edit
• ActiveSupport::EncryptedFile
• /tmp/
• /var/tmp/
• umask 000
• umask 002
• umask 022
• umask 027
• credentials.yml.enc
• master.key
• config/credentials.yml.enc
• config/master.key

What your security team should do

• Prioritize patching Rails/ActiveSupport on systems where encrypted credentials are edited, especially shared Linux hosts, CI/CD runners, bastion hosts, and developer workstations with multiple local users.
• Set and enforce a restrictive umask, preferably 077, for accounts and automation that edit encrypted Rails credentials or other encrypted application files.
• Inventory where Rails encrypted credentials are edited and remove that activity from shared or untrusted multi-user systems.
• Review local user access to systems used for secret management and remove unnecessary shell accounts or filesystem access.
• Search audit, shell, and process logs for evidence that non-owner users accessed temporary plaintext files during credential-editing sessions.
• Rotate secrets that were edited on vulnerable systems where permissive umask settings or untrusted local users were present.
• Add secure secret-editing procedures to engineering runbooks and CI/CD hardening standards.