Rails Active Storage mishandles uploaded filenames that contain a NUL byte. The filename helpers raise an exception, and every page that renders, previews or builds a variant of that file then fails until the blob is purged or renamed. This is a general web framework flaw, not an AI-specific one. It matters only where ML-adjacent apps (annotation portals, model-card sites, dataset upload tools, LLM front ends) are built on Rails. Severity is medium (CVSS 4.3), with no public exploit, no Nuclei template and no KEV listing. EPSS data was not available. The attacker needs an authenticated account that can upload, and only SQLite and MySQL/MariaDB are exposed because PostgreSQL rejects the row. Rails has a large footprint (6,440 downstream dependents for this package), so inventory affected apps and upgrade to activestorage 8.1.4.1 or 8.0.5.2 in the normal patch cycle.
What is the risk?
Low to medium. Exploitation is trivial for any authenticated user who can upload an attachment, but the impact is limited to availability (CVSS A:L, no confidentiality or integrity impact). The effect is persistent, because the poisoned filename stays in the database and re-triggers the error on each request. It needs a database that stores NUL bytes in string columns (SQLite, MySQL/MariaDB); PostgreSQL deployments are not affected. There is no known active exploitation or public exploit code, and no EPSS data was available. The AI/ML exposure is indirect and applies only to Rails apps that serve AI workloads.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Anthropic Python | rubygems | >= 8.1.0.beta1, < 8.1.4.1 | 8.1.4.1 |
Do you use Anthropic Python? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade activestorage/Rails to 8.1.4.1 (8.1 line) or 8.0.5.2 (8.0 line). 2) If you cannot upgrade immediately, apply the upstream patches: commit 60f22af8 for 8.1 and commit 9b0d4bef for 8.0. 3) Detect existing poisoned records by querying active_storage_blobs for filenames containing NUL (\0) characters on SQLite or MySQL/MariaDB, then purge them or correct the filename. 4) Add input validation that rejects NUL bytes and path separators in uploaded filenames at the application edge. 5) Monitor error tracking for repeated ArgumentError (string contains null byte) from File.basename/File.extname in blob rendering paths. 6) Prefer PostgreSQL where feasible, since it rejects such rows. The fix does not modify stored filenames, so no data migration is required.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-126074?
Rails Active Storage mishandles uploaded filenames that contain a NUL byte. The filename helpers raise an exception, and every page that renders, previews or builds a variant of that file then fails until the blob is purged or renamed. This is a general web framework flaw, not an AI-specific one. It matters only where ML-adjacent apps (annotation portals, model-card sites, dataset upload tools, LLM front ends) are built on Rails. Severity is medium (CVSS 4.3), with no public exploit, no Nuclei template and no KEV listing. EPSS data was not available. The attacker needs an authenticated account that can upload, and only SQLite and MySQL/MariaDB are exposed because PostgreSQL rejects the row. Rails has a large footprint (6,440 downstream dependents for this package), so inventory affected apps and upgrade to activestorage 8.1.4.1 or 8.0.5.2 in the normal patch cycle.
Is CVE-2026-126074 actively exploited?
No confirmed active exploitation of CVE-2026-126074 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-126074?
1) Upgrade activestorage/Rails to 8.1.4.1 (8.1 line) or 8.0.5.2 (8.0 line). 2) If you cannot upgrade immediately, apply the upstream patches: commit 60f22af8 for 8.1 and commit 9b0d4bef for 8.0. 3) Detect existing poisoned records by querying active_storage_blobs for filenames containing NUL (\0) characters on SQLite or MySQL/MariaDB, then purge them or correct the filename. 4) Add input validation that rejects NUL bytes and path separators in uploaded filenames at the application edge. 5) Monitor error tracking for repeated ArgumentError (string contains null byte) from File.basename/File.extname in blob rendering paths. 6) Prefer PostgreSQL where feasible, since it rejects such rows. The fix does not modify stored filenames, so no data migration is required.
What systems are affected by CVE-2026-126074?
This vulnerability affects the following AI/ML architecture patterns: Rails-based web front ends for AI apps, Data labeling and dataset upload portals, RAG document ingestion interfaces, Model governance and reporting portals.
What is the CVSS score for CVE-2026-126074?
CVE-2026-126074 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.50%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029Denial of AI ServiceAML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
What are the technical details?
Original Advisory
### 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).
Exploitation Scenario
An attacker with a low-privilege account on a Rails-based AI document-intake or data-labeling portal uploads an attachment whose filename contains a NUL byte, for example report.pdf%00.png. Active Storage stores the name verbatim on a SQLite or MySQL backend. Every later request that builds a variant or preview, or renders the blob in a dashboard or Action Text view, raises ArgumentError. The pages used by analysts or reviewers stay broken until an administrator finds and purges the blob, which can disrupt dataset review or RAG content management.
Weaknesses (CWE)
CWE-248 — Uncaught Exception: An exception is thrown from a function, but it is not caught.
- [Requirements] The choice between a language which has named or unnamed exceptions needs to be done. While unnamed exceptions exacerbate the chance of not properly dealing with an exception, named exceptions suffer from the up call version of the weak base class problem.
- [Requirements] A language can be used which requires, at compile time, to catch all serious exceptions. However, one must make sure to use the most current version of the API as new exceptions could be added.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:LReferences
- github.com/advisories/GHSA-p2pm-g2h6-7j5j
- github.com/rails/rails/commit/60f22af88b71eae251f112d8c0237a08a8832692
- github.com/rails/rails/commit/9b0d4bef2211a2c08cab2e0ea17fa1d0efd5d47a
- github.com/rails/rails/releases/tag/v8.0.5.2
- github.com/rails/rails/releases/tag/v8.1.4.1
- github.com/rails/rails/security/advisories/GHSA-p2pm-g2h6-7j5j
- github.com/rubysec/ruby-advisory-db/blob/master/gems/activestorage/GHSA-p2pm-g2h6-7j5j.yml
Timeline
Related Vulnerabilities
CVE-2026-9460310.0Podman: checkpoint images override sandbox on run
Same package: anthropicCVE-2026-466339.8Twig: single-quote escape flaw in {% use %} allows RCE
Same package: anthropicCVE-2026-544498.8LangBot: RCE via arbitrary STDIO MCP command
Same package: anthropicCVE-2026-277758.8Gitea: cached permission check allows repo takeover
Same package: anthropicCVE-2026-75748.7Claude Desktop: VM integrity bypass enables RCE
Same package: anthropic