Joomla SQL Injection: CVEs, Detection, and Prevention

How option=com_x Parameters Reach Joomla Components and Database Queries

Joomla commonly uses request routing that identifies a component through an option value such as option=com_content, option=com_users, or another com_x component name. Additional values determine views, tasks, filters, record IDs, sorting, pagination, and component-specific behavior.

Those parameters do not become vulnerabilities merely because they appear in a URL. The risk begins when the component later uses them while constructing SQL.

A simplified flow looks like this:

HTTP request → Joomla routing → component/controller → model state → DatabaseQuery → database

Historical Joomla vulnerabilities make this path concrete.

Trustwave’s 2015 research traced a vulnerable path into com_contenthistory. The affected model inherited behavior from JModelList, and request-controlled list state influenced a query built by the model. That flaw eventually allowed researchers to retrieve information from the database.

The lesson for developers is not to block option=com_x. It is to identify every place where a parameter, model state value, selected ID, filter, or ordering choice crosses into SQL.

Why ORDER BY and list[fullordering] Keep Appearing in Joomla SQLi

Ordering parameters are a recurring Joomla SQL injection risk because database placeholders are designed primarily for data values, while SQL identifiers and structural clauses such as column names and sort directions require different handling.

CVE-2017-8917 is one of the clearest examples. Sucuri traced the flaw to Joomla 3.7.0’s com_fields component. A value associated with list.fullordering could influence input passed to the query’s ORDER BY construction. The Joomla project fixed the issue in 3.7.1.

The pattern did not disappear after 2017.

CVE-2025-22207 involved improperly built order clauses in the com_scheduler backend task list. CVE-2026-21630 involved improperly built order clauses in the com_content articles Web Services endpoint. CVE-2026-352212 involved improperly validated order clauses in com_tags.

This is why developers should not take a user-supplied sort field and concatenate it directly into ORDER BY. Bind ordinary values. For structural SQL choices, use a strict allow-list that maps permitted request values to known column names or directions, then pass identifiers through Joomla’s identifier-handling methods where appropriate.

Can Joomla Web Services Endpoints Be Vulnerable to SQL Injection?

Yes. Joomla Web Services endpoints can contain SQL injection vulnerabilities when API-controlled parameters eventually influence unsafe query construction.

Joomla’s Web Services documentation uses a base such as /api/index.php/v1, with paths for resources including content articles. These requests eventually reach application code and database queries just as browser-facing routes do.

CVE-2026-21630 demonstrates the risk directly. Joomla reported that improperly built order clauses caused SQL injection in the com_content articles Web Services endpoint. The affected ranges were Joomla 4.0.0 through 5.4.3 and 6.0.0 through 6.0.3. Joomla fixed the issue in 5.4.4 and 6.0.4.

An API therefore should not be treated as a separate security universe. Filters, sorting parameters, identifiers, and search options still need the same SQL-safe handling as values received through normal site pages.

CVE-2015-7857: com_contenthistory and Administrator Session Hijacking

CVE-2015-7857 matters because the 2015 Joomla SQL injection was demonstrated as more than a theoretical database leak.

Joomla’s advisory says its core SQL injection issue affected versions 3.2.0 through 3.4.4 and was fixed in 3.4.5. The advisory associates CVE-2015-7297, CVE-2015-7857, and CVE-2015-7858 with that SQLi release.

Trustwave located vulnerable code in the administrator-side com_contenthistory model and showed how the SQLi could read database information. The vulnerable query was a SELECT path, so the original demonstration did not depend on arbitrary database writes. Instead, researchers targeted Joomla’s session data.

If an administrator had an active session, Trustwave showed that a session identifier could be extracted and replayed to access the administrator area. The active administrator session was a prerequisite for that specific takeover chain.

The often repeated “2.8 million sites” number also needs context. Trustwave said BuiltWith estimated that as many as 2.8 million websites used Joomla at the time. It did not claim that 2.8 million Joomla sites were successfully exploited or compromised by this vulnerability.

