Written by: 
On Thursday, Friday 16th at 16:00 UTC Joomla released version 4.2.8 with a major security fix. The vulnerability, they warned, was a very serious one and you would all need to update. However, the necessary information gap which follows a security release —so as not to tip off miscreants— has let rumours spread in such a way that they make people risk unnecessary damage to their site, or at least give the false impression that all Joomla sites have been “magically” hacked like we're in some Hollywood movie. That's not how the world works, so please let us explain exactly what is going on and you should not freak out.
Discovering the nature of the vulnerability
As I said above, the Joomla project decided to do exactly what every organisation pushing out a patch for a major vulnerability does: would not provide any information on the vulnerability fixed for weeks after the security fix so as not to tip the hand of any attacker.
However, this particular vulnerability is very serious, very straightforward, it has a trivial two line patch which was made publicly available at the same time as the security patch.
I would urge the Joomla Security Strike Team to not stick to an inflexible doctrine of delayed information sharing in situations like this. I would argue that forewarning the community is the better strategy, especially when you can simultaneously provide mitigation information for something attackers will figure out within minutes of the security release — a security release announced days in advance, getting the attention of literally everybody, be it a 3PD writing security software like us, site integrators anxious to protect their sites, or attackers eager to exploit sites.
Mitigation
The recommended course of action to mitigate this attack is, of course, to install the Joomla 4.2.8 update.
If you are on an older Joomla version family, e.g. 4.0 or 4.1, and cannot update for any number of reasons you can do one of three things.
Option A: Modify the libraries/src/Router/ApiRouter.php file
Find the line
$query = Uri::getInstance()->getQuery(true);
Add the following code below it:
// Remove the public key as it is only supported coming from the route definition
if (array_key_exists('public', $query)) {
unset($query['public']);
}
This effectively applies the security patch from Joomla 4.2.8 and “inoculates” your site against the vulnerability.
Option B: .htaccess code
Assuming that you are using Apache or LiteSpeed as your web server, you can add the following code to your .htaccess file, right below the RewriteRule line:
RewriteCond %{QUERY_STRING} public=
RewriteRule api/?. - [F]
These two lines will block any request to Joomla's API application which would trigger the vulnerability.
Option C: disabling the Joomla API
Unpublish all plugins in the webservices group. Do remember that by doing this you are disallowing all access, legitimate or not, to the Joomla JSON API which can and will break things in the future. This is only meant as a temporary solution.
To do that, go to your site's administrator backend and click on System, Manage, Plugins.
In the Plugins page click on Filter Options above the list.
From the “- Select Type -” dropdown choose the webservices option.
Select all items (use the checkbox at the top row of the list) and click on Disable.
Which Joomla version are affected?
Joomla 4.0.0-Beta2 up to and including Joomla 4.2.7.
Older versions of Joomla are not affected as they did not have the API application.
Newer versions of Joomla are not affected because the vulnerability has been addressed there.
Have I been hacked?
Apparently, releasing a security fix for a vulnerability that scores 10 out of 10 in the WASP scale (I would rate it a 9, as 10 is meant to be used for direct arbitrary code execution, but whatever) is like shouting “FIRE!” in a crowded theatre.
It caused a stampede.
People filled the information void with hearsay, wild conjectures, and —not to put too fine a point on it— utter rubbish. The number of people I have seen changing their database and email passwords in sheer panic is stupefying. However, I would argue that the vast majority, if not totality, of these people have not been hacked and need not do anything as drastic.
If you want to be sure you have not been hacked download your raw access log and look for the following regular expression:
api/(.*)(\?|&)public=
You can download your raw access log in cPanel through the Raw Access menu item. This downloads a .gz file which needs to be extracted first e.g. using 7-Zip.
If you are on a Linux, macOS, or *BSD system and you're handy with the command line you can scan the entire compressed file for signs of an attack like so:
gzcat akeeba.com-ssl_log-Feb-2023.gz| grep -E -e "api/(.*)(\?|&)public=
If you get no hits you're golden. If you only get hits with a 403 status code like this below you're also golden:
192.168.1.1 - - [17/Feb/2023:09:17:18 +0200] "GET /api/index.php/v1/content/articles?public=1 HTTP/2.0" 403 66 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0"
The line above was me verifying the fix works.
You should only worry if you receive hits like this:
192.168.1.1 - - [17/Feb/2023:06:17:42 +0200] "GET /api/index.php/v1/content/articles?public=true HTTP/2.0" 200 583 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
Note that the date (the first bold part between brackets) must be BEFORE the date and time you applied the mitigation AND the status code (the second bold part) must be 200. If you have hits like that then yes, you have been hacked.
What should I do if I have not been hacked?
Make sure you have a mitigation in place.
To check your mitigation try accessing the URL https://www.example.com/api/index.php/v1/content/articles?public=1 in your browser, where https://www.example.com is the URL to your own site. If you get a Forbidden message or an error message your site is safe.
What should I do if I have been hacked?
The URLs in your access log file tell you which information the hackers have accessed.
At the very least you should change all passwords present in your configuration.php file such as your database password, mail server password etc.
You should also change your site's secrets. The easiest way to do that is take a backup of your site with Akeeba Backup (the free version will do just fine) and restore it again back on your site; this always changes your site's secrets.
If you have evidence that the attacker accessed your user's information you need to notify your users that a data breach has occurred and an unknown attacker has the name, email address (plus whatever other information you collect), and a hashed version of their password. Depending on your jurisdiction you may need to disclose the data breach to your local authorities, e.g. your country's Data Protection Office if you in the EU.
Do I need to change my database and email password?
Not unless you have POSITIVE confirmation that your site has been hacked.
If you are not absolutely certain that you can check for that, despite the information above, you can always change your database and email password. Do keep in mind that by doing so you may break your site so please do take a backup. Akeeba Backup Core is free of charge and can save your neck if things go pear-shaped.
Isn't Joomla insecure?
NO!
Just because there is a serious vulnerability found and fixed doesn't mean that the software is insecure. This kind of major vulnerabilities have been found in the last decade in WordPress, Drupal, Typo3, Microsoft Windows, Apple macOS/iOS/iPadOS/tvOS/watchOS, Google Chrome OS, Android, and Linux. Vulnerabilities are bugs, and bugs are a fact of life.
If you want to be unexposed to software vulnerabilities you have to live completely off the grid, as a luddite, in a cave.
Should I disable the Joomla API altogether?
No, please don't!
The API is a very useful feature in Joomla 4.
Disabling it will eventually break useful features in the core and third party applications.
I know many of the people reading this will not listen to me and disable it anyway. I know the same people will moan, groan, and complain about something not working at a later point in time because they disabled the API application. Look, people. If you sabotage your site it will come to bit you in the posterior. If it happens, undo your changes.
Eventually, the Joomla project will change how the API applications work. Right now, the API is only accessible if you authenticate as a Super User and the assumption was made that if you're authenticated you must be a Super User, therefore you can see everything. This was supposed to be a conservative approach, but it also enabled this vulnerability to have a big impact. In the future, the core API components will be modified to have finer grained control over what information they display and allow changing, checking the actual permissions of the authenticated user. This means that even if somehow in the future such an authentication bypass were to happen again, the attacker would have Guest user permissions, therefore they would only be able to see what they can already see in the public HTML site, making it a non-issue.
You see, the solution to finding a problem is not nuking the entire useful thing which sprang a leak from high orbit. It's working on the darned thing to make it resilient and secure. This is a universal truth in security, be it IT security or physical security. Let me put it a different way. If you found out that your door's lock can be bumped and overridden would you remove the door and replace it with a brick wall, or would you invest in a better, more secure lock? Disabling the API application is the computer equivalent of replacing your front door with a brick wall; congratulations, you've buried yourself in a tomb of your own making.
Bonus question: does this affect Akeeba Backup Professional's API? Do I need to regenerate its secret word?
No. Akeeba Backup Professional's JSON API does not use the Joomla API application. We implement our own thing which is not affected by the vulnerability in Joomla 4's API application. You do not need to regenerate your secret word.
Thank you so much for this excellent article.
It's so useful (and reassuring) to have a way to know with certainty whether our site was affected by this vulnerability or not.
Thank you again !!
TEST
Test
Thanks Nicholas, appreciate the knowledge.
I'm one of the people that will ignore you and switch off the API. If nothing is using it I don't see the reason to leave a potential hole. I've been doing it the entire time. I assume that meant I was safe from this hack. Hurruh.
But one thing that does happen consistently is my update sites get turned off, including Joomla core.
I find this really suspicous. I've mentioned it on Mattermost, but my hunch has always been that this could potentially be an API vulnerability.
Would this hack have been able to do something like that?
I've also noticed that turning off the API and it comes back on again. Which I find odd, from the user part of Joomla.
Turning off the API is never the solution. You will have problems and, when you do, I will tell you "I told you so". A few examples. Panopticon uses the Joomla! API application to monitor your sites. Akeeba Backup is using it for remote backups -- and in a couple of years it will remove the old API altogether.
Your question about the update sites getting disabled... Let's use Occam's Razor. Which of the following two explanations is far more likely than the other?
A. L33t h4x0rz have nothing better to do with their time than monitor your site. Every time you enable an update site, they disable it. They don't use their access to deface your site, steal your data, serve malware, or generally make any street cred or money. They just diligently work continuously to merely... annoy you less than a fly.
B. Your server has a simple configuration issue. It fails to download the update XML file, and Joomla disables the update site as it has been doing since Joomla! 1.6 released back in 2010, fourteen years ago.
Ok makes sense, I use the remote backup so I'll turn it back on. Thanks for the heads up.
There are plenty of hacks that people do just because they can. It's just kiddie coders right? And it's just scripts. It's not always about achieving a financial result more proving you can do something. That's what I had assumed was happening.
I would wonder if it's a server configuration why it only happens sometimes. I always assume it happens randomly but as the J4 dashboard always checks perhaps it happens randomly when I am on the dashboard page and I don't notice until my next update.
In any case I can see no really good reason for them turning off at all. Especially not core. But I'm sure you will educate me differently.
Turning them on again doesn't turn them off automatically either. Perhaps the XML file really is temporarily down at that time or something.
You actually think that anyone who would find a novel way to get into any site would do absolutely sod all with it except reproduce a standard 14 year old behaviour which barely annoys anybody on the sites of just the one random person? That's a lamer plot line than Armageddon, and it doesn't even have a good cast to begin with.
A server can have myriads of issues which would cause intermittent problems. DNS (you wouldn't believe how often this is). Network stability (I have some funny horror stories about this, including the one where an earthquake in Algeria made me waste a day thinking my code was doing something wrong). Bad transparent proxy (I have recreated that one for shit and giggles). I could go on, but I have neither the time nor inclination at the moment.
And yes, Joomla does try to load updates whenever you visit its control panel. Remember those quickicons in the Control Panel about CMS and extension updates? That's what they're doing, alright!
As to why you need to disable them, it of course makes sense. You may be in an intranet which blackholes all communications with the Internet, meaning you never get a reply (the connection has to time out). Or you may be on a network which cannot access Internet resources reliably (such as satellite Internet way up north, or having shit tier Internet access like half of the world). Or the domain you are trying to access may have expired (e.g. 3PD went out of business). Or the third party server is no longer responding for any number of reasons. And so on and so forth. If Joomla would get stuck waiting for any one of these servers forever for a response you'd never get any update information from any other servers. So, what it does, is disable the non-responsive update site so the next time you try to fetch updates it will hopefully succeed. And this is also why when you manually try to fetch updates it re-enables the whole lot; it assumes that some update servers may have been disabled because of a transient network issue.
The core update servers are not special in any way... at least before 5.1.0 and the use of TUF. Because, you see, TUF is written by German folks who take reliable Internet as a given, and ignore all sorts of issues which may happen in the real world. Let's just say that things will get, um, tough for them when Joomla switches to TUF as its primary update method.