CVE-2026-44587: CarrierWave Content-Type Denylist Regex Bypass (Stored XSS)

Technical summary

The vulnerability stems from improper regex construction in CarrierWave's content_type_denylist implementation (lib/carrierwave/uploader/content_type_denylist.rb:57). When denylist entries are interpolated directly into a regex pattern without escaping via Regexp.quote or anchoring with \A, MIME types containing regex metacharacters are misinterpreted. For example, the intended denylist entry 'image/svg+xml' becomes the unanchored pattern /image\/svg+xml/, where the '+' quantifier matches one or more 'l' characters instead of a literal '+' sign, causing the pattern to never match the actual MIME type 'image/svg+xml'. The allowlist mechanism correctly applies both Regexp.quote and anchoring, highlighting the inconsistency. Any MIME type with regex special characters—including application/xhtml+xml, application/vnd.openxmlformats-officedocument.wordprocessingml.document, and others—suffers the same flaw. This results in silently ineffective filtering, not an error condition that would alert developers.

Business impact

Organizations relying on CarrierWave's content_type_denylist to enforce upload security policies face silent bypass of those controls. The primary risk is stored XSS via SVG uploads, which can lead to session hijacking, credential theft, malware distribution, or unauthorized actions performed on behalf of compromised users. For SaaS platforms or multi-tenant applications, a single malicious upload can affect all users who view the content. Incident response and remediation may require identifying and removing previously uploaded malicious files and notifying affected users. The silent nature of the failure—no warnings or exceptions are raised—means many deployments may already be compromised without detection.

Affected systems

CarrierWave versions prior to 2.2.7 (in the 2.2.x line) and prior to 3.1.3 (in the 3.x line) are vulnerable. Any Ruby application using CarrierWave with a configured content_type_denylist is at risk, particularly those that rely on this mechanism to block SVG or other MIME types with regex metacharacters. Applications that serve uploaded files inline from their own origin (rather than as attachments or from a separate domain) face the highest risk of XSS impact.

Exploitability

Exploitation requires no special privileges or authentication (if the application permits anonymous uploads) and minimal technical sophistication—an attacker simply uploads a .svg file containing malicious JavaScript. The success of the attack depends on two conditions: (1) the application must use content_type_denylist to block the file type, and (2) the application must serve the SVG inline from its own origin (not as an attachment download or from a CDN). User interaction is required for the XSS payload to execute (the victim must view a page serving the malicious SVG). The attack succeeds silently, with no indication to developers that the filter has failed.

Remediation

Upgrade CarrierWave to version 2.2.7 or later (if on the 2.2.x branch) or version 3.1.3 or later (if on the 3.x branch). These versions correct the regex construction to properly escape metacharacters and anchor patterns, ensuring denylist entries function as intended. As a defense-in-depth measure, applications should also enforce Content-Security-Policy headers to restrict script execution, serve uploaded content from a separate domain to prevent same-origin XSS, or validate file content (magic bytes) in addition to MIME-type checks.

Patch guidance

Verify the exact version of CarrierWave currently in use by checking your Gemfile.lock or running 'bundle show carrierwave'. Upgrade via bundler by updating your Gemfile to specify carrierwave >= 2.2.7 (for 2.2.x users) or >= 3.1.3 (for 3.x users), then run 'bundle update carrierwave'. Test the upgrade in a staging environment to confirm compatibility with your application's upload workflows and any custom carrierwave configurations. Consult the vendor advisory for any breaking changes or migration notes between your current version and the patched version.

Detection guidance

Review application logs for SVG or MIME-type uploads that should have been blocked by your content_type_denylist configuration. Inspect the public/uploaded-files directory (or equivalent storage) for any .svg files that were not explicitly allowed. If your application logs MIME types of rejected uploads, check for patterns suggesting attackers tested the denylist (e.g., repeated image/svg+xml uploads). Implement or enhance logging to record the MIME type and filename of all uploaded files, including those rejected. Consider scanning previously uploaded SVG files for embedded JavaScript or suspicious script tags.

Why prioritize this

While the CVSS score of 4.7 is moderate, the severity is significantly amplified by the silent failure mode and the prevalence of stored XSS as a high-impact attack vector. Organizations using CarrierWave should prioritize this patch if they (1) use content_type_denylist to block SVG or other risky MIME types, and (2) serve uploaded files inline from their own origin. Those with strict content-security-policy headers or separate-domain serving of uploads face lower practical risk but should still upgrade. The fix is low-complexity and low-risk, making it suitable for rapid rollout.

Risk score, explained

CVSS 4.7 (MEDIUM) reflects a network-accessible vulnerability with low attack complexity and low privileges required, but the impact is limited to confidentiality (C:L) and user interaction is required (UI:R). However, the silent bypass of security controls and the prevalence of stored XSS as a path to account compromise justify close attention. The true business risk depends on your specific deployment model (inline vs. attachment serving) and security posture (CSP headers, domain isolation).

Frequently asked questions