Why CVE-2015-8562 Is Not a Joomla SQL Injection CVE

CVE-2015-8562 should not be listed as another Joomla SQL injection vulnerability because Joomla classifies it as a remote code execution flaw.

Joomla said the issue affected CMS versions 1.5.0 through 3.4.5 and fixed it in 3.4.6. The vulnerable behavior involved browser information being stored in session data in a way that could lead to code execution.

Technical analysis of the vulnerability describes the mechanism as object injection related to a crafted User-Agent value. Trustwave documented attackers placing data in the User-Agent header and later causing Joomla to retrieve and process that stored value through PHP deserialization behavior.

That makes the distinction important for a Joomla SQLi article: CVE-2015-8562 is historically relevant to Joomla security and database-backed session handling, but it is not itself a SQL injection CVE.

CVE-2017-8917: com_fields and list[fullordering]

CVE-2017-8917 is a key Joomla SQL injection example because it shows why sort and ordering parameters deserve the same security attention as obvious form inputs.

The flaw affected Joomla 3.7.0 and was fixed in Joomla 3.7.1. Joomla credits Marc-Alexandre Montpas of Sucuri with reporting it.

Sucuri traced the vulnerable behavior to FieldsModelFields in com_fields. The model inherited from JModelList, and the researcher showed how the list.fullordering state could become attacker-controlled and eventually influence the query’s ordering logic.

That matters because developers sometimes think only search boxes, login fields, and raw text values are interesting SQLi inputs. A sort field can be just as dangerous when it changes an ORDER BY expression.

The safe pattern is not to bind an arbitrary column name as though it were an ordinary string value. Instead, map a limited set of accepted sort choices to known identifiers and reject anything else.

CVE-2020-10243 and CVE-2020-35613: Type Casting and Filtering Failures

CVE-2020-10243 and CVE-2020-35613 show two different ways apparently routine Joomla input handling can result in SQL injection.

For CVE-2020-10243, Joomla identified missing type casting in a variable used by the Featured Articles frontend menu type. The vulnerability affected Joomla 1.7.0 through 3.9.15 and was fixed in 3.9.16.

This is a useful reminder that a value expected to be numeric should actually be enforced as numeric before it reaches a query. A developer should not assume that an ID parameter contains an integer because the normal UI only sends integers.

CVE-2020-35613 affected Joomla 3.0.0 through 3.9.22 and was fixed in 3.9.23. Joomla attributed the SQL injection in the backend com_users list to an improper filter blacklist configuration.

The two CVEs make a broader point: generic input filtering is not a replacement for correct SQL construction. Data types, parameter binding, structural allow-lists, and database API usage each solve different parts of the problem.

CVE-2022-23797: SQL Injection Through Selected IDs

CVE-2022-23797 is important because it fills a gap between the better-known 2020 issues and later Joomla 4 and 5 vulnerabilities.

Joomla reported that inadequate filtering of selected IDs could result in SQL injection. The affected ranges were Joomla 3.0.0 through 3.10.6 and Joomla 4.0.0 through 4.1.0. Joomla fixed the issue in 3.10.7 and 4.1.1.

Selected IDs often arrive as arrays rather than single values. That does not make them inherently safe. If an application expects a collection of numeric identifiers, each value must still be treated according to its required type, or passed into database helpers designed to bind collections safely.

Current Joomla database documentation includes methods such as bindArray() and prepared-statement helpers for constructing value lists without manually concatenating raw request values into the SQL.

CVE-2025-22207 and CVE-2025-25226: Order Clauses and Database Identifiers

CVE-2025-22207 and CVE-2025-25226 are useful together because one affected Joomla CMS query construction while the other affected identifier handling in the Joomla Framework database package.

CVE-2025-22207 affected com_scheduler in Joomla 4.1.0 through 4.4.10 and 5.0.0 through 5.2.3. Joomla said improperly built order clauses in the backend task list caused SQL injection, and fixed the issue in 4.4.11 and 5.2.4.

