Joomla SQL Injection: How It Works, Real CVEs, and How to Prevent It

Joomla SQL injection is one of the oldest and most damaging ways an attacker takes over a Joomla site, and it is still live in 2026. A single unfiltered parameter can let an attacker read your database, dump password hashes, or forge an administrator session. Joomla core has been patched against several critical cases over the years, yet third-party extensions and unsupported branches keep the risk alive. This guide walks through how the attack works, the real CVEs that mattered, and exactly how you detect it and shut it down.

What is a Joomla SQL injection?

A SQL injection, or SQLi, is an attack where someone slips database commands into input that your application fails to sanitise, classified by MITRE as CWE-89 and listed under Injection in the OWASP Top 10. In a Joomla site, that input arrives through a URL parameter, a form field, or a Web Services API request that reaches a MySQL or MariaDB query without being escaped or bound to a placeholder. Because Joomla keeps users, sessions, configuration, and content in one database, an attacker who lands a working injection rarely stays contained. A successful UNION SELECT may let an attacker read rows from other tables that the Joomla database account is permitted to access, including the #__users table where password hashes live. That pivot, from one query to the whole database, is what makes SQLi dangerous rather than the query itself.

How does a Joomla SQL injection attack work?

An attacker looks for a parameter that changes a database query, then feeds it SQL syntax instead of a normal value. What comes back tells them which technique to use.

• Trigger an error-based injection. Force the database to throw an error that leaks table or column data straight into the HTTP response. This is the fastest technique when a site shows raw SQL errors.
• Extract data with a UNION-based injection. Append a UNION SELECT so the vulnerable query returns attacker-chosen columns from other tables, such as usernames and password hashes.
• Infer data with boolean-based blind injection. Ask the database true or false questions and read the answer from how the page changes, one character at a time, when no error or output is visible.
• Time the database with time-based blind injection. Inject a conditional delay and measure the response time to extract data even when the page never changes at all.

The best-known Joomla example is CVE-2017-8917. Attackers abused the list[fullordering] parameter in the com_fields component of Joomla 3.7.0; because the value flowed into an ORDER BY clause without being bound, an unauthenticated attacker could read arbitrary data from the database. Sucuri disclosed it, and automated scanners weaponised it within days. The lesson is not the payload, it is the pattern: one unbound parameter reaching a query is enough.

A worked example: from one parameter to admin access

To see why an unbound parameter rates as critical, follow how attackers turned Joomla’s 2015 content-history flaw into full control. The vulnerable endpoint accepted ordering input that flowed into the query unfiltered, so an unauthenticated attacker could append a UNION SELECT and read data the application’s database account was allowed to access. The prize sat in the session and user tables: pull an active administrator session token, replay it, and you are inside the backend with no password. Trustwave’s researchers demonstrated exactly that chain, and it was reported to reach roughly 2.8 million sites at the time. A separate flaw from the same period, CVE-2015-8562, was a PHP object-injection vulnerability in the HTTP User-Agent header that could lead directly to arbitrary PHP code execution; it was not part of the CVE-2015-7857 SQL-injection chain. Not every injection returns data so obligingly. When a page shows nothing, an attacker switches to blind techniques, reading one true-or-false answer at a time or timing deliberate delays. Worse, a second-order injection stores harmless-looking input that only fires when a later query uses it, which is the case a naive input filter is least likely to catch. The lesson for a defender is blunt: by the time you can watch the data leak, the attacker usually can too.

Notable Joomla SQL injection vulnerabilities

Joomla core has a strong track record of patching SQLi quickly through the Joomla Security Strike Team, and the advisories below are the cases that mattered. Two of them landed in 2025, which is the clearest sign that this class of flaw has not gone away.

Read the pattern across ten years. Core flaws get found, disclosed, and fixed fast, so a site on the latest release is rarely caught by a core SQLi for long. The long tail is elsewhere: unsupported branches that never receive the fix, and third-party extensions where no Security Strike Team reviews the code before release. This is the same dynamic behind the Joomla vs WordPress security debate, where the core is solid but the extension ecosystem carries the risk. None of it means the platform is unsafe by default; for the balanced view, see is Joomla secure.

What can an attacker do with a Joomla SQLi?

A single injection point is a foothold, and a capable attacker turns it into a full compromise quickly.

• Steal credentials. Dump the users table and crack or reuse the password hashes of your administrators.
• Forge an administrator session. Read or write session and token data to bypass authentication and land in the Joomla backend.
• Exfiltrate customer data. Pull personal or payment records, which turns a code flaw into a GDPR Article 32 and PCI DSS reporting problem.
• Plant a backdoor. Write a rogue Super User or use the database foothold to help drop a webshell, escalating toward remote code execution. If that has already happened, start with malware removal, not another scan.

SQL injection is one of the most serious Joomla security issues, but on a neglected site it is rarely the only one.

How do you check if your Joomla site is vulnerable?

You do not need to guess. Four checks tell you where you stand, from a two-minute version lookup to a full external scan.

• Confirm your core version. Open Joomla Update in the backend and compare the installed release against the latest supported version. An out-of-date or end-of-life core is the single strongest predictor of exposure.
• Inventory every extension. List each installed component, module, and plugin, then match versions against the community Vulnerable Extensions List and CVE records. Abandoned extensions are the ones that bite.
• Scan the running site. A Joomla vulnerability scanner runs DAST (Dynamic Application Security Testing, which tests your live site from the outside), maps detected versions to known SQLi advisories with their CVSS severity, and attaches HTTP evidence to what it can confirm without touching your database.
• Test staging with SQLMap. For developers, run SQLMap against a staging copy, never production, to probe custom code and extensions for injectable parameters before an attacker does.

