The Fabrik Fiasco: Announced, Restricted, Relabelled

Fabrik is an application builder for Joomla. You use it to construct forms, database-backed lists and small applications inside a Joomla site, and it has been on the Joomla Extensions Directory since 2014 with the project itself dating back to 2006. On 9 August 2026 its developers released Fabrik 4.6.7 and labelled it a security release. The following morning the Joomla CNA published CVE-2026-66915, an unauthenticated remote code execution flaw in the extension’s calc element, scored CVSS 4.0 10.0 Critical.

Later that same day, Fabrik released 4.6.8 with a second security fix, this one in the extension’s list filters. Then the story moved twice more. On 12 August the Joomla CNA revised CVE-2026-66915 to say that 4.6.7 had not actually closed it, widening the affected range to include 4.6.8. The same day, the list filter flaw got a CVE of its own. On 13 August Fabrik announced 4.7.0, a hardening release aimed at the whole class of problem.

Announced is the word to hold on to, because 4.7.0 has never had an ordinary release. Fabrik published it on 13 August with its maturity given as Stable, put it on the changelog history page and posted release notes to its forum, while the package itself stayed restricted to what the vendor calls a small group of users. It was left out of the Joomla update feed, so no site’s updater could see it. On 16 August it went into the feed, tagged as a release candidate that Joomla hides at default settings, and the release page was rewritten to read Release Candidate on the same build and the same release date. Fabrik 4.6.7 has been withdrawn from the download page in the meantime.

If you run Fabrik on any Joomla site, 4.7.0 was the version to be on when we first published this, because nothing else then sat above both published CVE ceilings. That includes the sites you updated to 4.6.8 last week on the advice everybody was giving, this post included. The vendor has since shipped 4.7.1 and then 4.7.2, so the current release to be on has moved on. See the update note immediately below; the rest of this post is the 4.7.0 story as it stood.

TL;DR

TL;DR: Fabrik’s calc element computes a field value by evaluating a PHP expression that the site builder writes. When the element’s AJAX option is on, that recalculation happens live through a front-end endpoint in com_fabrik, and that endpoint could be reached by an anonymous visitor with no login and no user interaction. Because evaluating PHP is the element’s intended job, reaching it without authorisation means running code on the server. That is CVE-2026-66915, CWE-94, CVSS 4.0 10.0 Critical (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H), reported by Moe Khalilov of LeetProtect Research. It was published on 10 August 2026 saying versions 1.0.0 to 4.6.6 were affected and 4.6.7 fixed it, then revised on 12 August to 1.0.0 to 4.6.8, fixed in 4.6.9. The first fix did not hold. A second flaw, in the front end list filter model, is CVE-2026-67282, also CWE-94 and also CVSS 4.0 10.0 Critical, reported by Murad Gasimov, affecting 1.0.0 to 4.6.7 and fixed in 4.6.8. There is no public Fabrik 4.6.9, so 4.7.0 (13 August 2026, “a major hardening release against PHP eval attack vectors”) is the release to be on. It breaks userAjax and needs FullCalendar and Paypal updated with it, and Joomla’s updater will not show it at default settings, so you install it by hand. Fabrik announced it on 13 August as Stable while the package was restricted to a small test group, added it to the update feed on 16 August tagged as a release candidate that Joomla hides at default settings, and relabelled the release itself Release Candidate the same day, on the same build and the same release date. It installs on Joomla 4.2 to 5.x only and needs a valid Fabrik subscription. Joomla 3 sites still have no patched release but now have a manual one-line source patch from the vendor for the calc flaw. We obtained the 4.7.0 package and read the source, which nobody outside the vendor’s test group has been able to do, and both flaws are fixed: eval() is down to two files in 869, and visitor data is now bound as PHP variables instead of spliced into the code. mySites.guru lists every connected Joomla site running Fabrik with both the Fabrik and Joomla version, so you can sort them into the ones that update and the ones that do not.

What Fabrik 4.7.2 fixes, and who reported it

