Joomla! CMS EUVD-2026-31871

No special authentication or user interaction is required (CVSS AV:N/AC:L/PR:N/UI:N), so exploitation is reachable against any internet-exposed Joomla! 4.0.0-5.4.5 or 6.0.0-6.1.0 instance in default configuration. The specific prerequisite tied to the bug is that the targeted code path must call InputFilter::getInstance() with the security-sensitive parameter that the cache key omits, and a prior cached instance with a different value for that parameter must already exist in the request lifecycle - meaning realistic exploitation depends on triggering an ordered pair of requests (or internal calls) that produce the cache collision. Exploitation is limited to confidentiality impact only (C:H, I:N, A:N): the flaw cannot be used to modify data, gain code execution, or cause denial of service, and the leaked content is bounded by what the mis-cached filter fails to sanitize on output.

Signals are mixed and point toward a moderate, not urgent, priority. CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/C:H) reflects that the bug is reachable over the network without authentication and yields high confidentiality impact, but integrity and availability are untouched and scope is unchanged. EPSS at 0.02% (5th percentile) and absence of CISA KEV listing indicate no observed mass exploitation. There is no public exploit identified at time of analysis. The practical risk is that exploitation depends on triggering a specific cache-collision condition between concurrent requests with differing filter parameters, which is non-trivial to weaponize despite the favorable CVSS vector - a likely reason EPSS is so low. Defenders should treat this as a standard scheduled patch item unless their deployment exposes administrative or multi-tenant flows that handle sensitive parameters through InputFilter.

An unauthenticated attacker sends a sequence of HTTP requests to a Joomla! endpoint that internally invokes InputFilter::getInstance() with a security-sensitive parameter, then issues a follow-up request that should receive a differently configured filter; because the cache key omits the security parameter, the second request reuses the first filter and the response leaks data that should have been stripped or masked. No public exploit code is identified at time of analysis, so weaponization would require an attacker to reverse the patch or advisory to identify which call sites and parameters produce a useful confidentiality leak.