Joomla CMS CVE-2026-90913

Requires an authenticated Joomla account with sufficient privileges to reach the Joomla Web Services (API) access-level endpoints (viewing access levels); the Joomla webservices API must be enabled/reachable on the target. Exploitation is limited by this authentication requirement (PR:H) - anonymous internet users cannot trigger it directly - and applies to Joomla CMS 4.0.0-5.4.8 and 6.0.0-6.1.3. It affects mutation (write/change) operations on access-level endpoints rather than read-only access, so the practical risk is highest on multi-user sites that grant API access to lower-trust accounts.

This is a medium-to-moderate priority authorization flaw, not a critical emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:L/VA:N = 7.0) shows a network-reachable, low-complexity issue but crucially requires HIGH privileges (PR:H) - the attacker must already hold an authenticated Joomla account with meaningful backend/API access before touching the access-level webservice endpoints. There is a notable internal tension: the description says an improper access check lets 'unauthorized users' perform mutation actions, which reads like a privilege-escalation from a lower tier, yet the vendor rates it PR:H - this most likely reflects that any authenticated API caller is 'privileged enough' to reach the endpoint but not authorized to mutate access levels; the exact minimum privilege boundary should be verified against the Joomla advisory. No EPSS score, no CISA KEV listing, and no public exploit are present in the supplied data, so this is 'no public exploit identified at time of analysis' and there is no evidence of active exploitation. Impact is skewed toward confidentiality/integrity of the access-control model (VC:H, VI:L, VA:N) rather than full system compromise. Net: a real but conditional risk that matters most for multi-user Joomla sites with untrusted authenticated accounts, not a drop-everything internet-wide threat.

An attacker who already holds an authenticated Joomla account (e.g., a low-trust backend user or an API token holder on a multi-user site) sends crafted requests to the access-level (viewing access level) webservice endpoints. Because the ACL check is improperly enforced, the server accepts mutation actions the account should not be permitted to make, letting the attacker create, modify, or delete access levels and thereby weaken the site's authorization model. No public proof-of-concept is referenced in the available data.