Fabrik 4.7.0 closed the two originally published remote code execution flaws. What happened over the following week is the part worth recording. Across 4.7.1 and 4.7.2, Fabrik closed a long series of further unauthenticated vulnerabilities, and its own changelog credits most of them to mySites.guru by name.

The Joomla CNA has now published a CVE record for every one of these, and fifteen of them credit mySites.guru as the finder, four of those at the maximum CVSS 10.0. Rather than repeat the full table here, we have put it, with every CVE linked and scored, in a dedicated post: Fabrik 4.7.2: A Long List of Security Fixes.

The short version is that these are unauthenticated flaws across the calc and image elements, the list filters, the comment and order plugins and more: remote code execution, SQL injection, arbitrary file upload, directory listing, comment manipulation, a path traversal and a heredoc breakout, most with no login, no token and no user interaction. Any Fabrik install below 4.7.2 should be treated as exposed, and 4.7.2 is the release that closes the set. mySites.guru flags every connected Fabrik site through 4.7.2 while we independently verify the latest build.

What Is Wrong in Fabrik’s Calc Element?

The calc element is a Fabrik field whose value is worked out rather than typed. A site builder writes a small PHP expression into the element’s settings, for example to total two other fields or apply a tax rate, and Fabrik evaluates that expression to produce the value. Evaluating site-builder PHP is the documented, intended behaviour of the element, and it is why Fabrik can do the things people use it for.

The element has an option to recalculate over AJAX, so the value updates live as a visitor fills in a form instead of only when the page reloads. That option adds a second route to the same evaluation: a front-end endpoint in the com_fabrik component that takes the current form data, substitutes it into the stored expression, and evaluates the result. In the Fabrik source that is public, which is the older Joomla 3 line, the calculation reaches a plain PHP eval() at the end of both routes. Fabrik 4.x is distributed only to subscribers and its source is not published anywhere we could find, so the description here is drawn from the public Joomla 3 code plus the CVE record’s own classification of CWE-94, rather than from reading the patched release.

The flaw is that the AJAX route was reachable by anyone. No login, no privileges, no user interaction, which is exactly what the CVSS vector records with PR:N and UI:N. Joomla’s standard input filtering runs on the submitted data, but that filter exists to strip HTML and script tags for cross-site scripting purposes and does not neutralise PHP syntax. Because the substitution happens before the evaluation, submitted data that steps outside its expected position changes what actually gets executed.

This is the same shape of problem we wrote about in AJAX endpoints being a CMS security blind spot: a helper route added for front-end convenience, sitting beside a well-guarded main path, that never inherited the main path’s checks.

Which Fabrik Versions Are Affected?

When the CVE first published it listed 1.0.0 through 4.6.6 as affected and 4.6.7 as fixed. On 12 August the Joomla CNA revised the record to 1.0.0 through 4.6.8, with the fixed version restated as 4.6.9. Either way it covers every Fabrik release ever made, across both the Fabrik 3.x line built for Joomla 3 and the Fabrik 4.x line built for Joomla 4 and 5. What changed is the other end: the fix that shipped on 9 August did not close it, and neither did the release that followed.

We were not the only ones working from the original range. The record’s own reference list now includes this post, which is a useful reminder that a fixed version in a CVE is a claim with a date on it, and dates move.

Fabrik’s own changelog and forum post are unambiguous about what 4.6.7 is.

Credit where it is due. This is a clearly labelled, clearly dated security release with an explicit instruction to update, published in two places on the day it shipped. We have covered plenty of vendors who buried a serious fix under “improved input validation” in a changelog, and Fabrik did not do that here.

Then Fabrik Released 4.6.8

On 10 August 2026, the day after 4.6.7 and the same day the CVE published, Fabrik released 4.6.8. Its changelog entry reads in full:

That was the whole of it at the time. No CVE, no advisory, no severity, no indication of whether an attacker needed a login. The forum announcement, when it came, called it “a very small change specific to list prefilters using eval”.