How to prioritise a Joomla SQL injection finding

A scan of a busy Joomla site can return a long list, and treating every SQL injection finding as equally urgent wastes the little time a small team has. Rank them by five signals instead.

• Read the CVSS base score first. The Common Vulnerability Scoring System (CVSS) rates technical severity from 0 to 10, so a 9.8 unauthenticated injection outranks a 6.5 flaw that needs an admin login.
• Weigh the EPSS probability. The Exploit Prediction Scoring System from FIRST estimates the probability of exploitation activity in the wild over the next 30 days, adding an exploitation-likelihood signal that CVSS severity alone does not provide.
• Check the CISA KEV catalog. A place in the Known Exploited Vulnerabilities catalog means CISA has evidence of exploitation in the wild. U.S. Federal Civilian Executive Branch agencies have binding remediation due dates under BOD 22-01; other organisations commonly use KEV as a high-confidence prioritisation signal.
• Confirm the exposure. An unauthenticated injection in a public-facing component is a patch-tonight job; an authenticated-only flaw in a rarely used admin view can sit behind it.
• Note whether a public exploit exists. A finding with a working proof of concept or a Metasploit module is more urgent than a theoretical one, because it lowers the skill and effort an attacker needs to use it.

Run those signals together and the list sorts itself: an unauthenticated, KEV-listed injection with a high EPSS score is where tonight goes, while a low-severity, authenticated finding can wait for the next maintenance window.

How to prevent Joomla SQL injection

Prevention splits cleanly by who you are. Site owners control patching and configuration; developers control the code that builds queries. Both halves have to hold.

If you run or manage the site

Start with the control that closes most real SQLi: keep the Joomla core and every extension on their latest supported release, because that is how the advisories above get neutralised on your site. Remove extensions that are abandoned, unused, or already listed on the Vulnerable Extensions List, since an unpatched extension with no maintainer is the long tail attackers count on. Put a web application firewall or a security extension such as Akeeba Admin Tools or RSFirewall in front of the site to filter injection attempts, and enforce two-factor authentication and the other Joomla security features that ship in the core. Give the Joomla database account the least privilege it needs rather than full rights, and for the full walkthrough follow how to secure your Joomla website.

If you write Joomla extensions

Treat every value that reaches a query as hostile until you have handled it. Use prepared statements through the Joomla query builder and bind parameters, described in the manual on secure database queries, rather than concatenating raw input into SQL strings. Escape strings with $db->quote() and typecast numeric input with (int) or (float), because Joomla’s own secure coding guidelines warn that JInput filters input but is not SQL-aware. Escape output as well, which also blocks the stored Joomla XSS vulnerability that often rides alongside injection flaws. Finally, run SQLMap and static analysis against a staging build so an injectable parameter is caught in review, not in production.

What to do if you find a SQL injection on your Joomla site

Finding a live SQL injection is not a fire drill if you work the steps in order. Treat it as a potential breach until you have ruled one out.

1. Confirm and scope the finding. Reproduce it on a staging copy, identify the vulnerable component and version, and note whether it needs authentication.
2. Patch or pull the component. Apply the vendor fix, or uninstall the extension if it is abandoned, and move off any end-of-life core in the same window.
3. Assume exposure and rotate secrets. Change the database password, the secret in configuration.php, and every admin credential, since a working injection can read all of them.
4. Hunt for a foothold. Review the users table for Super Users you did not create, and read the access logs for the injection signature and whatever followed it.
5. Scan for malware. A database foothold is often used to plant files, so run a malware scan for backdoors and webshells before you trust the site again.
6. Re-scan to confirm. Prove the vulnerable version no longer responds, and keep the clean result as evidence.
7. Run a post-incident review. Ask how an unbound parameter reached production, then add the check that would have caught it.

SQL injection, PCI DSS, and GDPR

A Joomla SQL injection is rarely just an engineering problem; if you handle payments or personal data, it is a compliance one. Sites in PCI DSS scope must address injection risks through secure development and vulnerability-management controls; where PCI DSS Requirement 11.3.2 applies, external vulnerability scans by an Approved Scanning Vendor are required at least once every three months, so a known, unpatched SQLi can directly affect compliance. If the flaw exposes personal data, Article 32 of the GDPR requires appropriate technical and organisational measures, while Article 33 requires notification to the supervisory authority within 72 hours where feasible unless the personal-data breach is unlikely to result in a risk to individuals’ rights and freedoms. For a lean team, that is the part worth internalising: the cost of a SQL injection is not the afternoon it takes to patch, it is the customer data, the audit finding, and the disclosure letter that follow if you miss it. Scanning on a schedule turns that open-ended liability into a routine task, which is what auditors and regulators expect to see.

Common myths about Joomla SQL injection

A few stubborn beliefs keep Joomla sites exposed long after the owner thinks the risk is handled.

• Assuming a firewall makes you immune. A web application firewall blocks known payload patterns, but a blind or novel injection can slip past it, so a firewall buys time rather than removing the flaw.
• Trusting Joomla’s input filter to stop injection. JFilterInput reduces risk, yet it is not SQL-aware, and several advisories were filter bypasses rather than missing filters.
• Believing only ancient Joomla is affected. The 2025 core and framework advisories landed on current, supported branches, so a fully updated site still needs monitoring.
• Treating a disabled extension as harmless. An installed component can expose a reachable endpoint even when it is switched off in the menus, which is why an inventory beats an assumption.

Each myth shares a root: it treats security as a one-time setting rather than a standing property of a site that keeps changing.

Frequently asked questions

Run a scan to see which of these advisories apply to your exact Joomla stack, with HTTP evidence and a fix for each finding.