Joomla CMS CVE-2026-92226

Exploitation requires an authenticated account with access to Joomla's web-services (API) application and enough privilege to reach the affected edit tasks (CVSS PR:H). The specific prerequisite is invoking the vulnerable webservice edit endpoints where the ACL check is improperly enforced, allowing edits to items the account is not authorized to modify. Limiting factors: the web-services/API application must be enabled and reachable, the attacker must already be authenticated (no unauthenticated path per PR:H), and the affected component is Joomla Core versions 4.0.0-5.4.8 or 6.0.0-6.1.3. No user interaction is required (UI:N).

This is a genuine but bounded-priority issue. The CVSS 4.0 vector (7.0, AV:N/AC:L/AT:N/PR:H/UI:N) confirms a network-reachable, low-complexity flaw but requires high privileges (PR:H), meaning the attacker must already hold an authenticated backend/API account before the improper ACL check can be abused. Impact is integrity-dominant (VI:H, edit actions on otherwise-uneditable items) with only limited confidentiality/availability (VC:L/VA:L) and no scope change (SC:N/SI:N/SA:N). No EPSS score, no CISA KEV listing, and no public exploit are present in the input, so exploitation status is 'no public exploit identified at time of analysis' - this is a vendor self-reported advisory, not evidence of active exploitation. The PR:H requirement is the dominant risk limiter: this is not a mass-exploitable unauthenticated bug, so despite the 7.0 score its real-world urgency is moderate and gated behind privileged account access. The vendor's VI:H rating is plausible for an edit-authorization bypass; I would rate slightly lower overall (~5.5 in CVSS 3.1 terms) because the confidentiality/availability impacts are marginal.

An attacker holding a low-to-mid privileged authenticated Joomla account (or API token) with backend/webservice access sends crafted edit requests to the Joomla web-services (API) endpoints for content items they should not be able to modify. Because the ACL check for these edit tasks is improperly enforced, the request succeeds and the attacker alters items they lack authorization for. No public exploit code is identified at time of analysis; the flaw is documented only in Joomla's own security advisory 20260913.