SURIQ
Another Joomla extension, another maximum-severity flaw that needs no password. On August 12 the Joomla project published CVE-2026-67282, an unauthenticated remote code execution bug in Fabrik, the well-known application and form builder for the Joomla content management system. It scores a full 10.0. The fix is Fabrik 4.6.8, and every release from 1.0.0 through 4.6.7 is affected.
If that reads familiar, it should. This is the latest in a summer-long run of Joomla add-ons drawing a perfect score for the same underlying reason: a feature that anonymous visitors can reach was trusted to handle anonymous input. We have followed the pattern since June, when the JCE editor flaw put the most-installed Joomla editor on the exploited list, through Balbooa Forms and iCagenda, which CISA added to its roster of Known Exploited Vulnerabilities on July 10 after both were attacked in the wild. Fabrik is the newest name on that pattern, and the earlier entries taught defenders something the advisory will not: the patch is the starting gun, not the finish line.
What the Fabrik flaw actually is
The bug lives in Fabrik's front-end list-filter feature. According to the CVE record, assigned by the Joomla project and credited to researcher Murad Gasimov, someone who never logs in can drive that feature into running code of their choosing on the server. In classification terms it is a code-injection weakness (CWE-94), a different mechanism from the file-upload bugs behind the earlier extension flaws, but the result is the same: arbitrary code running as the web application, with no account and no user interaction.
Two things about scope matter for triage. The affected range is wide. Any Fabrik older than 4.6.8 is vulnerable, so this is not a narrow "only if you turned on X" bug. And at the time of writing, no public proof-of-concept and no in-the-wild exploitation of this specific flaw had surfaced. That is the good news, and the reason to move now, before either changes.
| Extension | CVE | Flaw type | Exploited in the wild | Fixed in |
|---|---|---|---|---|
| Fabrik | CVE-2026-67282 | Unauthenticated code injection (front-end list filter) | Not reported yet | 4.6.8 |
| JCE editor | CVE-2026-48907 | Unauthenticated file upload | Yes (CISA KEV) | 2.9.99.6 |
| Balbooa Forms | CVE-2026-56291 | Unauthenticated file upload | Yes (CISA KEV, Jul 10) | 2.4.1 |
| iCagenda | CVE-2026-48939 | Unauthenticated file upload | Yes (CISA KEV, Jul 10) | 3.9.15 / 4.0.8 |
Set beside the extensions CISA has already flagged, the through-line is stark. Each of these carried a perfect 10.0, and each was reachable without a login. Fabrik differs only in the mechanism, a filter that mishandles input rather than an upload that skips a check.
Why the patch is the starting gun
Here is the part the earlier flaws make concrete. When the fix for a front-end Joomla bug goes public, the fix itself is a map. An attacker compares the patched build against the last vulnerable one, sees which code path changed, and rebuilds an exploit from the difference. For the extensions CISA flagged in July, the gap between a public fix and mass scanning was measured in days, sometimes hours. Balbooa Forms was reported exploited before its 2.4.1 fix even shipped, according to SecurityWeek.
Fabrik installs skew toward sites that have run Joomla for years, the kind that update on a human schedule rather than automatically. That is exactly the population the last few extension waves hit hardest. The exposure window is not measured from the day the CVE ages, it is the stretch between now and whenever an operator notices. Treat the 4.6.8 release as the moment the clock started, not the moment the risk ended.
Patch to 4.6.8, then hunt like you were already hit
Update Fabrik to 4.6.8 first. If you cannot patch right away, the interim move is to restrict or disable public access to the affected list views, since the flaw is reachable through the front end with no login.
Then assume the window may already have been used, and look. Unauthenticated code execution against a web application almost always ends in a webshell, a small script an attacker drops into the webroot to keep access after the hole closes. That maps to two techniques worth watching: exploitation of a public-facing application (ATT&CK T1190) for the initial hit, and a web shell for persistence (ATT&CK T1505.003). The concrete signals:
- A PHP file appearing in the Joomla webroot, especially under the
components/com_fabriktree or theimagesandtmpdirectories, that was never shipped with the extension. - Requests to the Fabrik component from anonymous sessions carrying unusually long or encoded filter parameters, followed by a request to a file that did not exist before.
- Outbound connections from the web server to hosts it never normally talks to, a common sign a shell is calling home.
None of that needs a specific payload signature. It needs someone watching the webroot and the request log for change. A managed file integrity monitoring setup flags a component directory that just gained an executable it never had, and log management over the front-end request stream is where the anomalous filter-then-fetch sequence shows up. Across a fleet of Joomla sites, vulnerability detection is what tells you which ones are still sitting below 4.6.8 before someone else finds out for you.
The advisory gives you the fix. What it cannot give you is whether the window was already used on your servers. That is the same lesson the broader CMS webshell campaign drove home earlier this year: patching closes the door, but only hunting tells you whether anyone walked through it first.