CVE-2026-126074: Possible DoS vulnerability in Active Storage filename handling
Affects activestorageSource GCVE Database
Not known to be exploited · CVSS 4.3 Medium : upgrade to 8.1.4.1 when convenient.
Data as of 10 Nov 2026, 22:34 UTC
Thin evidence
One scorer or none| CNA (GitHub_M) | CVSS 3.1 | 4.3 |
|---|
- Patch
- Available – fixed in 8.1.4.1, 8.0.5.2
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:LExploitation evidence
Disclosed: evidence found.
CVE published 10 Nov 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 10 Nov 2026.
What to do
Upgrade activestorage to 8.1.4.1; activestorage to 8.0.5.2.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| RubyGemsactivestorage | Affected
| Fixed in
|
| RubyGemsactivestorage | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
### Impact `ActiveStorage::Filename#base` and `#extension_with_delimiter`, and therefore `#extension`, pass the stored filename unmodified to `File.basename` and `File.extname`, which raise `ArgumentError` when the name contains a NUL byte. Active Storage stores the client-supplied filename verbatim, so a user who is permitted to upload an attachment could persist such a filename on databases that accept NUL bytes in string columns, such as SQLite and MySQL/MariaDB. Each subsequent request that builds a variant or preview of the blob, opens it, or renders it as an Action Text attachment then raises, possibly resulting in a persistent DoS vulnerability for the pages that display the blob until it is purged or its filename is corrected. Applications that use PostgreSQL are not affected, because PostgreSQL rejects the row. ### Details `Filename#base` and `#extension_with_delimiter` now derive from `Filename#sanitized`, the form that `Filename#to_s` and the `Content-Disposition` header already use. For a filename that `#sanitized` changes, such as one containing a NUL byte, an invalid byte sequence, a path separator or another replaced character, the base and extension now agree with `#to_s`; the variant format inferred from such a name may change, and an existing variant may be regenerated once. Stored filenames are not modified, and no data migration is required. ### Releases The fixed releases are available at the normal locations. Patches for those who cannot upgrade at once: - 8.1: https://github.com/rails/rails/commit/60f22af88b71eae251f112d8c0237a08a8832692.patch - 8.0: https://github.com/rails/rails/commit/9b0d4bef2211a2c08cab2e0ea17fa1d0efd5d47a.patch ### Credit This issue was found by the Anthropic OSS Scanner (ANT-2026-UQM5Z4YL).
References
- github.com/rails/rails/security/advisories/GHSA-p2pm-g2h6-7j5j (opens in a new tab)
- github.com/rails/rails/commit/60f22af88b71eae251f112d8c0237a08a8832692 (opens in a new tab)
- github.com/rails/rails/commit/9b0d4bef2211a2c08cab2e0ea17fa1d0efd5d47a (opens in a new tab)
- github.com/rails/rails (opens in a new tab)
- github.com/rails/rails/releases/tag/v8.0.5.2 (opens in a new tab)
- github.com/rails/rails/releases/tag/v8.1.4.1 (opens in a new tab)
- github.com/rubysec/ruby-advisory-db/blob/master/gems/activestorage/GHSA-p2pm-g2h6-7j5j.yml (opens in a new tab)