Patch issued for one flaw, but Joomla maintainers contest the severity of a second bug
UPDATED Security researchers have revealed the details of two vulnerabilities in Joomla – the popular content management system – which, if chained together, they said could be used to achieve full system compromise.
The two vulnerabilities – a password reset vulnerability and a stored cross-site scripting (XSS) flaw – were both discovered by security researchers at Fortbridge and responsibly disclosed to Joomla’s developers in February and March, respectively.
After some delays, Joomla released a patch for the XSS vulnerability with version 3.9.27 of the CMS (released in May). The password reset vulnerability – which Fortbridge warns remains unresolved – can be mitigated with a “trusted_hosts” configuration.
Fortbridge advises Joomla users to set the “$live_site” variable in the configuration.php file as a workaround pending the delivery of a patch for the password reset issue.
According to Joomla, however, this HOST-header injection vulnerability requires “extremely specific circumstances” that are “extremely uncommon” in the Joomla community in order to be exploitable.
The two vulnerabilities in Joomla are both high severity and “when chained together they allow an attacker to take over Joomla& website completely”, Adrian Tiron, managing partner at Fortbridge, told The Daily Swig.
“Once the attacker has full access to the Joomla website, [they] can upload a PHP shell which will allow [them] to execute commands on the server,” Tiron warned.
The password reset vulnerability allows the attacker to reset an administrator’s password.
Tiron explained: “The attacker triggers the password reset process and can manipulate the password reset link to point to the attacker’s server where [they will] capture the victim’s token and reset [their] password once the victim clicks on the link, or the link is fetched by some AV/EDR [anti-virus/ endpoint detection and response] scanning solution.
“Once the attacker was able to reset the admin’s password an obtained admin privileges, [they] use the second vulnerability, a stored XSS, to target the ‘Super Admin’ user.”
In response to questions from The Daily Swig, Joomla’s developers offered a detailed statement disputing the alleged seriousness of the flaws discovered by Fortbridge:
Fortbridge initially reported two separate issues:
1. a so-called HOST-header injection
2. an attack vector that would ultimately lead to an XSS attack, while requiring the existence of a privileged but non-super admin account on the Joomla installation
The XSS vector has been fixed in Joomla 3.9.27.
The HOST-header injection requires extremely specific circumstances to be exploitable, namely a web server setup with either:
a) no vhosts being configured or
b) a Joomla installation residing in the configured default vhost
Such a setup is extremely uncommon in the Joomla community, as the vast majority of sites are running in shared-hosting environments, where these conditions aren’t met.
However, even if a Joomla site is running in such an environment, a Joomla site can already be protected by utilizing the existing $live_site configuration flag in the configuration.php.
Fortbridge, which is sticking by its findings, rejected suggestions that the flaws it found only affected obscure configurations and were therefore difficult to exploit.
“It requires that Joomla is installed on a dedicated server to be specific (sometimes works in shared hosting),” according to Fortbridge. “The big Joomla websites will be on dedicated servers, thus they’re the most vulnerable to this issue.”
Fortbridge’s Tiron concluded: “Just because the two vulnerabilities require user interaction doesn’t make it un-exploitable.”
Joomla is one of the most popular CMS platforms with more than 1.5 million installations worldwide. Fortbridge came across the bugs it discovered in the platform during a penetration testing exercise.
Beyond the significance of the findings in their own right they offer lessons to other developers, according to Fortbridge’s Tiron.
For one thing the stored XSS flaw would have been preventable through the use of allowlists rather than blocklists. Secondly avoid making password reset links using $_SERVER[‘HTTP_HOST’] / $_SERVER[‘SERVER_NAME’], because these “variables are actually user input”, Tiron advised.
This story was updated to clarify that the password reset issue remains unresolved, according to security researchers at Fortbridge, and to add comment from Joomla disputing the researchers’ findings