On 12 August 2026 it got a number, and the number is not small. CVE-2026-67282 is an unauthenticated remote code execution flaw in Fabrik’s front end list filter model, scored CVSS 4.0 10.0 Critical on the same vector as the calc element flaw, classed as CWE-94 code injection, and reported by Murad Gasimov. It affects 1.0.0 through 4.6.7 and is fixed in 4.6.8.

Two unauthenticated remote code execution flaws, both scoring the maximum, in different parts of the same extension, disclosed two days apart. The 4.6.4 changelog from earlier this year has the line “Some more code hardening. Add error messages in case of FILTERTEXT reset (in case eval was used legally)”, so filters and eval were already an area the developers were tightening.

Then the Calc Element Fix Turned Out Not to Have Worked

On 12 August the Joomla CNA revised CVE-2026-66915. The affected range went from 1.0.0 to 4.6.6, up to 1.0.0 to 4.6.8. The fixed version went from 4.6.7 to 4.6.9.

Read straight, that says the fix shipped on 9 August did not close the flaw, and the release that followed it did not either. Everyone who updated to 4.6.7, and everyone who then updated again to 4.6.8 because of the list filter issue, was still exposed to the calc element flaw the whole time.

Acting on that is harder than it sounds, because there is no public Fabrik 4.6.9. It has no entry in the changelog history. It is not on the vendor’s download listing, which showed 4.6.3, 4.6.7, 4.6.8 and 4.7.0 on 13 August and shows 4.6.3, 4.6.8 and 4.7.0 today, 4.6.7 having been withdrawn. Its release information page returns a 404. The version named as the fix in the CVE record is not a version anybody can install.

What Fabrik shipped instead, on 13 August 2026, is 4.7.0:

That reads like a response to the whole class of problem, not to one more report. Both published flaws are CWE-94 code injection reached through eval, and the vendor’s own words on the Fabrik 3 thread confirm the intent: “A major security hardening effort is currently underway for F4 and F5.”

The version to be on is Fabrik 4.7.0: it is the only publicly downloadable release that sits above both CVE ceilings, and it is the release the vendor points at.

Joomla’s Updater Still Will Not Offer You 4.7.0

Fabrik 4.7.0 exists and the vendor has announced it. Getting it onto a site is a separate problem, and that problem has changed shape once already.

When we first wrote this up on 13 August, 4.7.0 was simply absent from the update feed Joomla reads for the Fabrik Base package. That feed carried 4.6.7, 4.6.8 and 4.6.3 and nothing above them, so a site running an update check was told 4.6.8 was the newest release available and then reported itself current.

On 16 August the feed changed. 4.7.0 is in it now, and 4.6.7 has been taken out. A site checking for updates today still will not be offered 4.7.0, for two independent reasons, and only one of them has a documented fix.

The Documented Reason: a Stability Tag

Fabrik’s feed entry for 4.7.0 has <tag>rc</tag>. Joomla’s installer has a setting called Minimum Extension Stability, its default value is Stable, and ExtensionAdapter discards any advertised update sitting below that setting. A release candidate is one rung below stable, so at default settings Joomla reads the update out of the feed and then throws it away without telling anyone. The vendor’s instruction is to go to System, then Update, then Extensions, click Options, and set Minimum Extension Stability to Release Candidate. That works. Note that it is a site-wide setting rather than a per-extension one, so every other extension on that site will start offering you its pre-release builds too, and it stays that way until somebody puts it back.

The Undocumented Reason: a Regex Bug

The second reason is not documented anywhere, and no setting fixes it. The feed entries for 4.7.0 and for 4.6.8 beside it both declare which Joomla versions they are for like this:

<targetplatform name="joomla" version="5.[4]"/>

Joomla takes that version attribute as a regular expression, anchors it, and tests it against the running Joomla version:

preg_match('/^' . $this->currentUpdate->targetplatform['VERSION'] . '/', JVERSION)

