What is the CVSS score of CVE-2026-48901?

CVE-2026-48901 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.0%.

Which versions of Joomla! CMS are affected by CVE-2026-48901?

Joomla! CMS contains a filter caching vulnerability that allows unauthenticated remote attackers to retrieve sensitive data through a security control bypass. Organizations using Joomla!

How to fix or mitigate CVE-2026-48901?

Within 24 hours: Conduct inventory of all Joomla! CMS instances in production and identify installed versions. Within 7 days: Implement Web Application Firewall rules to detect requests exploiting InputFilter caching mismatch behavior; enable detailed logging of filter instantiation and parameter tracking. Within 30 days: Subscribe to Joomla! security mailing list for patch notification; develop staged upgrade plan for when vendor patch becomes available; assess feasibility of restricting network access to non-critical Joomla! instances until patched.

Joomla! CMS CVE-2026-48901

EUVD-2026-31871 HIGH

Use of Cache Containing Sensitive Information (CWE-524)

2026-05-26 Joomla

GHSA-phf8-w34q-995j

Information Disclosure Joomla Cms

7.5

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Analysis Generated

May 28, 2026 - 16:30 vuln.today

CVSS changed

May 28, 2026 - 14:22 NVD

7.5 (HIGH)

CVE Published

May 26, 2026 - 16:42 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

The InputFilter::getInstance() method omitted a security sensitive parameter from the instance cache key.

AnalysisAI

Information disclosure in Joomla! CMS arises because InputFilter::getInstance() builds its instance cache key without including a security-sensitive parameter, allowing a previously cached filter instance to be returned even when a different security posture was requested. Remote unauthenticated attackers can leverage the resulting filter mismatch to retrieve sensitive data (CVSS 7.5, C:H only). No public exploit identified at time of analysis and EPSS is 0.02% (5th percentile), indicating low predicted exploitation in the near term.

Technical ContextAI

Joomla!'s InputFilter component is the central request-sanitization layer used across the CMS and third-party extensions to scrub user-supplied data. The class implements a singleton/factory pattern via getInstance(), which caches filter objects keyed by their construction parameters so subsequent callers reuse the same configured instance. CWE-524 (Information Exposure Through Caching) describes exactly this defect class: a security-relevant parameter was omitted from the cache key, so two logically distinct filter requests collide on the same cached object and the second caller receives a filter configured for the first caller's (weaker or different) security context. The CPE cpe:2.3:a:joomla!_project:joomla!_cms:*:*:* confirms the core CMS product, not an extension, is affected.

RemediationAI

Upgrade Joomla! CMS to a version beyond the affected ranges - i.e., past 5.4.5 in the 5.x branch and past 6.1.0 in the 6.x branch - per the Joomla! security advisory at https://developer.joomla.org/security-centre/1049-20260517-core-incorrect-cache-key-construction-for-inputfilter-objects.html; consult that advisory for the exact fixed release numbers as the input data does not enumerate a single canonical fix version. Where immediate upgrade is not possible, restrict network exposure of the CMS to trusted networks or place it behind an authenticating reverse proxy or WAF to limit which actors can drive the vulnerable code path, accepting that this only reduces the attacker pool and does not eliminate the cache-key flaw. Audit and minimize third-party extensions that call InputFilter::getInstance() with non-default security parameters, since those callers are most likely to surface the collision; the trade-off is functional regressions in extensions that depend on customized filter configurations.