Joomla extension file-upload RCE wave

CVE-2026-61425, Balbooa Gridbox for Joomla: a client-supplied cookie is accepted as proof of identity, giving anonymous Super User access

The Joomla third-party-extension disclosure wave covered here since early July has been a file-upload story: unauthenticated uploads reaching code execution, several of which were weaponised and CISA-KEV-listed within days of disclosure. The batch mySites.guru published between 2026-07-20 and 2026-07-23 adds a different and more direct failure. In Balbooa's Gridbox page builder, "A critical unauthenticated authentication bypass in Gridbox let anyone become a Super User on a Joomla site by setting a single browser cookie" (mySites.guru, 2026-07-20). The extension treats a client-supplied cookie value as proof of identity rather than as an assertion to be validated against server-side session state, so an anonymous requester who places an administrator's username in that cookie is served the site as that administrator, no password, no login form, no pre-existing session. Because a Joomla Super User can edit templates, and templates are PHP, the practical outcome is code execution on the web server from a single unauthenticated request. Gridbox 2.20.1 fixes it; the vulnerable code had shipped since the previous release in October 2025, roughly nine months of exposure.

The rest of the week's batch is the same research campaign continuing on its original axis, with two flaws that matter beyond the site itself. EasyStore for Joomla carried an unauthenticated SQL injection able to read the whole site database (CVE-2026-65761, scored 9.3 by the Joomla CNA) plus an order-forgery flaw (CVE-2026-65759, 8.7) where "An anonymous request to the order-repayment endpoint could mark any order paid with no login, no token, and no contact with any payment gateway" (mySites.guru, 2026-07-23), fixed in 2.0.2. Events Booking exposed invoices containing personal and financial data to anonymous requests that simply walked sequential identifiers, fixed in 5.8.2 (mySites.guru, 2026-07-21). Membership Pro's unauthenticated upload was initially disputed by the vendor, the researcher records that "The vendor called it 'not a critical security issue.' The Joomla CNA disagreed" and it was assigned CVE-2026-62415 at 9.1 critical, fixed in Membership Pro 4.6.2 (mySites.guru, 2026-07-21).

There is no public exploitation signal for any of these: the researcher withholds the exact cookie name, endpoints and proof-of-concept code under a fix-first policy. The reason to act ahead of the routine extension-update cycle is the wave's own track record rather than current telemetry, earlier members of this same disclosure series moved from publication to confirmed in-the-wild exploitation within days once the mechanism became public, and a cookie-forgery bypass is trivially rediscovered by anyone who diffs the 2.20.1 release against its predecessor.

Triage: a cookie-forgery bypass leaves little at the network layer to distinguish it; the request is well-formed and returns HTTP 200. The observable is the mismatch between authentication and privilege: administrative actions in Joomla's action log attributed to a Super User account with no preceding successful login event for that account, and no session-establishment record. Legitimate administrator activity is preceded by an authentication event from a consistent source; forged-cookie access produces privileged actions that appear without one. On sites running affected Gridbox versions, template-file modification timestamps postdating the October 2025 release, with no corresponding administrator login, are the artefacts worth reviewing.

Sourcerer for Joomla: unauthenticated RCE exploited in the wild since before a working fix existed; the vendor's first two patches did not close it, and the CVE was re-scoped in place to widen the affected range