CVE-2025-25226 affected the Framework Database package’s quoteNameStr method. Affected package ranges were 1.0.0 through 2.1.1 and 3.0.0 through 3.3.1, fixed in 2.2.0 and 3.4.0. Joomla also added an important qualification: the vulnerable protected method was not used by the original database classes, so the issue concerned derived classes that actually called it.

That distinction prevents the article from overstating exposure. A vulnerable library version does not always mean every application using the library has an exploitable path.

2026 Joomla SQL Injection CVEs: CVE-2026-21630, CVE-2026-35221 and CVE-2026-352212

The 2026 Joomla SQL injection advisories show that unsafe filter and order-clause construction remains relevant even in current Joomla branches.

CVE-2026-21630 affected the com_content articles Web Services endpoint. Joomla said improperly built order clauses caused the flaw. Versions 4.0.0 through 5.4.3 and 6.0.0 through 6.0.3 were affected, with fixes in 5.4.4 and 6.0.4.

CVE-2026-35221 involved authenticated blind SQL injection in com_finder. Joomla attributed it to improperly built filter clauses. Affected versions were 5.4.0 through 5.4.5 and 6.0.0 through 6.1.0, fixed in 5.4.6 and 6.1.1.

CVE-2026-352212 affected com_tags, where improperly validated order clauses could produce authenticated blind SQL injection. Joomla lists affected versions as 4.0.0 through 5.4.5 and 6.0.0 through 6.1.0, again fixed in 5.4.6 and 6.1.1.

The unusually long numeric suffix in CVE-2026-352212 is not a typo. Joomla’s Security Centre uses that exact identifier.

Taken together, these 2026 cases reinforce a pattern visible since CVE-2017-8917: values that determine SQL structure, particularly filtering and ordering, need dedicated controls rather than generic sanitization.

How the Vulnerable Extensions List and JSST Fit Into Joomla Security

The Joomla Security Strike Team and the Vulnerable Extensions List serve different but complementary roles.

The Joomla Security Strike Team, or JSST, oversees security issues affecting the Joomla project. Joomla’s security site describes the JSST as a group of developers and security specialists responsible for managing and improving security for Joomla. The Security Centre publishes resolved issues affecting Joomla CMS and Framework releases.

The Vulnerable Extensions List, or VEL, focuses on extension risk. Joomla’s Extensions Directory says its live list contains extensions for which a known vulnerability has no patch listed, while its resolved list covers extensions for which a patch is available. The VEL also warns that it is compiled from available reports and does not guarantee completeness or independent validation.

Site owners therefore need more than one check:

Core and Framework advisories tell you what Joomla itself has fixed. The VEL and extension vendors help you track third-party code. Your own inventory tells you which of those packages are actually installed.

Lifecycle matters too. Joomla 3 standard support ended in August 2023, and its extended LTS period ended in February 2025. Joomla documentation lists Joomla 4.4 security support ending in October 2025. As of September 2026, Joomla’s roadmap identifies 5.x and 6.x as supported release families.

Running an end-of-life branch changes the problem from “Which patch fixes this CVE?” to “How do we migrate onto software that still receives fixes?”

Use DatabaseQuery, bind(), and ParameterType for Data Values

Joomla’s current database documentation uses prepared statements and parameter binding for values rather than concatenating request values directly into SQL.

For example, a developer can build a condition using a placeholder such as :id, then bind an integer value using ParameterType::INTEGER. Joomla’s documentation explains that when a variable is bound to a query, the application does not need to manually quote or escape that bound value.

The important distinction is that placeholders represent data values.

A user ID, username, article ID, search term, status value, or similar piece of data usually belongs in a bound parameter.

Type information matters as well. Joomla supports ParameterType values so the query can distinguish an integer from a string. For numeric IDs, explicitly enforcing an integer type reduces ambiguity and prevents a string containing unexpected SQL syntax from being treated as the intended ID.

For collections, Joomla also documents bindArray() and helpers such as whereIn(), which avoid manually constructing a comma-separated list from uncontrolled values.

