Password in plain text in Scheduled Backups

Hello,

I’ve spotted a security issue with Virtualmin’s Scheduled Backups.

In my case, I have a dedicated server and store my backups on the FTP service provided by my data centre (off-site FTP + cold storage).
Occasionally, this service crashes for one reason or another, most often when deleting old backups.
There isn’t much you can do about this; their backup servers have never been particularly stable.

However, there is a problem. When a login or password attempt fails, the FTP password is shown in plain text in the email report!

40 virtual servers backed up successfully
9 Virtualmin system configurations backed up successfully
Deleting backups from /virtualmin on FTP server sub.domain.tld matching .-.-.* older than 18 days ..
Deleting FTP file /virtualmin/27-06-2026, which is 21 days old ..
.. FTP deletion failed : PASS xxx failed : bad login

.. found 4 backups, but none were old enough

Where xxx is the plaintext password.

Emails aren’t exactly the most secure form of communication; putting a password in plain text might not be the best idea, would it?
Is there a way to disable this whilst still keeping the reports?

Alternatively, my FTP backup service offers auto-login, with authentication based on IP address and MAC address (username = auto and an empty password). On the one hand, we no longer send the password, so it won’t appear in the reports; but on the other hand, is there a possibility that the addresses could be spoofed? What do you think?

PS: A few years ago, the password wasn’t written in plain text:
Uploading archive to FTP server sub.domain.tld ..
.. upload failed! PASS ***** failed : bad login

SYSTEM INFORMATION
OS type and version Debian 11
Webmin version 2.651
Virtualmin version 8.1.0 GPL

Hello,

Thanks for the heads-up!

This is indeed a bug. Could you please apply the following patch and let me know if it fixes the issue for you?

webmin patch https://github.com/virtualmin/virtualmin-gpl/commit/f6199fe

I’ve applied the patch, Thank you !

For the test, I wasn’t able to force the backup server to bug; however, I tried changing the password and then logging in via the schedule, and the password was masked.

.. failed to list FTP directory : PASS ***** failed : Bad credentials
.. failed to list FTP directory : PASS ***** failed : No such login

It’s not ‘bad login’, but I suppose it uses the same mechanism?

Yeah, that’s all right now! Thanks again for reporting this!