Count of vulnerable Joomla! to CVE-2023-23752

We stumbled upon a nice article on recent CVE-2023-23752 vulnerability impacting Joomla! versions 4.0.0 through 4.2.7. article describes how one can leverage that issue to achieve Remote Code Execution (RCE).

However, they identified ~1,500 vulnerable instances. That number is underestimated. Let’s explain how we came to this conclusion.

On testing the vulnerability

We have added a check-based vulnerability detection to our vulnscan category of data on 2023/03/15. Check-based means our test is reliable as it is not based on version-detection. Thus, we have pretty early results in comparison to the vulnerability disclosure date. For customers, you can search your vulnerable assets with the following dork:

NOTE: This check has been launched against ~1.5M exposed Joomla! products.

category:vulnscan cve:CVE-2023-23752

For a complete list of CVEs we can detect, please refer to this page.

Counting the number of vulnerable instances

In order to have an exact view on vulnerable assets, you have to search vulnerable IP addresses, but also vulnerable virtual hosts. As we scan both, we can compare both numbers. Let’s aggregate and deduplicate all the results we have to start with:

onyphe -export 'category:vulnscan cve:CVE-2023-23752 -weekago:1 | uniq ip,port,forward | addcount'

NOTE: install our CLI Tools to execute this search.

The result is as many as 10,193 vulnerable machines. But some machines may expose the same instance on both port 80/tcp & 443/tcp ports (or other ports). So let’s count again on deduping against ip & forward fields only. forward field corresponds to the HTTP Host header (the so called virtual host):

onyphe -export 'category:vulnscan cve:CVE-2023-23752 -weekago:1 | uniq ip,forward | addcount'

That’s 7,693 unique results. From these results, we have 6,823 (87%) found from virtual host scanning and 870 (11%) found from IP scanning.

We may still have duplicates as some Web sites may be exposed with www host name added and also without that string. Again:

onyphe -export 'category:vulnscan cve:CVE-2023-23752 -weekago:1 | uniq ip,forward | regex forward="^(?:www\.)?(.+)" outputfield=forward | dedup ip,forward | addcount'

4,936 unique results from virtual-host scanning. It is more than 3 times the identified vulnerable assets based on exposed IP-addresses only, and this count is only for virtual host scanning results.

Of course, we can count on unique IP addresses. This number decreases to 3,981. Why so? Simply because many Joomla! instances are installed on shared hosting providers IP addresses. It is the role of the administrator to patch its software, and not the role of the provider, even in shared hosting environments. Without scanning virtual hosts, you just can’t see what is exposed on shared Web hosting platforms.

How many are also exposing publicly a database?

To answer this question, we have to execute a correlation search. By starting with a list of vulnerable IP addresses, we can search if they also expose a database:

onyphe -export 'category:vulnscan cve:CVE-2023-23752 -weekago:1 | uniq ip | search category:datascan device.class:database ip:$ip | dedup ip | fields ip | addcount'

1,263 results. Thus, out of 3,981 unique IP addresses, nearly a third are also exposing their database on the Internet. An explanation is because many Joomla! instances are hosted on shared Web hosting platforms and they have to have access to their database remotely.


This vulnerability is exploited at scale because it has some interest. Of course, we have seen more widely spread vulnerabilities, but we can count on this one to remain for some time and to be exploited.

As we usually do with such sensitive matters, Web & Free View users won’t be able to see our results. Only paid subscriptions will have access to result details. Furthermore, the check-based CVE is only available starting from Eagle View subscriptions which we don’t sell to everyone. We are a cyber defense search engine, and our purpose is to give access to such data for legitimate use only.

This is what looks like a stripped result (access denied by policy):