Merge pull request #1244 from jasnow/sep-22a-advs

Two new faraday-http-cache advisories

@simi - Thanks for taking the time to review and approve this PR.

Author: jasnow

gems/faraday-http-cache/GHSA-c33f-42f2-gwcc.yml

@@ -0,0 +1,38 @@
+---
+gem: faraday-http-cache
+ghsa: c33f-42f2-gwcc
+url: https://github.com/sourcelevel/faraday-http-cache/security/advisories/GHSA-c33f-42f2-gwcc
+title: Shared cache serves responses to authenticated requests to other callers
+date: 2026-09-15
+description: |
+  faraday-http-cache acts as a shared cache by default (shared_cache: true).
+  The ByUrl strategy keys entries on method and URL and treats a cached
+  response without a Vary header as matching every request, and the
+  ByVary strategy relies on the origin listing Authorization in Vary.
+  A response to a request that carried an Authorization header is
+  therefore stored and served to later requests from different callers
+  whenever the origin omits Vary and does not mark the response private.
+
+  RFC 9111 section 3.5 requires a shared cache not to reuse such a
+  response unless it carries public, must-revalidate or s-maxage. The
+  middleware did not implement that rule.
+
+  NOTE: Versions 2.0.0 through 2.7.0 were confirmed by the reporter;
+  the 1.x line was not tested.
+
+  ## CREDIT
+
+  Reported by Matthew Mongeau (Ruby Central / Project Glasswing).
+  RFC 9111 section 3.5.
+cvss_v3: 6.5
+patched_versions:
+  - ">= 2.8.0"
+related:
+  url:
+    - https://rubygems.org/gems/faraday-http-cache/versions/2.8.0
+    - https://github.com/sourcelevel/faraday-http-cache/blob/master/CHANGELOG.md#280-2026-09-15
+    - https://github.com/sourcelevel/faraday-http-cache/compare/v2.7.0...v2.8.0
+    - https://github.com/sourcelevel/faraday-http-cache/security/advisories/GHSA-c33f-42f2-gwcc
+notes: |
+  - cvss_v3 from GHSA URL.
+  - No CVE in GHSA URL.

gems/faraday-http-cache/GHSA-p8jg-8p9f-pgmr.yml

@@ -0,0 +1,36 @@
+---
+gem: faraday-http-cache
+ghsa: p8jg-8p9f-pgmr
+url: https://github.com/sourcelevel/faraday-http-cache/security/advisories/GHSA-p8jg-8p9f-pgmr
+title: Cache entries deserialized with JSON.load can instantiate
+  arbitrary classes named by an origin server
+date: 2026-09-15
+description: |
+  faraday-http-cache stores cached responses with the JSON module by
+  default and reads them back with JSON.load, which honours the
+  json_class key and calls json_create on the named class. Response
+  headers are stored verbatim inside the cache entry, so an origin
+  server that returns a json_class response header causes that class
+  to be instantiated in the client process on the next cache hit. Any
+  application that uses the middleware to fetch URLs it does not
+  fully control is affected with the default configuration, through
+  both the ByUrl and ByVary strategies.
+
+  NOTE: Versions 2.0.0 through 2.7.0 were confirmed by the reporter;
+  the 1.x line was not tested but uses the same deserialization path.
+
+  ## CREDIT
+
+  Reported by Matthew Mongeau (Ruby Central / Project Glasswing).
+cvss_v3: 8.1
+patched_versions:
+  - ">= 2.8.0"
+related:
+  url:
+    - https://rubygems.org/gems/faraday-http-cache/versions/2.8.0
+    - https://github.com/sourcelevel/faraday-http-cache/blob/master/CHANGELOG.md#280-2026-09-15
+    - https://github.com/sourcelevel/faraday-http-cache/compare/v2.7.0...v2.8.0
+    - https://github.com/sourcelevel/faraday-http-cache/security/advisories/GHSA-p8jg-8p9f-pgmr
+notes: |
+  - cvss_v3 from GHSA URL.
+  - No CVE in GHSA URL.