CVE-2026-33195

What it actually does

This is a path traversal vulnerability in Ruby on Rails Active Storage when using the local DiskService backend. Before Rails 8.1.2.1, 8.0.4.1, and 7.2.3.1, Active Storage did not verify that the filesystem path derived from a blob key stayed inside the configured storage root. If an application allows attacker-controlled input to influence Active Storage blob keys, a key containing traversal sequences such as ../ can resolve outside the storage directory. Depending on how the application uses Active Storage, this can allow the Rails process to read, write, or delete arbitrary files that are accessible to the application user account.

Why it matters to the business

Successful exploitation can expose sensitive server files, corrupt application data, or remove files needed for service operation. In higher-impact cases, arbitrary file write may enable application compromise if an attacker can overwrite files that Rails later loads or executes. The CVSS score is critical, but exploitation depends on whether an application passes untrusted input into Active Storage blob keys and uses the local DiskService backend. It is not currently listed in CISA KEV, is not marked as ransomware-used, has low EPSS, and has no indicated public exploit maturity, but affected internet-facing Rails applications should still prioritize remediation because the flaw can cross normal file-storage boundaries.

How an attack unfolds

An attacker first identifies a Rails application feature that creates, references, downloads, deletes, or otherwise operates on Active Storage blobs. The attacker then determines whether any request parameter, API field, import value, or indirect workflow can influence the blob key rather than letting Rails generate a trusted key. If the application passes that attacker-controlled value to Active Storage DiskService, the attacker submits a blob key containing path traversal sequences such as ../../../../etc/passwd or equivalent encoded variants. Vulnerable Rails versions resolve the resulting path without ensuring it remains beneath the configured storage root. The attacker can then trigger a read operation to retrieve files, a write operation to place or overwrite files, or a delete operation to remove files, limited by the filesystem permissions of the Rails process. Follow-on activity may include theft of credentials from configuration files, tampering with application content, deletion of operational files, or attempts to gain code execution by writing to locations loaded by the application.

How to fix it

Upgrade Rails to a patched version: 8.1.2.1 or later, 8.0.4.1 or later, or 7.2.3.1 or later, depending on the application’s Rails branch. If immediate upgrade is not possible, apply the vendor patch or an equivalent temporary guard that canonicalizes the resolved path and rejects any path that escapes the Active Storage root. Review application code for any use of user-supplied values as Active Storage blob keys; blob keys should be generated by Rails or another trusted random identifier generator, not accepted from request parameters, filenames, import metadata, or API clients. Prefer cloud/object storage backends where appropriate, restrict filesystem permissions on the storage root, run Rails under a least-privileged operating-system account, and ensure the application user cannot write to application code, configuration, system directories, or other sensitive paths.

How to confirm the fix worked

Confirm the deployed Rails version is 8.1.2.1, 8.0.4.1, 7.2.3.1, or newer. Inventory applications using Active Storage and identify which use the DiskService backend, especially in production or internet-facing deployments. Review dependency lockfiles such as Gemfile.lock to verify the patched rails, activestorage, and related Rails component versions are installed and deployed. Perform code review for direct assignment or construction of Active Storage keys from untrusted input. In a safe non-production environment, attempt to use a traversal-style key such as ../test and confirm Rails rejects it or confines it to the storage root. Also verify filesystem permissions prevent the Rails process from modifying application code, secrets, and operating-system paths.

Typical attack path

1. Find a Rails application using Active Storage with the local DiskService backend.
2. Identify an upload, import, attachment, file-management, or custom API path where user input can influence an Active Storage blob key.
3. Submit a crafted key containing traversal sequences such as ../, URL-encoded traversal, or double-encoded traversal.
4. Trigger an Active Storage operation that calls DiskService#path_for, such as file download, upload/write, delete, or metadata processing.
5. Access, overwrite, or delete files outside the intended Active Storage root, constrained by the Rails process privileges.
6. Use any exposed secrets, modified files, or deleted files to expand impact, disrupt service, or attempt further compromise.

How to detect it

Investigate whether exploitation has already occurred by correlating web access logs, Rails application logs, reverse proxy logs, WAF logs, background job logs, and host filesystem telemetry. Look for requests to upload, download, delete, or process Active Storage files that include traversal strings such as ../, URL-encoded traversal, double-encoded traversal, or backslash traversal. Review Rails logs for Active Storage DiskService errors, unexpected file-not-found or permission-denied exceptions, and file paths resolving outside the configured storage root. On hosts, examine file audit logs, EDR telemetry, and filesystem metadata for the Rails process reading sensitive files, writing outside the storage directory, modifying application code/configuration, or deleting unexpected files. Pay close attention to access to credentials, environment files, SSH keys, system account files, application initializers, dependency files, scheduled tasks, and web-served directories. Because exploitation requires application-specific unsafe key handling, absence of generic indicators does not prove safety; pair log review with code review and version validation.

• ../
• ..\\
• %2e%2e%2f
• %2e%2e/
• ..%2f
• %252e%252e%252f
• %c0%ae%c0%ae%c0%af
• storage/../
• /rails/active_storage/
• ActiveStorage::Service::DiskService
• ActiveStorage::FileNotFoundError
• Errno::EACCES
• Errno::ENOENT
• No such file or directory @ rb_sysopen
• Permission denied @ rb_sysopen
• /etc/passwd
• /etc/shadow
• /proc/self/environ
• config/master.key
• config/credentials.yml.enc
• .env
• id_rsa

What your security team should do

• Prioritize upgrading affected Rails applications using Active Storage DiskService to Rails 8.1.2.1, 8.0.4.1, 7.2.3.1, or later.
• Inventory all Rails applications that use Active Storage and determine whether local DiskService is enabled in any internet-facing, production, staging, or administrative environment.
• Review application code for unsafe blob key handling, especially custom upload APIs, import pipelines, direct DiskService calls, background jobs, and integrations that accept externally supplied file identifiers.
• Search recent web, application, and Rails logs for traversal payloads, encoded traversal sequences, unexpected Active Storage errors, and file operations outside the storage root.
• Harden runtime permissions so the Rails process cannot write to application source code, credentials, initializer files, system directories, or other sensitive locations.
• Add regression tests that ensure Active Storage blob keys cannot resolve outside the configured storage directory.
• If suspicious activity is found, rotate secrets that may have been readable by the Rails process and review file integrity for unauthorized writes or deletions.