CVE-2026-74253 (Regular Labs' Sourcerer, the Joomla extension that renders PHP, JS and CSS embedded in content) is CWE-94 (Improper Control of Generation of Code), CVSS 4.0 10.0 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H, every metric at its worst), credited to finder Lukasz Rybak. Before Sourcerer 14.0.0, only article-text content had its origin verified before Sourcerer would execute embedded code; code reaching the page through a module, component, page head, or any other rendering position ran unconditionally. 14.0.0 (17 Aug) added trust-marking for article content and unmodified custom-module output, but did not close every route by which untrusted content could reach the render (URL and form parameters, raw request bodies, uploads, cookies and headers all remained live) and the CVE record originally scoped the fix as "<14.0.0", affected 1.0.0–13.1.1.

The flaw has been under active exploitation since roughly 2026-08-19 per the Joomla Security Strike Team: "Exploited Yes, in the wild since roughly 19 August 2026 per the Joomla Security Strike Team, confirmed to us 24 August 2026" (mySites.guru, citing the Joomla Security Strike Team, 2026-08-26), two days after the first "fix" shipped and seven days before a working one existed. Sourcerer 15.0.0, also never tagged a security release, also failed to close it. Only 16.0.0 (26 Aug) closes the untrusted-input-delivery routes and additionally blocks common filesystem-write PHP functions by default. On 2026-08-26 the Joomla CNA re-scoped CVE-2026-74253 in place, widening the affected range from 1.0.0–13.1.1 to 1.0.0–15.0.0: "the Joomla CNA widened CVE-2026-74253 from 'Sourcerer < 14.0.0' to 'Sourcerer < 16.0.0', moving the affected range from 1.0.0-13.1.1 to 1.0.0-15.0.0, after the vendor's first two attempts at a fix turned out not to close the flaw" (mySites.guru, 2026-08-26), meaning every site that updated to 14.0.0, 14.0.1 or 15.0.0 in good faith, told by both its extension manager and the CVE record itself that it was patched, was exploitable the entire time.

HTML-escaping input is explicitly not a mitigation here, and the reason is design rather than oversight: "code written in a WYSIWYG editor arrives with its angle brackets converted to HTML entities. So that code still runs, Sourcerer decodes entities inside its own tags before handling the contents" (mySites.guru, 2026-08-26), the decoding cannot distinguish administrator-typed code from attacker-supplied text. PHP execution is enabled by default; the default forbidden-function list blocks shell-exec functions but not file-write functions. A separate, earlier CVE, CVE-2026-64796 (fixed in 13.0.0, affected 1.0.0–12.2.8), closed only the article-content path and does not protect against this one.

Triage: any site that "patched" Sourcerer to 14.x or 15.0.0 between 17 and 26 August must be re-verified against 16.0.0 and treated as having been exposed the entire window regardless of what its extension manager reported. Look for PHP execution originating from content-rendering code paths outside article bodies (module output, page-head injection, or request-parameter-derived content reaching Sourcerer's render function) since that is exactly the delivery route the 14.0.0/15.0.0 fixes failed to close. A web-server process spawning a shell or writing new PHP files to disk from within Joomla's content-rendering pipeline has no legitimate explanation.

iCagenda Calendar module for Joomla: unauthenticated SQL injection via com_ajax needs no session, token or account (CVE-2026-67365, CVSS 9.2), and the vulnerable module's own version number does not track the package version

The Joomla project's CNA published CVE-2026-67365 on 2026-08-14: an unauthenticated SQL injection (CWE-89) in mod_icagenda_calendar, the Calendar module bundled with the iCagenda events extension, reachable via com_ajax (Joomla's generic anonymous front-end AJAX entry point) with no session, token or account required. Rated CVSS 4.0 9.2 Critical (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:L/SC:H/SI:H/SA:H): "Joomla Extension - icagenda.com - Unauthenticated SQL injection in iCagenda < 4.0.0-4.0.11 - Unauthenticated SQL injection in mod_icagenda_calendar (iCagenda), reachable via com_ajax with no session, token or account" (Joomla CNA record, quoted by mySites.guru, 2026-08-17). Affected 4.0.0–4.0.11; fixed in 4.0.12. The flaw was reported by Joep van Antwerpen of Onvio, not mySites.guru's own find.

The operationally important detail is a version-tracking trap: the vulnerable Calendar module's own version number stayed pinned at 4.0.7 through package releases 4.0.8, 4.0.9, 4.0.10 and 4.0.11, and only advanced to 4.0.12 with the fix, "The Calendar module stayed at 4.0.7 through the 4.0.8, 4.0.9, 4.0.10 and 4.0.11 releases and only moved with 4.0.12, so the module version and the package version disagree and a site can look patched when it is not." (mySites.guru, 2026-08-17). A naive version check against the package number (in either direction) gives a wrong answer for this specific component. A second, independent detection trap sits upstream of that: at the time of mySites.guru's writing, iCagenda's own update feed had not yet been updated to list 4.0.12, even though the fixed release was already shipping and installing on real sites, "the feed still lists 4.0.11 from this date and nothing above it, even though 4.0.12 is shipping and installing on real sites. A site running an update check is told it is current" (mySites.guru, 2026-08-17), meaning an automated update-status check could report a vulnerable site as current independent of the module-version trap above. No vendor advisory or changelog entry exists for this fix beyond the CVE record itself at time of writing. This is the second security issue in iCagenda in two months and unrelated to the first: CVE-2026-48939, an unauthenticated file-upload flaw already CISA-KEV-listed, was fixed in 4.0.8/3.9.15 and does not cover this SQL injection.

Triage: hunt and inventory tooling should key on the Calendar module's own reported version, not the iCagenda package version, when assessing exposure to this specific CVE. On the wire, unauthenticated com_ajax requests targeting the iCagenda calendar component carrying SQL-metacharacter payloads in parameters are the delivery shape; iCagenda's legitimate calendar AJAX traffic carries only structured date/view parameters, so a request with SQL syntax in those fields has no benign explanation.