Joomla! CMS EUVD-2026-61034

Exploitation requires that the target Joomla installation has CORS explicitly configured with an origin allowlist - the vulnerability manifests in the validation of that allowlist, so Joomla deployments with no CORS configuration or with CORS headers managed entirely at the reverse proxy layer are not affected through this code path. The CVSS 4.0 UI:N metric indicates that a victim visiting a malicious page is not strictly required; a direct crafted API request with a manipulated Origin header may be sufficient to trigger the bypass. Limiting factors include: the attacker must know the target Joomla API endpoint structure; the bypass does not grant server-side code execution, file system access, or direct database access; impact is constrained to the scope of the session or API token context at the time of the forged request; and the CRLF-injection mechanism (CWE-93) implies the attacker must understand the specific parser flaw to construct a working bypass. Joomla instances without CORS enabled are not exposed.

The CVSS 4.0 base score of 6.9 with vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:L reflects a medium-severity, network-accessible vulnerability requiring no privileges and no user interaction, but with impact constrained to low-level influence over subsequent-system resources. No EPSS score was provided in the source data, making probabilistic exploitation forecasting unavailable. There is no CISA KEV listing and no known public POC, so exploitation status is currently theoretical. The CWE-93 (CRLF Injection) root cause is a notable signal: it implies exploitation requires crafting a non-trivial malformed Origin header rather than simply pointing a browser at a malicious page, which modestly elevates attack complexity above what AC:L alone conveys. Defenders should weigh that the zero-privilege, no-interaction profile makes this scalable if exploit techniques become public, while the low-impact scope limits the blast radius per successful exploitation. There is no conflicting data between sources, but the absence of EPSS and KEV data means residual uncertainty about real-world exploitation likelihood.

An attacker sends a direct HTTP request to the Joomla API endpoint with a crafted Origin header containing CRLF sequences (e.g., Origin: attacker.example.com Origin: allowed.example.com), causing the server's validation logic to accept the unauthorized origin and return permissive Access-Control-Allow-Origin headers. In a browser-mediated follow-on, the attacker's malicious web page exploits those permissive headers to silently issue cross-origin API calls using the victim's authenticated Joomla session, reading sensitive CMS content or performing state-changing operations such as modifying articles or user data. No public exploit code has been identified at time of analysis, but the CRLF injection technique is well-documented in security literature and does not require specialized tooling.