<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 13 Nov 2026 12:46:33 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-126085</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-126085</link>
      <description>&lt;p&gt;Active Storage makes it simple to upload and reference files in cloud services and attach those files to Active Record objects. Prior to 8.1.4.1 and 8.0.5.2, ActiveStorage::Service::GCSService#url_for_direct_upload does not bind the declared content length into the signed direct-upload URL, and #headers_for_direct_upload returns no length constraint, so the URL authorizes an upload body of any size. A direct-upload client could store a file larger than the byte_size it declared, and the resulting blob keeps the declared size, possibly bypassing application file size validations and quotas. This is the weakness that CVE-2020-8162 fixed in the S3 service. Applications that store files in Google Cloud Storage and accept direct uploads are affected. This issue is fixed in versions 8.1.4.1 and 8.0.5.2.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Active Storage makes it simple to upload and reference files in cloud services and attach those files to Active Record objects. Prior to 8.1.4.1 and 8.0.5.2, ActiveStorage::Service::GCSService#url_for_direct_upload does not bind the declared content length into the signed direct-upload URL, and #headers_for_direct_upload returns no length constraint, so the URL authorizes an upload body of any size. A direct-upload client could store a file larger than the byte_size it declared, and the resulting blob keeps the declared size, possibly bypassing application file size validations and quotas. This is the weakness that CVE-2020-8162 fixed in the S3 service. Applications that store files in Google Cloud Storage and accept direct uploads are affected. This issue is fixed in versions 8.1.4.1 and 8.0.5.2.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-126085</guid>
    </item>
    <item>
      <title>GHSA-hfr4-8rjc-97m2 — Active Storage: Possible circumvention of file size limits in Active Storage direct uploads to Google Cloud Storage</title>
      <link>https://db.gcve.eu/vuln/ghsa-hfr4-8rjc-97m2</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; RubyGems: activestorage&lt;/p&gt;
