Discourse CVE-2025-61598

Exploitation requires an intermediary that caches HTTP responses (a shared forward/reverse proxy or CDN) sitting in front of the Discourse instance, AND that proxy must cache responses by default when no Cache-Control directive is present. The specific trigger is any error response path handled by the DiscoursePublicExceptions middleware - e.g. ActionController::RoutingError (404), Discourse::InvalidAccess (403), or an invalid API key - because those responses skipped the dont_cache_page after_action and shipped without no-cache, no-store. Limiting factors: the AT:P metric reflects that the attacker does not control whether/when the proxy caches and re-serves the response, impact is confidentiality-only and rated Low, and deployments that do not use a caching intermediary or that already enforce cache directives at the proxy are not exposed. Authentication is not required to send the triggering request.

This is a genuinely low-priority issue despite its CWE-524 (Use of Cache Containing Sensitive Information) classification. All exploitation signals point the same direction: EPSS is 0.30% (21st percentile), there is no CISA KEV listing, and no public exploit code was identified. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) yields only 6.3 (Medium), and crucially the impact is limited to VC:L with VI:N and VA:N - no integrity or availability effect and only low confidentiality. The AT:P flag (attack requirement present) signals that exploitation depends on conditions outside the attacker's control, namely the presence and behavior of an intermediary cache. The signals are consistent rather than conflicting: a medium-scored, confidentiality-only header-hardening fix with low exploitation probability and no evidence of real-world abuse. One note of caution - the GitHub advisory (GHSA-jp9x-wwv6-cv3j) describes this as 'may cause unintended caching' and 'potentially leading to cache poisoning,' which is conditional language; the real-world impact depends entirely on whether a shared caching proxy fronts the deployment and what sensitive data those error responses contain.

A Discourse instance sits behind a shared caching proxy or CDN. An attacker (or an ordinary request) triggers an error response - a 404 routing error or a 403 invalid-access/API-key response - which, before the fix, lacked the no-cache, no-store Cache-Control header. The proxy caches that response and subsequently serves it to other users, enabling cache poisoning or disclosure of a response that was meant to be per-request. No public exploit identified at time of analysis.