FTP Credentials In Global Configuration

Joomla's FTP Layer went in Joomla 4, but old configuration.php files still hold plain text FTP credentials. Why that is a legacy risk worth checking for.
How common is this?
- 4.6% of the Joomla sites we have this data for fail this check. Platform: Joomla.
Measured across the sites we audit, on each site's most recent snapshot.
What this check and mySites.guru tool looks at on your site
This check reads your site’s configuration.php file and looks at the $ftp_user and $ftp_pass values. Both belong to the Joomla FTP Layer, a compatibility feature that let Joomla write files through an FTP connection instead of directly to disk. It existed in Joomla 3 and earlier, and it was removed completely in Joomla 4. If you’re running Joomla 4 or later, this setting no longer exists and there is nothing here to worry about.
The FTP Layer was built to work around a specific hosting problem: on some servers, the user account PHP runs as isn’t the same account that owns your site’s files, so Joomla’s own web process couldn’t reliably write to its own directories. Rather than fail outright when installing an extension or saving Global Configuration, Joomla would connect to the server over FTP using credentials you supplied, and let the FTP account do the writing instead. Joomla 4 removed the feature because it assumes correctly configured file ownership and permissions in the first place, which is what well-run hosting should provide anyway.
How a retired setting still leaks a live credential
If $ftp_user and $ftp_pass are still populated, one of two things is true: the site is still running Joomla 3, or it was upgraded to Joomla 4 or later in place and the old configuration.php was carried across without being cleaned up, leaving these two lines behind even though nothing reads them any more.
Either way, the underlying problem is the same, and it’s the reason this check exists in the first place. The FTP Layer stored your FTP username and password in configuration.php in plain text, with no encryption at all. configuration.php isn’t a page a browser can request directly, Joomla and most hosts stop that, but there’s more than one way it ends up readable anyway: a local file inclusion bug in a vulnerable extension, a full-site backup zip left sitting in a public folder, a .php.bak or editor swap file a developer forgot to delete, a misconfigured server that serves PHP source instead of executing it, or simply another compromised account on the same shared server reading across a permissions gap. None of those require the attacker to be particularly skilled, only patient.
On a lot of shared hosting setups, particularly cPanel, the FTP account and the main hosting account share the same credentials. Reading one PHP file then hands over not just FTP access but the whole account: cPanel login, file manager, every database on the account, email, the ability to delete the lot. A credential that looks like it only controls file transfer often controls everything.
Worked through end to end: a site was migrated from Joomla 3 to a newer major version some time ago. The migration copied the site’s files across, configuration.php included, and nobody went back through the old file afterwards to strip out settings the new version no longer reads. Joomla 4 and later simply ignore $ftp_user and $ftp_pass, so the site runs perfectly normally with them still sitting there. Months or years later, an unrelated vulnerability in a different extension gives an attacker the ability to read arbitrary files from the server. configuration.php is one of the first files anyone in that position checks, because it’s a known, predictable location holding database credentials by design, and on this site it also happens to be holding a working FTP password from a setting nobody knew was still readable. The FTP layer itself was never active on the current Joomla version. The leftover credential was.
Both values empty
On Joomla 4 and later, there’s nothing to check: the setting was removed with the FTP Layer itself. On Joomla 3, $ftp_user and $ftp_pass are both empty. There’s no functionality trade-off in clearing them: nothing on a well-configured server needs the FTP Layer permanently switched on, and Joomla writes to its own files directly by default whenever file ownership and permissions are set up correctly in the first place.
How to fix it
- Open
configuration.phpin a text editor, either over SFTP or through your host’s file manager. - Find the lines setting
$ftp_userand$ftp_pass, and clear their values, leaving them as empty strings rather than deleting the lines. - If you genuinely need the FTP Layer for a specific task, such as a folder-permission problem during an extension install, set the credentials, do that one task, then clear them again straight away.
- If your host requires the FTP Layer just for Joomla to write its own files day to day, treat that as a sign the hosting itself is misconfigured. Correctly configured PHP hosting lets Joomla write to its own directories directly, without needing an FTP round trip.
- If the site is still on Joomla 3, clearing these credentials is a small fix; the underlying problem is bigger. See Joomla 3 Is End Of Life for what running an unsupported major version means and what to do about it.
$ftp_user = '';
$ftp_pass = '';
What mySites.guru does about it
mySites.guru flags any connected site where $ftp_user or $ftp_pass is still populated, and links you straight to the evidence in configuration.php so you can confirm whether it’s a live Joomla 3 install or a leftover from an old upgrade before deciding what to do about it.
FTP Credentials In Global Configuration
mySites.guru checks every connected site for this automatically and flags it the moment it appears. These run twice a day on every connected site.