That line is in libraries/src/Updater/Adapter/ExtensionAdapter.php, and it is identical in Joomla 5.1, 5.3 and 6.1. The pattern 5.[4] reads as a 5, then any single character, then a 4. It matches Joomla 5.4.x. It matches nothing else:

preg_match('/^5.[4]/', '5.4.2');   // 1
preg_match('/^5.[4]/', '5.3.1');   // 0
preg_match('/^5.[4]/', '5.1.4');   // 0
preg_match('/^5.[4]/', '4.4.13');  // 0

So on any Joomla site below 5.4, the 4.7.0 entry is discarded before the stability setting is even consulted, and the 4.6.8 entry goes with it. The only entry left that those sites can see is 4.6.3, whose target platform is an empty string and therefore matches everything. Because 4.6.3 is older than whatever they already have installed, Joomla compares the two, finds nothing newer, and reports the site as up to date.

We described this feed on 13 August as stopping at 4.6.8. That was right about the feed’s contents and wrong about the consequence: for every Joomla version except 5.4, the feed effectively stops at 4.6.3. The same pattern sits on the 4.6.8 entry, so this is not something 4.7.0 introduced, and lowering your stability setting will not fix it.

Either way the reliable route is a manual install. Log in to fabrikar.com with a current subscription, take the 4.7.0 package from My Download Files, and install it on each site through Extensions, Install. Then check the version the site actually ended up on, because a package that installs without complaint is not the same as a package that installed.

The changelog history page has moved backwards too: the 4.7.0 entry is gone, and the newest release the page lists is 4.6.8 from 10 August, a version both CVE records say is vulnerable.

If a colleague checked earlier in the week and reported back that 4.7.0 did not exist, they were reading the site correctly at the time. On 11 August a subscriber posted that the download button was greyed out, and a Fabrik administrator replied that “V4.7.0 is not ready, it is being tested by a few people to make sure it is good. Announcement will be displayed shortly.” The announcement arrived two days later. Someone else has since reported on the release notes thread that listing 4.7.0 with restricted access breaks the updater’s route to 4.6.7 as well, so a site offering you no Fabrik update at all is not telling you it is up to date.

The Timeline: Announced, Restricted, Relabelled

Eight days, three security releases, two CVEs scored 10.0, one CVE revision, one version number that does not exist, and six days between the fix being written and the people running the software being able to install it. If you are trying to work out why the answer to “what should this site be running” keeps moving, the sequence explains it.

The full timeline is at the foot of this post.

Two threads run through that table.

Announced Is Not the Same as Released

Fabrik announced 4.7.0 on 13 August, with release notes, a release date and a maturity of Stable, and told people it was a major security release. For the next three days most subscribers could not get it. That is not our inference: on 11 August a subscriber reported the download button greyed out and an administrator answered “V4.7.0 is not ready, it is being tested by a few people to make sure it is good”; on the evening of 13 August, hours after the announcement, another subscriber posted that “adding and restricting access to v4.7 breaks updating from Joomla updater”; and the 16 August post opens by saying it “has been thoroughly tested by a small group of users” before announcing that “in a 1st step we are making it available as a Release Candidate”.

Put those together and the announcement of 13 August described a build in the hands of a test group as a stable release, on the vendor’s own account of who had it. Anyone reading fabrikar.com that weekend, holding two CVSS 10.0 unauthenticated code execution flaws with no other remedy, was looking at a fix they were told existed and could not obtain.

What became available on 16 August is a release candidate that Joomla will not show you until you lower your site’s minimum extension stability. So the fix has gone from announced but withheld, to obtainable but formally pre-release.

There is one more wrinkle, inside the package. Every file in the 4.7.0 download is timestamped 15 August 2026, 06:29, two days after the release date its own page gives. Whatever the small test group had on 13 August, the build you can download now was assembled on the 15th.

The Announcement Told Attackers Where to Look

The release information page went up on 13 August with two pieces of text. The changelog entry, dated 2026-08-10, says the release is “a major hardening release against PHP eval attack vectors”. The notes say: “This is a major security release. This release will break any userAjax you are using. Also, if you are using FullCalendar or Paypal you will need to update to the latest versions.”

