A patched Joomla core is a sound base; the settings that matter most are a supported branch, well-maintained third party extensions, a closed or restricted Web Services API and strongly protected Super User accounts. Joomla publishes security fixes through the Joomla Security Centre, and applying them promptly is the first control. This guide covers how Joomla users, groups and the access control list work, protecting Super Users with multi-factor authentication, Web Services API tokens and other integration credentials, Action Logs and detection, and a hardening baseline tied to the official support dates. It is for site owners, Joomla developers and web security teams. Facts come from joomla.org documentation, the Joomla Security Centre and the Vulnerable Extensions List, checked on 8 November 2026; confirm details for your version.
This is an independent guide from NHI Mgmt Group, based on Joomla's public documentation as of November 2026. It is not sponsored or reviewed by Joomla. Product features change, so confirm settings against Joomla's current documentation.
Key takeaways
- Joomla 5 is in security only support. The Joomla roadmap lists regular bugfix support for 5.x ending on 13 October 2026 and security support ending on 12 October 2027; 6.x is current (6.2.0) and supported until October 2029.
- Patch every core security release. On 25 September 2026 Joomla 5.4.9 and 6.1.4 fixed eight core issues, including an MFA bypass through remember me cookies and SSRF in core extensions.
- Close the Web Services API unless you use it. Disable the API authentication plugins you do not need and keep the core on a current release.
- Extensions are the main attack surface. Check every extension against the Vulnerable Extensions List, remove anything unused, and patch the rest on the day fixes ship.
- Enforce MFA for Super Users and Administrators. Core MFA supports authenticator codes, WebAuthn and YubiKey, and can be required per user group.
How identity and access work in Joomla
Joomla stores accounts in its own users table and authorises through user groups and access levels. Groups are hierarchical and inherit from their parent; a default install includes front end groups such as Registered, Author, Editor and Publisher and back end groups such as Manager, Administrator and Super Users, all descending from Public. Permissions (actions such as Site Login, Admin Login, Create, Delete, Edit, Edit State, Configure ACL and Options) are set per group in Global Configuration and can be overridden per component, category and article. Viewing access is controlled separately by access levels (Public, Registered, Special and custom levels). For CMS security generally, see the Small Business Website Security Guide; this page stays on Joomla.
| Identity | What it is | Security notes |
|---|---|---|
| Super Users group | Bypasses all permission checks, including Global Configuration and extension installation | Keep to two or three named people; MFA required; no shared accounts |
| Administrator group | Back end access with broad component rights | Check it cannot change Global Configuration or install extensions unless intended |
| Manager group | Back end content management | Typical home for content staff who need the administrator interface |
| Registered and front end groups | Site visitors who create accounts | Disable registration if not needed; review what Registered can submit |
| API users | Accounts used with Joomla API tokens | The core API documentation states the default API application is planned to require Super User accounts, so every token is privileged |
Login protection in core
- Multi-factor authentication: core MFA plugins are Verification Code (authenticator apps and password managers), YubiKey, Web Authentication (device based, often biometrics), and Authentication Code by Email (six digit codes valid for two minutes by default). A Fixed Code plugin exists for testing only, is disabled by default, and must never be enabled in production.
- Enforcement: in Users: Options, on the Multi-factor Authentication tab, administrators can require or disable MFA for each user group. Require it for Super Users, Administrator and Manager at minimum.
- Backup codes: adding an MFA method makes backup codes available on the user's profile; make sure administrators generate and store them.
- Passwordless: the System - WebAuthn Passwordless Login plugin adds a passkey style login button to the login form.
- Keep MFA current: apply Joomla security updates promptly, since they include fixes to authentication features. NHI Mgmt Group recommends disabling the remember me feature for administrators.
Admin roles and privileged access
The administrator interface (/administrator) is the main privileged surface. Anyone who can install extensions or edit templates can run PHP on the server.
| Permission or capability | Why it is privileged |
|---|---|
| Super User (core.admin) | Complete control of the site, including ACL and all extensions |
| Configure ACL and Options | Can grant itself or others new rights |
| Extension installation (com_installer) | Installing a package uploads and runs arbitrary PHP |
| Template editing (com_templates) | Template files are PHP; edit rights equal code execution |
| User management (com_users) | Can reset passwords or add users to Super Users |
| Global Configuration | Database settings, mail, logging paths, session and server options |
| Workflow stage changes | Review who can move items between workflow stages and publish |
- Separate daily and admin accounts: editors work in Manager or front end groups; Super User accounts are used only for configuration and updates.
- Change default names: the joomla.org Security Checklist advises changing the default administrator username, because the username and password are all an attacker needs.
- Restrict the administrator path: limit
/administratorby IP or VPN at the web server or WAF where your team works from known networks; the checklist recommends .htaccess password protection only as an extra layer on top of SSL. - Server access is admin access: SFTP, SSH, hosting control panels and database credentials all bypass Joomla's ACL. See the Hosting control panels security guide.
Integrations, API tokens and service accounts
Joomla 4 and later expose a Web Services API under /api/index.php/v1 for content, users, configuration and more. Every endpoint requires authentication unless marked public, and authentication is provided by plugins. See the API Key Management Guide.
| Credential | Plugins involved | Hardening |
|---|---|---|
| Joomla API token (Bearer) | API Authentication - Web Services Joomla Token, and User - Joomla API Token | Joomla documents this as the more secure option. Issue to a dedicated account, store in a secrets manager, revoke when the integration ends |
| Basic authentication | API Authentication - Web Services Basic Auth | Sends a username and password on every request; keep the plugin disabled unless there is no alternative |
| Database credentials | configuration.php | Dedicated database user with rights on the Joomla schema only; file not readable by other hosting users |
| Mail (SMTP) and third party API keys | Global Configuration and extension settings | Use scoped keys, record an owner, rotate after any compromise |
| Update and download keys for commercial extensions | Update Sites | Treat as secrets; remove when the subscription ends |
Security updates and patching
Joomla publishes security announcements for core on the Joomla Security Centre; apply security updates promptly. NHI Mgmt Group recommends these practical steps for the Web Services API:
- Disable what you do not use: if nothing calls the API, disable the API authentication plugins and block
/api/at the web server or WAF. - Restrict callers: where the API is needed, allow it only from known integration hosts.
- Rotate after exposure: a patch closes the hole but does not invalidate credentials already read. See the Secrets Management Guide.
Logging and detection
Joomla's User Actions Log (com_actionlogs) records back end and user actions such as logins, content changes, user changes and extension installs, stored in the database. Ship web server logs and, where possible, action log exports to a SIEM so that evidence survives a compromise. The joomla.org checklist also advises moving the log folder (by default administrator/logs in 3.6 and later) somewhere browsers cannot reach, or protecting it.
| Signal | Source | What it can indicate |
|---|---|---|
| New Super User or group change | User Actions Log | Privilege escalation or persistence (T1078.003) |
| Extension installed or template file edited | User Actions Log | Code planted through the admin interface (T1505.003) |
Requests to /api/index.php/v1/ from unknown sources | Web server or WAF logs | Probing of webservice endpoints (T1190) |
Bursts of failed logins on /administrator | Web server logs, Action Logs | Password guessing (T1110.003) |
| Unexpected PHP files in images, media or tmp folders | File integrity monitoring | Web shells after an extension upload flaw |
| Outbound requests from the web server to internal addresses | Network logs | Possible server-side request forgery |
For web shell indicators and clean up, see PHP web shells and the File Integrity Monitoring Guide.
Metrics
- Days from a Joomla core security release to production: target under 3 for High severity.
- Installed extensions on the VEL Vulnerable list: target zero; Resolved entries updated: 100 percent.
- Super User and Administrator accounts with MFA: target 100 percent.
- Number of Super Users: kept to a documented small number and reviewed quarterly.
- API authentication plugins enabled without a documented integration: target zero.
Hardening baseline
Versions and patching
As listed on the Joomla roadmap on 8 November 2026, the current release is 6.2.0, with regular bugfix support for 6.x until 17 October 2028 and security support until 16 October 2029. Joomla 5.4.10 is the current 5.x release; its bugfix support ended on 13 October 2026 and security only support runs to 12 October 2027. The roadmap no longer lists Joomla 3 or 4, so treat them as unsupported and migrate. Subscribe to Joomla Security Announcements and watch the Security Centre. See the Patch Management Guide.
Extensions
The Vulnerable Extensions List (VEL) on the Joomla Extensions Directory has a Vulnerable (Live) list, where no patch is available and uninstalling is recommended, and a Resolved list, where updating to the patched version is advised. The VEL team does not test reports and the list may not be complete, so treat it as a floor, not a guarantee. Keep every extension updated and remove any that are no longer maintained.
- Install from trusted sources only, prefer open source code over encrypted code, and test on a staging site first, as the joomla.org checklist advises.
- Remove, do not just disable: uninstall unused extensions and delete leftover files, because files left on the server can still be requested directly.
- Keep an inventory: extension name, version, publisher, update source and owner, reviewed monthly against the VEL and each publisher's update notes.
Configuration baseline
| Area | Setting |
|---|---|
| Transport | Use SSL across the site (Global Configuration Force HTTPS set to entire site) and HSTS at the web server |
| Installation leftovers | Delete the installation directory, archive files and anything left in tmp |
| File permissions | Directories 755 and files 644 as the checklist advises, with configuration.php tighter (for example 444 or 440, a common hosting practice rather than a checklist value) and owned by the site user |
| Writable and upload paths | Keep caches, logs and uploads outside public_html where possible; set PHP open_basedir |
| Host header | On non vhost servers set live_site in configuration.php to prevent host header injection |
| Web server rules | Enable the shipped htaccess.txt as .htaccess (Apache) or equivalent rules; block PHP execution in images and media |
| Registration | Allow User Registration off unless needed; administrator activation where open |
| Debug | Debug System and Error Reporting off in production |
| API | API authentication plugins disabled unless used; /api/ restricted |
| MFA | Required for all back end groups |
Rollout order
- Back up files and database, and confirm you can restore to staging.
- Upgrade to the current supported release on staging, test extensions, then production.
- Audit extensions against the VEL; remove unused ones.
- Lock down accounts: reduce Super Users, enforce MFA, change default usernames, review group permissions.
- Close the API or restrict it, then rotate database and integration secrets if the site ever ran an affected version.
- Apply the configuration baseline and file permissions, and test that uploads and updates still work. Roll back from the backup if an extension breaks.
- Turn on logging and monitoring and set alerts for the signals above.
Common misconfigurations
- Running an unsupported branch: Joomla 3 or 4 sites left in place because a template or extension blocks migration.
- Abandoned extensions: a page builder or form extension installed years ago, no longer updated, and now on the VEL.
- API left open by default: sites that never used Web Services but kept the authentication plugins on and
/api/reachable from the internet. - Too many Super Users: agencies, former staff and test accounts in the Super Users group without MFA.
- Writable code: the whole web root writable by the web server user, so an upload flaw becomes a persistent web shell.
- No rotation after a patch: applying a security update for the Web Services API but keeping the same database password that may already have been read.
Framework mapping
| Joomla control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | MITRE ATT&CK |
|---|---|---|---|
| Supported release and patching | SI-2, SA-22 | PR.PS-02 | T1190 |
| Extension inventory and removal | CM-7, CM-6 | PR.PS-01 | T1505.003 |
| MFA for back end groups | IA-2 | PR.AA-01 | T1110.003 |
| Group permissions and few Super Users | AC-6 | PR.AA-05 | T1078.003 |
| API tokens and secrets in configuration.php | IA-5 | PR.AA-01 | T1552.001 |
| Action Logs and SIEM | AU-2, AU-6 | DE.CM-01 | T1078 |
Practitioner checklist
- Move every site to a supported Joomla release and apply core security releases within days.
- Subscribe to Joomla Security Announcements and check the Security Centre after each release.
- Check all extensions against the VEL monthly; uninstall unused and abandoned ones.
- Require MFA for Super Users, Administrator and Manager groups, and keep Super Users to a small named set.
- Disable API authentication plugins unless an integration needs them; prefer Joomla API tokens over Basic auth.
- Rotate database and integration secrets if the site ever ran Joomla 4.0.0 to 4.2.7.
- Set file permissions, protect
configuration.php, delete installation leftovers and block PHP in upload folders. - Send web server logs and User Actions Log events to a SIEM, with alerts for new Super Users and extension installs.
Standards and references
- Joomla: Roadmap and support dates
- Joomla: Security Centre
- Joomla Documentation: Multi-factor Authentication
- Joomla Documentation: Joomla Core APIs
- Joomla Documentation: Security Checklist, Joomla! Setup
- Joomla Extensions Directory: About the Vulnerable Extensions List
Related NHI Mgmt Group resources: MFA Guide · Web Application Firewall Guide · CISA KEV Catalogue Guide · Vulnerability Management Guide