&lt;p&gt;### Impact
`ActiveStorage::Service::GCSService#url_for_direct_upload` does not bind the declared content length into the signed direct-upload URL, and `#headers_for_direct_upload` returns no length constraint, so the URL authorizes an upload body of any size. A direct-upload client could store a file larger than the `byte_size` it declared, and the resulting blob keeps the declared size, possibly bypassing application file size validations and quotas. This is the weakness that CVE-2020-8162 fixed in the S3 service.&lt;/p&gt;
&lt;p&gt;Applications that store files in Google Cloud Storage and accept direct uploads are affected.&lt;/p&gt;
&lt;p&gt;### Details
The fixed releases sign an `x-goog-content-length-range` header that matches the blob&amp;#39;s declared `byte_size` and return it from `headers_for_direct_upload`, so Cloud Storage rejects an upload body of any other size. Browsers send this header with the direct upload, so a bucket&amp;#39;s CORS configuration must list `x-goog-content-length-range` in `responseHeader`, or browser direct uploads fail after the upgrade. The Active Storage CHANGELOG and the CORS example in the Active Storage guide show the change.&lt;/p&gt;
&lt;p&gt;### Releases
The fixed releases are available at the normal locations.&lt;/p&gt;
&lt;p&gt;Patches for those who cannot upgrade at once:
- 8.1: https://github.com/rails/rails/commit/e19916cea31cbfb0030b165ae853b741f8dd57a7.patch
- 8.0: https://github.com/rails/rails/commit/7fe85a72a789eae5ee070ce3ee1dad10a8a5f70c.patch&lt;/p&gt;
&lt;p&gt;### Credit
This issue was responsibly reported by HackerOne r…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; RubyGems: activestorage&lt;/p&gt;
&lt;p&gt;### Impact
`ActiveStorage::Service::GCSService#url_for_direct_upload` does not bind the declared content length into the signed direct-upload URL, and `#headers_for_direct_upload` returns no length constraint, so the URL authorizes an upload body of any size. A direct-upload client could store a file larger than the `byte_size` it declared, and the resulting blob keeps the declared size, possibly bypassing application file size validations and quotas. This is the weakness that CVE-2020-8162 fixed in the S3 service.&lt;/p&gt;
&lt;p&gt;Applications that store files in Google Cloud Storage and accept direct uploads are affected.&lt;/p&gt;
&lt;p&gt;### Details
The fixed releases sign an `x-goog-content-length-range` header that matches the blob&amp;#39;s declared `byte_size` and return it from `headers_for_direct_upload`, so Cloud Storage rejects an upload body of any other size. Browsers send this header with the direct upload, so a bucket&amp;#39;s CORS configuration must list `x-goog-content-length-range` in `responseHeader`, or browser direct uploads fail after the upgrade. The Active Storage CHANGELOG and the CORS example in the Active Storage guide show the change.&lt;/p&gt;
&lt;p&gt;### Releases
The fixed releases are available at the normal locations.&lt;/p&gt;
&lt;p&gt;Patches for those who cannot upgrade at once:
- 8.1: https://github.com/rails/rails/commit/e19916cea31cbfb0030b165ae853b741f8dd57a7.patch
- 8.0: https://github.com/rails/rails/commit/7fe85a72a789eae5ee070ce3ee1dad10a8a5f70c.patch&lt;/p&gt;
&lt;p&gt;### Credit
This issue was responsibly reported by HackerOne r…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-hfr4-8rjc-97m2</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-126085</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-126085</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:16.04:LTS: rails, Ubuntu:Pro:18.04:LTS: rails, Ubuntu:Pro:20.04:LTS: rails, Ubuntu:Pro:22.04:LTS: rails, Ubuntu:24.04:LTS: rails, Ubuntu:26.10: rails, Ubuntu:26.04:LTS: rails&lt;/p&gt;
&lt;p&gt;Active Storage makes it simple to upload and reference files in cloud services and attach those files to Active Record objects. Prior to 8.1.4.1 and 8.0.5.2, ActiveStorage::Service::GCSService#url_for_direct_upload does not bind the declared content length into the signed direct-upload URL, and #headers_for_direct_upload returns no length constraint, so the URL authorizes an upload body of any size. A direct-upload client could store a file larger than the byte_size it declared, and the resulting blob keeps the declared size, possibly bypassing application file size validations and quotas. This is the weakness that CVE-2020-8162 fixed in the S3 service. Applications that store files in Google Cloud Storage and accept direct uploads are affected. This issue is fixed in versions 8.1.4.1 and 8.0.5.2.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:16.04:LTS: rails, Ubuntu:Pro:18.04:LTS: rails, Ubuntu:Pro:20.04:LTS: rails, Ubuntu:Pro:22.04:LTS: rails, Ubuntu:24.04:LTS: rails, Ubuntu:26.10: rails, Ubuntu:26.04:LTS: rails&lt;/p&gt;
&lt;p&gt;Active Storage makes it simple to upload and reference files in cloud services and attach those files to Active Record objects. Prior to 8.1.4.1 and 8.0.5.2, ActiveStorage::Service::GCSService#url_for_direct_upload does not bind the declared content length into the signed direct-upload URL, and #headers_for_direct_upload returns no length constraint, so the URL authorizes an upload body of any size. A direct-upload client could store a file larger than the byte_size it declared, and the resulting blob keeps the declared size, possibly bypassing application file size validations and quotas. This is the weakness that CVE-2020-8162 fixed in the S3 service. Applications that store files in Google Cloud Storage and accept direct uploads are affected. This issue is fixed in versions 8.1.4.1 and 8.0.5.2.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-126085</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-4317 — Ruby on Rails: Mehrere Schwachstellen</title>
      <link>https://db.gcve.eu/vuln/wid-sec-w-2026-4317</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Ruby on Rails ausnutzen, um beliebigen Programmcode auszuführen, um einen Denial of Service Angriff durchzuführen, um Informationen offenzulegen, um Daten zu manipulieren, um falsche Informationen darzustellen, um einen Cross-Site Scripting Angriff durchzuführen und um Sicherheitsvorkehrungen zu umgehen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Ruby on Rails ausnutzen, um beliebigen Programmcode auszuführen, um einen Denial of Service Angriff durchzuführen, um Informationen offenzulegen, um Daten zu manipulieren, um falsche Informationen darzustellen, um einen Cross-Site Scripting Angriff durchzuführen und um Sicherheitsvorkehrungen zu umgehen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/wid-sec-w-2026-4317</guid>
    </item>
  </channel>
</rss>