Read that as an attacker. The CVEs had already told you there was an unauthenticated path to code execution in Fabrik, and the revised record had already told you 4.6.8 did not close it. What this page added was two things the CVEs did not say: that the problem is a class of eval attack vectors rather than the two specific ones with numbers attached, and that the thing being changed is userAjax, which names the surface to go and look at.

That page was public on 13 August. The release it describes did not become generally available until 16 August. For three days it described where the remaining problem was, in a product whose source is closed, to an audience that included everyone except the people who needed to fix their sites.

Counting from the date on the fix itself, it is worse. The change is dated 10 August. It reached the people running the software on 16 August. That is six days in which the work was done, the nature of it was published, and the sites with two flaws scored 10.0 could do nothing about it. Fabrik’s own instruction throughout was to update immediately.

There is a second supply problem underneath all of this. A thread running since 8 July has multiple subscribers reporting “Could not open update site” for Fabrik Base on every one of their sites, with valid subscriptions and correct download keys. It is still unresolved. The vendor’s answer on 16 August was “Workaround: download from your My download files on fabrikar.com and install. No idea what is going on on your sites.” Those users have had no working updater route to any Fabrik security release for over a month.

And Three Published Pages Were Altered Afterwards

Everything Fabrik put out about 4.7.0 on 13 August has since been changed, and the three changes are the clearest evidence of what happened.

The changelog history entry has been withdrawn. Fabrik listed Fabrik Base Version 4.7.0 on that page on 13 August, dated 2026-08-13, with the “major hardening release against PHP eval attack vectors” note attached, and our release monitoring recorded it at 13:30 UTC. It is not there today, and the newest entry is 4.6.8. The likeliest explanation for the row vanishing is mechanical rather than intended, because that page appears to list stable releases, so demoting 4.7.0 to Release Candidate would drop it off by itself. That makes the missing row independent confirmation of the downgrade rather than a separate act of tidying up. It also leaves the vendor’s own release page telling anyone who checks that the latest Fabrik release is 4.6.8, which both CVE records cover.

The maturity was changed. Fabrik 4.7.0 went from Stable to Release Candidate with no change to the build, no change to the 13 August release date, and nothing on the page recording that it moved. We read that page on 13 August, published that it said Stable, and emailed it to every account with an affected site. The same URL says something different three days later.

The release notes thread was retitled, from “Fabrik V4.7.0 Release Notes” to “Fabrik V4.7.0 Release Notes, Release Candidate is now available”. That one is checkable from outside: the URL we linked on 13 August now 301s to the new one. And the 16 August post presents the release candidate as the plan all along, in a thread whose first post three days earlier had called 4.7.0 a major release with no such qualifier.

None of this would matter much if there were something else to install. There is not. 4.7.0 is the only publicly downloadable release above both CVE ceilings. It is the only thing anyone can actually do about two unauthenticated code execution flaws, both scored 10.0, in an extension whose vulnerable code is on every version ever shipped. Anyone who did manage to get the package between 13 and 16 August installed it on production sites believing it was a stable release, because the alternative was staying on a version the CVE record says is exploitable without a login. The build has not changed. What changed is what the vendor is willing to call it, and the new answer arrives with an instruction to lower your site’s minimum extension stability so Joomla will accept pre-release software.

Our advice has not changed either, because there is nothing else to point at. Get to 4.7.0. Test it on a sandbox first, which was already the vendor’s advice and matters more now than it did at release.

We Read the Fabrik 4.7.0 Code, and the Fix Is Real

Fabrik 4.x has never had public source. The GitHub repository stops at 3.10 from 2021, the vendor’s own “GitHub” footer link points at a Bitbucket repository that 404s, and 4.x ships only to subscribers. So nobody outside the vendor’s test group has been able to check whether any of the three security releases did what they claimed.

