Cache entries deserialized with JSON.load can instantiate arbitrary classes named by an origin server
Published: September 15, 2026
SECURITY IDENTIFIERS
- GHSA: GHSA-p8jg-8p9f-pgmr
- Vendor Advisory: https://github.com/sourcelevel/faraday-http-cache/security/advisories/GHSA-p8jg-8p9f-pgmr
GEM
SEVERITY
CVSS v3.x: 8.1 (High)
PATCHED VERSIONS
>= 2.8.0
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).
RELATED
- 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