Use quoteName() for Identifiers, quote() Carefully for Values, and Cast Numeric IDs

quoteName(), quote(), parameter binding, and integer casting solve different problems, so they should not be treated as interchangeable “sanitization” functions.

quoteName() is designed for database identifiers such as table and column names. Joomla’s own examples use it when specifying fields, tables, joins, and ordering expressions.

quote() applies database-appropriate quoting to values, but modern code should prefer parameter binding for ordinary untrusted values whenever the query supports it. Prepared statements make the boundary between SQL instructions and application data much clearer.

Integer casting is valuable when the application truly expects an integer. CVE-2020-10243 is a Joomla example where lack of type casting contributed to SQL injection.

Structural choices require another strategy. You cannot safely assume that binding a value will turn arbitrary user text into a valid column name or ASC/DESC instruction. Sort fields and directions should come from an explicit allow-list.

For example, if the UI accepts title, date, or id as sort choices, translate those values to known application-controlled identifiers. Reject anything outside that set.

Joomla input filters still have a role, but they should not be treated as an SQL security boundary. A filter designed to clean HTML or normalize request values does not replace correct query-level data handling.

Vulnerable vs Fixed Joomla PHP Query Example

The safer Joomla pattern keeps request-controlled values out of the SQL string itself and binds them separately with the expected type.

Consider an extension that receives an article ID.

A risky pattern is:

use Joomla\CMS\Factory;

$db = Factory::getContainer()->get(
    \Joomla\Database\DatabaseInterface::class
);

$input = Factory::getApplication()->input;
$id = $input->get('id');

$query = $db->createQuery()
    ->select('*')
    ->from($db->quoteName('#__content'))
    ->where('id = ' . $id);

$db->setQuery($query);
$article = $db->loadObject();

The problem is not the query builder itself. The problem is that $id becomes part of the SQL text through string concatenation.

A safer approach separates the value:

use Joomla\CMS\Factory;
use Joomla\Database\ParameterType;

$db = Factory::getContainer()->get(
    \Joomla\Database\DatabaseInterface::class
);

$input = Factory::getApplication()->input;
$id = (int) $input->getInt('id');

$query = $db->createQuery()
    ->select('*')
    ->from($db->quoteName('#__content'))
    ->where($db->quoteName('id') . ' = :id')
    ->bind(':id', $id, ParameterType::INTEGER);

$db->setQuery($query);
$article = $db->loadObject();

The improved example applies two controls with different purposes. The application enforces the value as an integer, then passes it to the query as a bound integer parameter. The column name is application-controlled and handled as an identifier with quoteName().

Joomla’s database documentation follows this same prepared-statement model and demonstrates bind() with ParameterType::INTEGER.

The same principle applies beyond IDs. Bind text values, dates, booleans, and other data with appropriate types. For structural SQL such as permitted sort columns, choose from application-controlled identifiers rather than accepting raw SQL fragments from the request.

Check Core, Extension, and Framework Versions Against Security Advisories

Start with exact versions because known Joomla SQL injection CVEs usually have precise affected and fixed ranges.

A Joomla 5 site, for example, should not be treated as “safe” merely because the major version is supported. CVE-2026-21630 affected part of the 5.x line through 5.4.3, while CVE-2026-35221 and CVE-2026-352212 affected later 5.4 releases through 5.4.5.

The same principle applies to extensions.

Record each installed component, plugin, module, page builder, template framework, and supporting package. Compare versions against Joomla’s Vulnerable Extensions List, vendor advisories, and CVE records. Remove software that is abandoned or no longer needed.

Custom extensions require another layer because no public CVE database can describe a private query flaw that has never been disclosed.

Review custom code for values flowing from request input into calls such as where(), order(), having(), raw SQL fragments, selected-ID arrays, search expressions, or manually assembled IN clauses.

Understand What an External Joomla Scan Can and Cannot Confirm