We obtained the 4.7.0 package and read it. Its SHA-256 is b1d79d144a23142704f6524947ffd6f8d705bf38f85cb65ba9c9b7472d8e8316, which matches the sha256 Fabrik publishes in its own Joomla update feed, so this is the release itself and not something reconstructed.

After two fixes that did not hold, this one does. It addresses the class of bug rather than the instance.

What actually changed

eval() now appears in two files out of 869, and everything routes through one helper, Fabrik\Helpers\Php::Eval(), reached from 61 places.

The old design took the site builder’s PHP expression, substituted the visitor’s submitted data into it as text, then evaluated the result. That is what turned data into code, and it is why an anonymous request could run PHP on the server.

4.7.0 inverts it. The helper compiles the site builder’s code once into a cached class, then passes the visitor’s data in as bound PHP variables instead of splicing it into the source. Data that is never concatenated into code cannot become code, whatever it contains. All 61 call sites use that route.

Where placeholders do still expand into code, the substituted value is written out with var_export(), so a submitted value arrives as a quoted PHP literal rather than as syntax.

They also caught the trap that a naive version of that fix leaves behind. If the site builder’s own expression already has the placeholder inside a quoted string, wrapping it in fresh quotes either produces broken code or escapes for the wrong quote character. The new code runs PHP’s own tokenizer over the expression to establish the quote context at that exact byte offset, then escapes for the quotes that are already there. A comment in the file records that an earlier attempt missed this case.

The most telling line is the vendor’s own note on why the earlier fixes failed:

That is the 4.6.7 and 4.6.8 story in a sentence. Escaping for HTML does nothing to a payload that never needed a quote character in the first place.

The list filter path, the second CVE, is closed the same way, and its guard is switched on by exactly the condition that decides whether the evaluation happens at all. That pairing is the detail these fixes usually get wrong.

What we did not find

No remaining route from an unauthenticated request to code execution. No system, exec, create_function or unserialize reached by request data anywhere in the package. The one place that could build a require_once out of a string is fed by an administrator-only setting, filtered to alphanumerics and confined to a fixed directory.

Three things weaker than the release notes suggest

The release notes say every AJAX call must now have a session token and a proper Content-Type. There is a real gate, and it runs as the first statement of every front-end controller entry point, which is the right place for it. Three details matter:

• The token is enforced only on requests that are not GET.
• The Content-Type check applies only to POST.
• The Referer check is skipped entirely when the browser sends no Referer header.

So an anonymous GET still reaches the calc endpoint. That is no longer a way in, because what it used to lead to is closed, but the token is not the barrier the release notes imply and it should not be the thing you rely on.

The caveat on all of this

This is a source review, not a live exploitation test. We read the code and traced every path from request input to every remaining evaluation. We did not stand up a site and fire the old payloads at it. A negative result from reading is weaker than a negative result from trying. What we can say is that the mechanism behind both CVEs has been removed rather than patched around, and that a future call site cannot reintroduce it by forgetting to escape, because escaping is no longer how it works.

How Serious Is This Really?

The Joomla CNA scored it 10.0 Critical on CVSS 4.0, the maximum. The vector says the attack comes over the network, needs no privileges, needs no user interaction, and produces high confidentiality, integrity and availability impact both on the vulnerable component and on the wider system. That is the score to work from.

The nuance is about reach rather than severity. Reaching the flaw needs the site to publish a Fabrik form or list that an anonymous visitor can load, and that form needs a calc element with the AJAX option enabled. A Fabrik install used only behind a login, or one with no calc elements, is a smaller target than the score alone implies.

That nuance is close to useless as an operational filter, for two reasons. Public forms are the ordinary use of Fabrik, not an edge case, and a site builder who wanted a login-only tool would usually reach for something simpler. And there is no practical way to audit “does any published form on this site contain an AJAX-enabled calc element” across more than a handful of sites without opening every form on every site by hand. Treat every install below 4.7.0 as affected, because you cannot cheaply prove otherwise, and because the list filter flaw is reached through a different surface again.

