How to Change Joomla Credentials After a Security Incident
Contain the incident before rotating credentials
If compromise is still active, take the site offline or restrict access before making credential changes. Preserve relevant logs and evidence first. Joomla's security checklist recommends taking a compromised site offline, working with the host, checking administrator workstations for malware, and changing credentials as part of a broader cleanup rather than treating password rotation as the entire recovery.
Change hosting and server access credentials
Rotate the hosting control-panel account, SSH/SFTP or FTP credentials, deployment keys, and any other account that can modify the site. Use unique, strong credentials and revoke accounts or keys that are no longer required. If an attacker retained server-level access, changing only Joomla user passwords will not prevent the site from being modified again.
Rotate database credentials safely
Create or set a new database password using the hosting or database administration system, then update Joomla's database password in configuration.php so the application can reconnect. Test the site immediately after the change. Avoid exposing the new database secret in tickets, screenshots, shell history, or shared documents.
Reset Joomla privileged accounts
Review Users → Manage and identify every Administrator and Super User account. Reset passwords for legitimate privileged users and block or remove accounts that cannot be verified. Joomla's incident guidance specifically calls for changing Joomla Administrator and Super User credentials, and its recovery guidance emphasizes checking that privileged users are legitimate.
Rotate external service secrets
Change credentials and tokens Joomla or its extensions use for SMTP, payment gateways, storage, APIs, backup destinations, CDNs, webhooks, and other integrations when those secrets could have been exposed. A compromised configuration file, extension, administrator session, or server account may reveal secrets beyond the Joomla login itself.
Invalidate old access wherever possible
Revoke API tokens, app passwords, SSH keys, active sessions, and remembered devices where the relevant service supports it. Re-enroll authentication factors if their integrity is uncertain. Do not simply change a password while leaving an attacker-controlled token or key valid.
Verify the clean state after rotation
Credential rotation should happen alongside removal of malicious files, vulnerable extensions, unauthorized users, and persistence mechanisms. After cleanup, verify Joomla and Administrator access, review logs for continued suspicious requests, and store the new credentials in a trusted password manager. If suspicious activity continues, assume another access path remains.
Need More Help with Joomla?
Still having trouble? Open a support ticket with QuantaCade Support and we'll be happy to help where we can.
Support priority is given to QuantaCade products, services, and customers. However, we're also happy to assist fellow Joomla users with general Joomla questions and troubleshooting when possible.
QuantaCade is an independent Joomla extension developer and is not official Joomla support. Some issues involving third-party extensions, hosting environments, server configurations, or other systems outside our development control may be beyond what we're able to resolve.