Joomla! CMS EUVD-2026-61033

Exploitation requires an authenticated session with high-privilege Joomla credentials (confirmed by PR:H in the CVSS 4.0 vector) - unauthenticated actors cannot exploit this flaw. The Joomla REST API webservice layer must be reachable by the attacker over the network, which is not the default in all Joomla configurations and may require explicit enablement or exposure. The attack is specifically limited to the custom fields component of the webservice API - the attacker can create custom fields for components their ACL denies them, but cannot achieve arbitrary code execution, account takeover, or data exfiltration beyond low-level field metadata. The vulnerability is only meaningful in deployments where ACL-based component segregation is used as an access boundary between different user groups; installations where all elevated users hold equivalent full-admin rights have no exploitable ACL gap.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N, score 5.1) appropriately reflects medium-low real-world severity. The high-privilege requirement (PR:H) is the most significant limiting factor: exploitation is restricted to users already holding elevated Joomla credentials, not the general user population. The 'Authentication Bypass' tag in the source intelligence is somewhat misleading - this is more precisely an authorization bypass (ACL circumvention within an authenticated session), not a bypass of the authentication mechanism itself. No EPSS data was provided, and the absence of a CISA KEV listing means active exploitation is not confirmed. No POC code was identified. Real-world risk is most acute in multi-tenant Joomla deployments where component-level ACL segregation is an explicit security boundary - for example, where different editorial teams are restricted to specific content components. Environments where all elevated users already have full administrative rights have no meaningful ACL boundary to bypass and are at negligible effective risk from this flaw.

An authenticated Joomla user with a high-privilege role - such as a manager or administrator account that has been restricted from specific components via ACL - identifies a component they are denied access to in the web UI. The attacker crafts a direct HTTP POST request to the Joomla custom fields webservice endpoint (e.g., /api/index.php/v1/fields/fields), including the identifier of the restricted component in the payload. The server processes the request without performing the expected component-level ACL check, successfully creating a custom field in the target component. No public POC has been identified, so exploitation currently requires manual knowledge of the Joomla webservice API structure.