The second flaw removes even that much comfort. List filters are the controls that narrow a Fabrik list, so CVE-2026-67282 does not depend on calc elements or on the AJAX option at all. A site with no calc element anywhere, which was the smaller target under the first flaw, is squarely in scope for the second.

Nobody had reported exploitation in the wild when this post was last updated on 16 August 2026, and neither CVE has a CISA Known Exploited Vulnerabilities entry. Neither of those is reassuring on its own. An unauthenticated flaw that ends in code execution is the profile that attracts mass scanning quickly, and Joomla extension flaws of exactly this class have gone from disclosure to automated exploitation inside a week several times this year.

How to Fix Your Joomla Sites Running Fabrik

1. Find every site running Fabrik and check the version. Anything below 4.7.0 is affected, including the sites you updated to 4.6.7 or 4.6.8 last week. The component shows as com_fabrik in Joomla’s extension manager.

2. Confirm the Fabrik subscription is current. Both update routes, Joomla’s updater and direct download, check it. This is worth doing first, because discovering a lapsed subscription halfway through an update run across several sites wastes an afternoon.

3. Test 4.7.0 on a sandbox before you touch anything live. Fabrik states that 4.7.0 breaks any userAjax calls you use, and that FullCalendar and Paypal need updating to current versions alongside it. Find out which of your applications depend on those on a copy, not on the site your client is looking at.

4. Install Fabrik 4.7.0 by hand. Joomla’s updater will not show it at default settings, and on any Joomla below 5.4 it will not show it at all. Download the package from My Download Files on fabrikar.com with a current subscription, then install it through Extensions, Install on each site and check the version you actually ended up on afterwards. If 4.7.0 is not there or the download is greyed out, that is the restricted access other subscribers have been reporting since 13 August rather than a problem with your account, and the forum announcement thread is where the vendor has been posting about it.

5. Deal with the sites that cannot take it. See the next section. Joomla 3 sites now have a manual patch for the calc element flaw. Unpublishing public Fabrik forms and lists reduces exposure while you decide, though it is a stopgap rather than a fix.

6. Check exposed sites for compromise. Updating stops the next attempt and tells you nothing about whether one already succeeded. An unauthenticated flaw leaves no failed logins and no audit trail. Look for administrator accounts you did not create, recently modified or unfamiliar PHP files, and scheduled tasks nobody added. Our post on finding rogue admin accounts across every Joomla site covers the account side, and reinfection through crontabs covers a persistence route people routinely miss.

Not Every Joomla Site Can Install the Fabrik Fix

This is the part that turns a straightforward update into a project. Fabrik’s installation notes say 4.7.0 installs on Joomla 4.2 and above, and Joomla 5.1 and above, the same window as 4.6.7 and 4.6.8 before it. The forum announcement adds that Fabrik 4 will not install on Joomla 6. So the fixed releases have a compatibility window of Joomla 4.2 to Joomla 5.x, and sites at either end of that window are stuck.

Below the window sit the Joomla 3 sites. They run the Fabrik 3.x line, whose last release was 3.10 in August 2021. The calc element’s AJAX evaluation path is present in that code, the joomla3 branch of the public repository has had no commits since 2016, and there is no patched version for those sites to move to. Fabrik has now confirmed there never will be, and explained why:

Above the window sit the Joomla 6 sites, which the vendor’s own announcement rules out in one line.

Across the Joomla sites we manage, this splits the affected population roughly two to one against being able to fix it by updating:

Of the sites still short of 4.7.0, roughly two thirds are on a Joomla version the fix does not support. The single most common configuration we see is Fabrik 3.10 on Joomla 3.10, which is a site running the newest version each project ever shipped for that generation, and exposed anyway.

Fabrik 3 Now Has a Manual Patch

This changed on 11 August 2026, and it is the one piece of good news in the sequence. After a subscriber asked on the forum for something their Joomla 3 clients could use while migrations were in progress, a Fabrik administrator published a manual source patch for the Fabrik 3 code, covering the calc element flaw. It is a single line in plugin/fabrik_element/calc/calc.php, adding two arguments to the existing parseMessageForPlaceHolder call so that the placeholder replacement runs in its escaped mode.

