https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 14:56:05 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-328300 EUVD-2026-328300 https://cve.radiocsirt.org/vuln/euvd-2026-328300 https://cve.radiocsirt.org/vuln/fkie_cve-2026-44587 <p>CarrierWave is a framework to upload files from Ruby applications. In versions prior to 2.2.7 and 3.1.3, the content_type_denylist check fails to escape regex metacharacters in string entries, causing the denylist to silently not match the content types it is intended to block. In lib/carrierwave/uploader/content_type_denylist.rb:57, denylist entries are interpolated directly into a regex without Regexp.quote or anchoring, so an entry such as image/svg+xml becomes the pattern /image\/svg+xml/, in which + is treated as a quantifier rather than a literal character and therefore never matches the real MIME type image/svg+xml. This is inconsistent with the allowlist implementation, which correctly applies both Regexp.quote and a \A anchor. Other content types containing regex metacharacters, such as application/xhtml+xml, are affected as well. As a result, any application that relies on content_type_denylist to block image/svg+xml, most commonly to prevent stored XSS, is silently unprotected. An attacker can upload an SVG file containing arbitrary JavaScript; if the application serves that SVG inline from its own origin, the script executes in the victim&#39;s browser, resulting in stored XSS. This issue has been fixed in versions 2.2.7 and 3.1.3.</p> <p>CarrierWave is a framework to upload files from Ruby applications. In versions prior to 2.2.7 and 3.1.3, the content_type_denylist check fails to escape regex metacharacters in string entries, causing the denylist to silently not match the content types it is intended to block. In lib/carrierwave/uploader/content_type_denylist.rb:57, denylist entries are interpolated directly into a regex without Regexp.quote or anchoring, so an entry such as image/svg+xml becomes the pattern /image\/svg+xml/, in which + is treated as a quantifier rather than a literal character and therefore never matches the real MIME type image/svg+xml. This is inconsistent with the allowlist implementation, which correctly applies both Regexp.quote and a \A anchor. Other content types containing regex metacharacters, such as application/xhtml+xml, are affected as well. As a result, any application that relies on content_type_denylist to block image/svg+xml, most commonly to prevent stored XSS, is silently unprotected. An attacker can upload an SVG file containing arbitrary JavaScript; if the application serves that SVG inline from its own origin, the script executes in the victim&#39;s browser, resulting in stored XSS. This issue has been fixed in versions 2.2.7 and 3.1.3.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-44587 https://cve.radiocsirt.org/vuln/ghsa-7g26-2qgj-chfg <p><strong>Affected:</strong> RubyGems: carrierwave</p> <p>### Summary CarrierWave&#39;s content_type_denylist check fails to escape regex metacharacters in string entries, causing the denylist to silently not match the content types it is intended to block.</p> <p>**Note**: CarrierWave is aware `#content_type_denylist is deprecated for the security reason`, but it still used by developers, and the problem here isn&#39;t denylist allows any filetype, and thats not a vulnerability in carrierwave, its an implementation problem in developers using CarrierWave, the problem is its denylist entries are interpolated directly into a regex without `Regexp.quote` or anchoring. The denylist is still useful when developers want to ban specific content types but allow everything else.</p> <p>### Details In `lib/carrierwave/uploader/content_type_denylist.rb:57`, string denylist entries are interpolated directly into a regex without `Regexp.quote` or anchoring:</p> <p>```ruby def denylisted_content_type?(denylist, content_type) Array(denylist).any? { |item| content_type =~ /#{item}/ } end The entry &#34;image/svg+xml&#34; becomes the regex /image\/svg+xml/ where + is a quantifier meaning &#34;one or more g&#34;, not a literal +. This regex never matches the real MIME type &#34;image/svg+xml&#34; which contains a literal +. This is inconsistent with the allowlist implementation at lib/carrierwave/uploader/content_type_allowlist.rb:53-57, which correctly applies both Regexp.quote and a \A anchor: rubydef allowlisted_content_type?(allowlist, content_type) Array(allowlist).any? do |item| ite…</p> <p><strong>Affected:</strong> RubyGems: carrierwave</p> <p>### Summary CarrierWave&#39;s content_type_denylist check fails to escape regex metacharacters in string entries, causing the denylist to silently not match the content types it is intended to block.</p> <p>**Note**: CarrierWave is aware `#content_type_denylist is deprecated for the security reason`, but it still used by developers, and the problem here isn&#39;t denylist allows any filetype, and thats not a vulnerability in carrierwave, its an implementation problem in developers using CarrierWave, the problem is its denylist entries are interpolated directly into a regex without `Regexp.quote` or anchoring. The denylist is still useful when developers want to ban specific content types but allow everything else.</p> <p>### Details In `lib/carrierwave/uploader/content_type_denylist.rb:57`, string denylist entries are interpolated directly into a regex without `Regexp.quote` or anchoring:</p> <p>```ruby def denylisted_content_type?(denylist, content_type) Array(denylist).any? { |item| content_type =~ /#{item}/ } end The entry &#34;image/svg+xml&#34; becomes the regex /image\/svg+xml/ where + is a quantifier meaning &#34;one or more g&#34;, not a literal +. This regex never matches the real MIME type &#34;image/svg+xml&#34; which contains a literal +. This is inconsistent with the allowlist implementation at lib/carrierwave/uploader/content_type_allowlist.rb:53-57, which correctly applies both Regexp.quote and a \A anchor: rubydef allowlisted_content_type?(allowlist, content_type) Array(allowlist).any? do |item| ite…</p> https://cve.radiocsirt.org/vuln/ghsa-7g26-2qgj-chfg https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-44587 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: ruby-carrierwave, Ubuntu:Pro:18.04:LTS: ruby-carrierwave, Ubuntu:Pro:20.04:LTS: ruby-carrierwave, Ubuntu:Pro:22.04:LTS: ruby-carrierwave, Ubuntu:Pro:24.04:LTS: ruby-carrierwave</p> <p>CarrierWave is a framework to upload files from Ruby applications. In versions prior to 2.2.7 and 3.1.3, the content_type_denylist check fails to escape regex metacharacters in string entries, causing the denylist to silently not match the content types it is intended to block. In lib/carrierwave/uploader/content_type_denylist.rb:57, denylist entries are interpolated directly into a regex without Regexp.quote or anchoring, so an entry such as image/svg+xml becomes the pattern /image\/svg+xml/, in which + is treated as a quantifier rather than a literal character and therefore never matches the real MIME type image/svg+xml. This is inconsistent with the allowlist implementation, which correctly applies both Regexp.quote and a \A anchor. Other content types containing regex metacharacters, such as application/xhtml+xml, are affected as well. As a result, any application that relies on content_type_denylist to block image/svg+xml, most commonly to prevent stored XSS, is silently unprotected. An attacker can upload an SVG file containing arbitrary JavaScript; if the application serves that SVG inline from its own origin, the script executes in the victim&#39;s browser, resulting in stored XSS. This issue has been fixed in versions 2.2.7 and 3.1.3.</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: ruby-carrierwave, Ubuntu:Pro:18.04:LTS: ruby-carrierwave, Ubuntu:Pro:20.04:LTS: ruby-carrierwave, Ubuntu:Pro:22.04:LTS: ruby-carrierwave, Ubuntu:Pro:24.04:LTS: ruby-carrierwave</p> <p>CarrierWave is a framework to upload files from Ruby applications. In versions prior to 2.2.7 and 3.1.3, the content_type_denylist check fails to escape regex metacharacters in string entries, causing the denylist to silently not match the content types it is intended to block. In lib/carrierwave/uploader/content_type_denylist.rb:57, denylist entries are interpolated directly into a regex without Regexp.quote or anchoring, so an entry such as image/svg+xml becomes the pattern /image\/svg+xml/, in which + is treated as a quantifier rather than a literal character and therefore never matches the real MIME type image/svg+xml. This is inconsistent with the allowlist implementation, which correctly applies both Regexp.quote and a \A anchor. Other content types containing regex metacharacters, such as application/xhtml+xml, are affected as well. As a result, any application that relies on content_type_denylist to block image/svg+xml, most commonly to prevent stored XSS, is silently unprotected. An attacker can upload an SVG file containing arbitrary JavaScript; if the application serves that SVG inline from its own origin, the script executes in the victim&#39;s browser, resulting in stored XSS. This issue has been fixed in versions 2.2.7 and 3.1.3.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-44587