An external Joomla scan can identify externally observable risks and match detectable software versions to known vulnerabilities, but it cannot prove that every custom query path is free from SQL injection.

ScanTitan’s Joomla vulnerability scanner uses non-destructive external checks and known-version detection. It does not send working SQL injection exploit payloads to a site simply to prove exploitation.

That distinction matters.

Version-based detection can tell you that a detected Joomla or extension version falls inside the affected range of a known CVE. External configuration checks can identify additional exposed conditions. Neither result should be described as source-code review of a custom extension.

If you need to validate a suspected custom SQLi path, use a controlled testing environment and an authorized application-security process. ScanTitan’s guide to testing for SQL injection vulnerabilities explains the broader testing process.

For an SMB team, the practical workflow is to combine version awareness, external detection, extension inventory, and code review where custom development exists.

For Joomla Site Owners and Administrators

Site owners prevent known Joomla SQL injection primarily by keeping the CMS and extensions on supported, patched releases and by removing code that no longer receives security maintenance.

1. Patch supported versions: Apply Joomla core and extension security updates promptly after testing them in staging. A fixed CVE remains relevant to your site until the affected version is actually replaced.
2. Remove abandoned extensions: Uninstall extensions that are no longer required or supported. Do not assume that disabling a component eliminates every reachable file or integration path.
3. Review the VEL: Compare installed extensions with Joomla’s live and resolved Vulnerable Extensions List, while remembering Joomla explicitly warns that the list is not guaranteed to contain every vulnerability.
4. Migrate end-of-life branches: Treat Joomla 3 and Joomla 4 migration as a security requirement rather than a cosmetic upgrade. Unsupported branches no longer receive normal security fixes from the Joomla project.
5. Limit database privileges: Give the application’s database account only the permissions the site actually requires. SQL injection impact depends partly on what the compromised query and database account are able to access or modify.
6. Use a WAF as a secondary control: A web application firewall can block some recognizable SQLi traffic, but it does not repair unsafe query construction. MITRE notes that application firewalls can reduce exposure while still missing vectors or being bypassed.
7. Harden the rest of Joomla: SQLi prevention belongs inside a larger maintenance process that includes account security, access control, HTTPS, logging, backups, and extension review. ScanTitan’s Joomla hardening guide covers that broader workflow, while the Joomla security features guide explains the controls available in the CMS.

If a suspected SQL injection has already led to unauthorized modification, new administrator accounts, malicious files, or other evidence of compromise, patching the vulnerable component is only the first step. The site should also be investigated for persistence and contamination. ScanTitan’s website malware removal service covers that recovery scenario.

For Joomla Extension Developers

Extension developers prevent Joomla SQL injection by designing query construction so request-controlled data never becomes trusted SQL syntax by accident.

1. Bind ordinary values: Use placeholders and bind() for user-controlled values rather than concatenating those values into where(), set(), or other SQL fragments.
2. Declare expected types: Use ParameterType and appropriate input methods for integers, strings, booleans, and other known value types. Type enforcement is especially important for IDs.
3. Quote identifiers correctly: Use quoteName() for application-controlled table and column names rather than manually adding database quoting characters.
4. Allow-list structural choices: Map user-facing sort and filter options to known column names, operators, and sort directions. Never treat arbitrary request text as a trusted ORDER BY expression.
5. Bind arrays safely: Use helpers such as bindArray() or whereIn() for collections instead of joining unchecked request values into an SQL list.
6. Review inherited model state: Values set by parent classes such as list-model behavior can still originate from request parameters. CVE-2017-8917 is a useful reminder to trace state all the way to the query.
7. Test API routes too: Apply the same query-review rules to /api/index.php/v1 endpoints and other Web Services code. An API parameter is not safer merely because it arrives as JSON or through an authenticated token.
8. Separate HTML filtering from SQL safety: Use Joomla input and output filtering for the problems those tools are designed to solve, but keep SQL safety at the database-query boundary.

A security review should follow data flow from request to query, not simply search the codebase for a few dangerous function names.