Read the forum thread before you touch a file, and note the correction in the reply: the method name in the original post has a typo, and the working line uses parseMessageForPlaceHolder.

Three caveats, all of them the vendor’s own:

• It is offered as-is, with no warranty. Nobody is supporting this on your site.
• It covers the calc element flaw only. Fabrik states that the second attack vector, the list filter one patched in 4.6.8, does not affect Fabrik 3.
• Fabrik still strongly urges migration to Fabrik 4, and a hand-edited file is not a maintained release.

Take it as a stopgap that buys you time on the largest group of affected sites, which is roughly three in five of everything we can see. It is not a reason to stop planning the migration.

The Sites With No Path At All

If you have Joomla 6 sites running Fabrik, or Joomla 3 sites where hand-editing a plugin file is not something you are willing to take on, there are three honest options and no comfortable ones. Remove Fabrik, if the application it powers can be retired or rebuilt. Move the site onto Joomla 4.2 to 5.x, which is the work you were putting off anyway and now has a deadline attached. Or accept the risk knowingly, with public Fabrik forms and lists unpublished, which is a holding position rather than a solution. Joomla 3 has been end of life since August 2023, and this is the ordinary way that debt gets called in, through a third-party extension whose vendor has moved on to the next Joomla generation. We have written before about what is realistically available to sites still on Joomla 3.

Finding Every Fabrik Install Across Your Joomla Sites

Doing this by hand means logging in to each Joomla site, opening the extension manager, searching for Fabrik and writing the version down. For one site that is two minutes. For fifty it is an afternoon you will not get back, and you will still not be certain you checked them all.

mySites.guru keeps a live inventory of every extension, template and framework on every connected Joomla and WordPress site. Search the extension inventory for Fabrik once and you get back every site running it, the version each one is on, and whether an update is available, on one screen. Sites running a version flagged on our vulnerable extension list are marked automatically, so a site that drifts onto an affected version later gets flagged without anyone remembering to look.

For this particular flaw the inventory answers the second question too. Because it records the Joomla version alongside the extension version, you can separate the sites that just need an update from the sites that need a migration decision, which is the split that actually determines how much work you are looking at.

If a site turns out to have been compromised, fix.mysites.guru is a fixed fee of £120 per incident, usually same day. Sites are screened before we commit, so you are not charged in the very rare case that it cannot be fixed, and non-subscribers get a free month. There is more on recovery in our Joomla hacked guide.

Fabrik Has Been a Target Before

Fabrik has carried three earlier CVEs before this month’s pair, and the pattern is worth knowing if you have run it for a long time:

• CVE-2010-1981, a directory traversal in com_fabrik 2.0 allowing arbitrary file reads
• CVE-2011-5004, an unrestricted file upload in the CSV import model, fixed before 2.1.1
• CVE-2018-10727, a reflected cross-site scripting flaw through a hidden referrer field, affecting versions through 3.8.1

The Joomla Vulnerable Extensions List also has a resolved entry for “fabrik 3.9, Various Issues”, published in May 2020 and fixed in 3.9.1. Neither of this month’s CVEs was on the VEL when we last checked it, on 13 August 2026.

There is also one recent release that never got a CVE at all. Fabrik 4.6.3, released on 25 February 2026, has a changelog line reading simply “Security fix” with no further detail, under the same “This is a security release, please update immediately” note that 4.6.7 uses. Nothing has been published about what it closed. That is worth knowing if you are the sort of person who skips point releases on an extension that seems to be ticking over without incident, because four times this year a Fabrik release has been the security update, and the CVE numbers arrived days later or not at all.

The 2011 upload flaw is the one that left a mark. Several public auto-exploiter tools targeting com_fabrik are still sitting on GitHub, written years ago against that bug. They are irrelevant to this CVE, but they are a reminder that a Joomla extension with a long history and a shell-upload flaw in its past stays on scanners’ lists long after the flaw is fixed.