Joomla’s core codebase has gotten reasonably solid when it comes to SQL injection prevention. The framework provides database abstraction methods that handle escaping and quoting. The problem is that most Joomla sites do not run on core alone. They rely on dozens of third-party extensions - and this is where things fall apart.

In this post, we will look at how extensions introduce SQL injection vulnerabilities, what to look for before installing one, and how to audit extensions you already have running.

How Extensions Create Injection Points

The most common pattern is straightforward. A component or module takes user input from the URL or a form field and drops it directly into a SQL query without sanitization.

Here is a simplified example of what vulnerable code looks like in a Joomla component:

$id = JRequest::getVar('id');
$query = "SELECT * FROM #__items WHERE id = " . $id;
$db->setQuery($query);

The developer used JRequest::getVar() to grab the input, but did not cast it to an integer or use the database class escaping methods. An attacker can append arbitrary SQL to the id parameter.

The correct approach uses Joomla’s built-in methods:

$id = JRequest::getInt('id', 0);
$query = "SELECT * FROM #__items WHERE id = " . (int) $id;
$db->setQuery($query);

Using getInt() forces the value to an integer. The explicit cast adds a second layer of safety. For string values, you would use $db->Quote() and $db->getEscaped().

Why This Keeps Happening

The Joomla Extensions Directory (JED) has thousands of extensions. Many are written by developers who understand PHP but have limited security experience. The JED does not perform security audits before listing extensions. They rely on community reports and the Vulnerable Extensions List (VEL) to flag known issues after the fact.

This means that installing an extension from the JED is not a guarantee of safety. It simply means someone submitted it and it met the basic listing requirements.

Checking the VEL Before Installing

Before you install any extension, check the Joomla Vulnerable Extensions List at vel.joomla.org. Search for the extension name and see if any past vulnerabilities have been reported.

If an extension has had multiple SQL injection reports, think carefully about whether you trust the developer to have fixed the underlying coding practices - or just patched the specific reported issue.

Also check the extension’s page on the JED for:

  • Last update date. An extension that has not been updated in over a year may have unpatched issues.
  • Number of reviews and ratings. Popular extensions get more eyes on them.
  • Developer responsiveness. Check the support forum. Does the developer respond to security reports?

Auditing Extensions You Already Have

If you have extensions already installed and want to check them, here is a practical approach.

Step 1: Identify Your Extensions

Go to Extensions > Install/Uninstall in the Joomla admin. Make a list of every third-party component, module, and plugin installed.

Step 2: Search for Direct Query Construction

Look in the extension’s PHP files for patterns like these:

grep -rn "getVar\|getCmd\|getString" components/com_extensionname/

Then check whether the results of those calls are passed through escaping functions or cast to the expected type before being used in queries.

Step 3: Look for Raw Query Strings

Search for SQL keywords concatenated with variables:

grep -rn "SELECT.*\$\|INSERT.*\$\|UPDATE.*\$\|DELETE.*\$" components/com_extensionname/

Any line where a PHP variable is concatenated into a SQL string without using $db->Quote() or type casting is a potential injection point.

Step 4: Test with Basic Payloads

For components that take URL parameters, try appending a single quote to numeric parameters:

index.php?option=com_extensionname&id=1'

If you get a database error message, the input is not being sanitized. This is not a comprehensive penetration test, but it catches the most obvious issues.

What To Do When You Find a Vulnerability

  1. Disable the extension immediately if it is not critical to your site.
  2. Contact the developer with details of the issue. Give them a reasonable timeline to respond.
  3. Report it to the Joomla VEL so other administrators are warned.
  4. Check for alternatives on the JED that provide similar functionality.

If you must keep a vulnerable extension running while waiting for a fix, consider adding mod_security rules or .htaccess filters to block common injection payloads targeting that specific parameter.

The Takeaway

Your Joomla site is only as secure as its weakest extension. Treat every third-party extension as untrusted code until you have verified otherwise. Audit before installing, keep everything updated, and monitor the VEL regularly. Most Joomla compromises I have investigated trace back to a vulnerable extension - not a core flaw.