Here at Joomlashack, we were alerted to a possible security issue with OSMap.
To the best of our knowledge, this report is false. We did post our own detailed response on the reporting site called "Packet Storm". However, not only did Packet Storm remove the security report, but other sites picked up the report with our response.
So we wanted to share details of this OSMap issue and our response. We take all security issues very seriously, and want to reassure OSMap users.
The key part of the report started like this:
Joomla OSMap Components 4.2.19 and other versions - component for Joomla is prone to an SQL-injection vulnerability because it fails to sufficiently sanitize user-supplied data before using it in an SQL query.
We did a careful review of our code and saw no indications of a problem. We also attempted to replicate the issue, even using a special version that did no input filtering whatsoever. We could find no indications of a problem.
Looking at the report carefully, it seems to have been generated by an automated tool from IBM Cloud. The person who posted the OSMap security report was using this tool to publish large quantities of potential security issues.
Joomla and MySQL Files
We talked with the Packet Storm staff in depth, and answered their security questions.
They were curious about the practice of storing SQL install/update scripts in Joomla extensions. Here are a couple of examples:
- /administrator/components/com_osmap/sql/updates/mysql/utf8/4.2.0.sql
- /administrator/components/com_osmap/sql/install/mysql/utf8.sql
This is the default behavior in Joomla, but it was mentioned in the OSMap security report.
So we raised the issue to the Joomla core developers. Here is the response we received from the Joomla Security Strike Team:
We discussed this topic a couple of days ago because we received similar reports for Joomla core. The only "issue" resuting from the availabilty of those files is the fact that an attacker might be able to detect if a specific Joomla and/or extension version is installed, however: in most situations, there are other, more bulletproof ways of getting this information (i.e. hashsum fingerprinting of public assets). Attackers don't detect upfront, they just fire exploits because the additional detection request doesn't give them any advantage. So, at the end of the day there's no real world security impact from the .sql files. For Joomla 4, we are considering a webserver-level block for sql files in the administrator, but backporting it to Joomla 3 is extremly unlikely as it's a potential B/C break.
How to Report Security Issues
If you do find a security issue, please report it. You'll get an all-hands-on-deck response from our team. Send an email to This email address is being protected from spambots. You need JavaScript enabled to view it..
The Joomla Security team are available at This email address is being protected from spambots. You need JavaScript enabled to view it..
About the author
