Joomla Security Checklist 2026: 15 Steps to Lock Down Your Site

What you'll need	Details
Access	Joomla Super User login + FTP/SFTP or hosting file manager access
Applies to	Joomla 4.x (end of life — upgrade urgently), 5.x, 6.x
Server access	Ability to edit .htaccess or server-level config (ask your host if you're on shared hosting)
Time needed	30–60 minutes for a first full pass; 10 minutes for a monthly re-check

This checklist covers the 15 checks that matter most for a Joomla site running in 2026, ordered by how much risk each one removes. It's written against the current stable releases — Joomla 6.1.2 and 5.4.7, both released 7 July 2026 as security & bugfix updates — and references the specific vulnerabilities patched this year so you can see exactly why each step matters, not just take it on faith.

🖼️ [ẢNH CẦN CHỤP — HERO] Ảnh minh họa tổng quan: Joomla admin dashboard với icon khóa/shield overlay, thể hiện chủ đề "bảo mật site".

1. Update Joomla Core to the Latest Patched Release

Joomla 4 reached end of life on 14 October 2025 and no longer receives security patches — if you're still on Joomla 4, upgrading is not optional. For Joomla 5, the current secure version is 5.4.7; for Joomla 6, it's 6.1.2. Both were released on 7 July 2026 and fix three moderate-severity XSS issues (CVE-2026-48951, CVE-2026-48952, CVE-2026-48953) in modal return layouts, the com_installer update list view, and the generic image output layout.

Just as important: the 26 May 2026 release (5.4.6 / 6.1.1) fixed two critical privilege-escalation flaws — CVE-2026-48898 and CVE-2026-48904 — caused by improper access checks in the com_users batch task and group-editing webservice endpoint. Both affected every Joomla CMS version from 4.0.0 through 6.1.0. If your site hasn't been updated since before late May 2026, treat this as urgent.

2. Patch Every Extension, Template, and Plugin — Not Just Core

In 2026, the highest-impact Joomla vulnerabilities have come from third-party extensions, not the CMS core. Two examples worth knowing about:

• JCE (Joomla Content Editor) — CVE-2026-48907, CVSS 10.0. Versions 1.0.0 through 2.9.99.4 let an unauthenticated attacker create a fake editor profile and upload PHP code, leading to remote code execution. CISA added it to its Known Exploited Vulnerabilities catalog after confirming active exploitation. Fixed in JCE 2.9.99.5, hardened further in 2.9.99.6.
• PageBuilder CK — CVE-2026-56290, CVSS 10.0. An AJAX endpoint checked CSRF tokens but never verified the requester was an administrator, letting attackers grab a token from the public login page and upload backdoors. Fixed in 3.6.0 (27 June 2026); Joomla 3 and 4 users need the back-ported 3.1.1 / 3.4.10 releases respectively.

Both were rated maximum severity and both were exploited before most site owners even knew a patch existed. Check every installed extension against its changelog monthly, and remove anything you're not actively using — an inactive extension is still an attack surface.

3. Enable Two-Factor Authentication for Every Admin Account

Joomla has supported built-in Two-Factor Authentication since version 3.2, released in 2013 — but it still isn't enabled by default. Weak or reused passwords remain one of the most common entry points for attackers, and 2FA is the single cheapest control against it.

To enable it: go to Users → Manage, open the user profile, and turn on Two-Factor Authentication under the relevant tab. Do this for every account with Administrator or Super User access — not just your own.

🖼️ [ẢNH CẦN CHỤP] Screenshot Joomla admin: Users → Manage → Edit profile → tab Two-Factor Authentication, khoanh đỏ vùng chọn "Google Authenticator" hoặc "Yubikey".

4. Enforce Least-Privilege Access Control Levels (ACL)

The two 2026 privilege-escalation bugs (CVE-2026-48898, CVE-2026-48904) both revolved around unauthorized changes to user group membership. That makes ACL hygiene a direct mitigation, not just theory: audit who holds Super User access, remove anyone who doesn't strictly need it, and use Joomla's ACL system to give editors and authors only the permissions their role requires.

5. Change the Default Admin Login Path and Rate-Limit Login Attempts

The default /administrator URL is the first thing any automated scanner checks. Joomla 4/5/6 include login rate-limiting to slow brute-force attempts, but combining that with a non-default admin path and IP allow-listing (if you log in from a fixed location) closes the door further. A security extension such as Akeeba Admin Tools can rename the admin path without editing core files directly.

🖼️ [ẢNH CẦN CHỤP] Screenshot Admin Tools (hoặc extension tương đương): panel "Secret word / Rename administrator directory", khoanh đỏ ô nhập đường dẫn admin mới.

6. Set Correct File and Folder Permissions

The Joomla documentation's recommended permission set is consistent across the project's own manual and community references:

Item	Permission	Meaning
Folders	755	Owner can read/write/execute; everyone else can only read/execute
Files	644	Owner can read/write; everyone else can only read
configuration.php	444	Read-only for everyone, including the owner — Joomla temporarily switches it to 644 when you save Global Configuration, then back to 444 automatically

7. Force HTTPS Across the Entire Site

Every page — admin and front end — should be served over HTTPS. Without it, login credentials and session cookies travel in clear text and can be intercepted by anyone on the same network path. In Joomla, this is set under System → Global Configuration → Server → Force HTTPS → Entire Site.

🖼️ [ẢNH CẦN CHỤP] Screenshot Joomla admin: System → Global Configuration → tab Server, khoanh đỏ option "Force HTTPS" đang set "Entire Site".

8. Harden .htaccess and Add Security HTTP Headers

Joomla ships a default htaccess.txt that you rename to .htaccess — it includes rewrite rules that block common exploit patterns and enforce clean URLs. On top of that, add headers such as X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, and a Content-Security-Policy suited to your template, to reduce exposure to clickjacking and XSS at the browser level.

9. Install a Security Extension (Firewall + Malware Scanning)

Joomla's built-in protections cover the basics; a dedicated security extension adds a web application firewall, IP blocking, and file-integrity monitoring on top. Commonly used options in the Joomla ecosystem include Akeeba Admin Tools (firewall, IP blocking, .htaccess hardening) and RSFirewall (real-time protection and scanning).

10. Set Up Automated Backups — and Actually Test the Restore

A backup you've never restored from is a backup you don't actually have. Use an automated backup solution (Akeeba Backup is a common choice for Joomla) on a regular schedule, store copies off-server, and periodically run a real restore to a staging environment to confirm the backup is usable.

11. Subscribe to Joomla Security Announcements

The Joomla Security Strike Team (JSST) publishes every advisory through the official Security Centre, and you can subscribe to feeds.joomla.org/JoomlaSecurityNews to get notified the moment a core vulnerability is disclosed. Do the same for any major extension you run — the JCE and PageBuilder CK incidents above both had public vendor advisories before CISA got involved.

12. Run Regular Malware and File-Integrity Scans

Weekly scans catch a compromise early instead of months later. Options include a security extension's built-in scanner, or an external check like Sucuri SiteCheck against your live front end.

13. Restrict Direct Access to Sensitive Files and Folders

Beyond configuration.php, make sure folders like /logs, /tmp, and any folder that shouldn't be browsable are blocked from direct web access — either via .htaccess rules or your web server config.

14. Disable Web Services / API Endpoints You Don't Use

CVE-2026-48904 specifically abused the com_users webservice group-editing endpoint via Joomla's REST API. If you don't actively use the Joomla Web Services – Users plugin or the wider REST API, disable it. Fewer exposed endpoints means fewer places a future vulnerability can be exploited from.

15. Review User Accounts on a Recurring Schedule

Remove accounts that are no longer active, downgrade access for anyone who no longer needs Administrator or Super User rights, and rotate credentials for any account that may have had elevated access during a known vulnerability window (such as the May 2026 com_users incident above).

❓ Frequently Asked Questions

Is Joomla still safe to use in 2026?

Yes, when kept patched. Joomla continues to receive regular security releases — three in 2026 alone by July — and most serious incidents this year traced back to unpatched third-party extensions like JCE and PageBuilder CK, not core neglect.

How often should I update Joomla core and extensions?

Check weekly. Apply security releases immediately, especially anything tagged critical or added to CISA's Known Exploited Vulnerabilities catalog — the JCE flaw went from patch to active exploitation to a federal patch deadline within about two weeks.

What permissions should configuration.php have?

444 (read-only for everyone). Joomla briefly switches it to 644 when you save Global Configuration changes, then reverts it automatically. Never leave it at 777.

Do I still need a security extension if I update regularly?

Updates close known vulnerabilities; a firewall and scanner catch attacks between disclosure and patching, plus generic threats like brute force and malware uploads that aren't tied to a specific CVE.

Is Two-Factor Authentication mandatory in Joomla?

It's built in since Joomla 3.2 but not enabled by default. It's not enforced automatically — you have to turn it on per user under Users → Manage, and you should do this for every admin-level account.

What's the first thing to do if my Joomla site gets hacked?

Take the site offline or into maintenance mode, restore from a known-clean backup, then patch whatever was exploited before bringing it back — updating alone does not remove a backdoor that's already been planted.

🧯 Common Mistakes to Avoid

• Updating core but ignoring extensions. The two most severe 2026 Joomla incidents (JCE, PageBuilder CK) were both extension flaws, not core bugs.
• Setting 777 permissions to make an error go away. This trades a minor inconvenience for a real attack surface.
• Never testing a backup restore. An unverified backup is a false sense of security.
• Leaving the default /administrator path with no rate-limiting or IP restriction. It's the first thing every scanner checks.
• Enabling 2FA only for your own account. Any admin-level account without it is a gap.
• Assuming "updating" fixes a site that's already compromised. Patching closes the entry point; it doesn't remove a backdoor already planted.