Joomla! CMS CVE-2026-48902

Exploitation requires four concrete conditions present together: (1) the target Joomla! site is running a vulnerable version in the 3.9.0-5.4.5 or 6.0.0-6.1.0 ranges, (2) the site administrator has NOT set the 'Force SSL' global configuration flag to enforce HTTPS, (3) a legitimate user actively initiates a password or username reset and then clicks the emailed link, and (4) the attacker is positioned as an on-path observer of the network segment carrying the victim's initial http:// request to the site. Exploitation is meaningfully limited by user interaction (UI required despite the published CVSS UI:N), by reliance on the victim's network being attacker-accessible, and by HSTS preloading on browsers that already trust the site's HTTPS endpoint.

There is a sharp conflict between the headline CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) and every other signal in the dataset, and defenders should weigh the other signals heavily. EPSS rates exploitation at 0.02% (5th percentile), the vulnerability is tagged only as Information Disclosure, it is not on the CISA KEV list, and no public exploit code has surfaced. The CVSS vector also appears inflated for the described behavior: realistic exploitation requires an attacker positioned on the network path between the victim and the Joomla! site (a passive MITM or hostile network), plus a victim who initiates a reset and clicks the link, which is closer to AV:N/AC:H/UI:R with C:H/I:L/A:N than to the published 9.8. Net assessment: this is a meaningful credential-recovery hygiene issue for sites that have not enabled Force SSL, but it is not a drop-everything priority and the 9.8 score should not be used to justify emergency change windows.

A user on a hostile network (open Wi-Fi, compromised ISP path, or attacker-controlled VPN) requests a password reset on a Joomla! site that serves HTTPS but has not enabled Force SSL; the site emails them a reset link prefixed with http://. When the victim clicks the link, the initial request traverses the network in clear text and the attacker captures the one-time reset token before any TLS upgrade can occur, then races to redeem it and take over the account. No public proof-of-concept is required because the attack is a standard passive interception of an unencrypted HTTP request.