2026-08-28 · view entry permalink →
YOOtheme ZOO for Joomla: unauthenticated file-upload RCE (CVSS 10.0) plus a precondition-free SQL injection reachable with no submission form at all — three releases in three days, and the 3.x line has no fix
mySites.guru (Phil Taylor) found and reported three unauthenticated flaws in YOOtheme ZOO (com_zoo), a Joomla content-construction extension, affecting every version 1.0.0 through 4.1.63. CVE-2026-74803 (CVSS 10.0, CWE-434) is an arbitrary-file-upload-to-RCE: the front-end submission form's Image element validates an upload solely by trusting the client-supplied Content-Type header — "the Image element validates that attachment. It builds a validator configured with a MIME type group of image and a maximum size... The problem is which value that validator inspects. It reads the Content-Type header the client attached to the upload" (mySites.guru, 2026-08-25) — never inspecting file bytes or enforcing an extension allow-list. An anonymous visitor uploads a .php file declared image/jpeg; Joomla's File::makeSafe() preserves the .php extension, and the file lands executable inside images/zoo/uploads/, a directory the web server executes PHP from.
CVE-2026-74804 (CVSS 9.3, CWE-89) is a precondition-free unauthenticated SQL injection in ItemController::element() — two unescaped request values pasted into the query's string-comparison condition — reachable on any site running ZOO at all: "a site with no submission form at all is still fully exposed to this one" (mySites.guru, 2026-08-25). mySites.guru proved it bypasses access filters and extracts the database name and version via UNION-based extraction. CVE-2026-75114 (CVSS 5.1) is a lower-severity open redirect in the Twitter comment callback.
All three were fixed in ZOO 4.1.64 (2026-08-19), but two follow-up releases inside three days closed five further issues that 4.1.64 had missed or introduced, including CVE-2026-76612 (CVSS 8.6, unauthenticated stored XSS via comments/field elements) — current guidance is 4.1.66 or later. No fix exists for the ZOO 3.x line at all, since the affected range starts at 1.0.0. The same week, YOOtheme Pro for Joomla shipped its own fix for CVE-2026-76613 (SQL injection); the CVSS score was corrected on 23 August from 9.2 with a PR:N (no privileges required) vector to 8.6 with PR:H, after YOOtheme told the CNA the original vector was wrong — though mySites.guru flags one mismatch the correction did not resolve: the record's own description still reads "any contributor-level user", a role most sites treat as barely privileged, while PR:H denotes privileges giving significant control over the component; mySites.guru states it has not audited YOOtheme Pro itself and cannot settle which reading is right, and this entry carries that same open question rather than treating PR:H as settled — and the fix was backported to the Joomla-3-only 4.5.x line in 4.5.34 (24 Aug) with a regression fix in 4.5.35 (25 Aug) after that first backport introduced a new problem.
Triage: any non-image file under images/zoo/uploads/ — especially .php, .phtml or any server-executable extension — is a compromise indicator regardless of current patch level, since the flaw has existed since ZOO 1.0.0. For the SQL injection, unusual UNION-shaped query patterns or boolean-timing probes against ZOO's item-listing endpoints from unauthenticated sessions are the discriminator; ZOO's normal front-end traffic issues parameterised, predictable queries.
ZOO lets visitors submit content through a front-end submission form... The Image element validates that attachment. It builds a validator configured with a MIME type group of image and a maximum size... The problem is which value that validator inspects. It reads the Content-Type header the client attached to the upload.
A site with no submission form at all is still fully exposed to this one.