Support

Contact your host. That's not a malicious file. This is Kickstart. It is uploaded to the target site when using the Site Transfer Wizard where it is renamed with a .php extension so it can be executed.

It is saved with a .txt extension on your site so that it's not executable on your site. This is something that only needs to run on the target site when using the Site Transfer Wizard.

For what it's worth, this is how Akeeba Backup has been packaged for over 15 years. It's much safer than either of the alternatives. One alternative is to have it as a .php file. This is unsafe as it can be used in an attack chain; the only other vulnerability they need in any other extension on your site is an arbitrary file upload, like the ones fixed in mid-June 2026 in several Joomla extensions. The second alternative is downloading this file over the Internet which is unsafe for a multitude of reasons, least of which being the fact that a man-in-the-middle or cache poisoning attack would end up executing malicious code on your target site.

Basically, OVH is complaining that we are doing this the actually secure way instead of only pretending to care about security. Clearly, their scanner is broken.

This is correct, this file is only used for the Site Transfer Wizard.

Yes, you may of course share this with OVH. They should know so they can whitelist the file.

I am planning a workaround. For the workaround, I am going to obfuscate the file and its purpose just like an actual hacker would do with malicious files. I hate having to do that. It's the third time in 20 years I have to do exactly this kind of pointless change in my software to work around a broken scanner. I am already doing this in Admin Tools, where the malicious file signatures are obfuscated for the same reason. Insanity...

Also, fun fact, Joomla's extract.php file used by the Joomla Update component uses pretty much the same code as Kickstart. In fact, I contributed that file myself and it's just a cut down version of Kickstart which can only extract ZIP files, does not have a web interface, and has its classes slightly renamed to better follow Joomla's conventions. Clearly, they must've added an exception for that file. Why I am telling you this? If they complain they can't add an exception you can tell them that they obviously have done that for extract.php, written by the very same person and doing the very same thing, so any excuse is just that: an excuse, and a lame one at that.

You're welcome and thank you for bringing this to my attention. I am currently working on the workaround. I am not sure if I will have the time to make a release tomorrow. If not, I will be making a release on Monday.

Yes, I have seen some other people with the same problem. We get problems with malfunctioning scanners every couple of years. The solution is always the same: ironically, write our software to look more like malware, all obfuscated code and underhanded tricks to blind the scanners to the very legitimate things we do but which mistakenly trigger them. It's infuriating, really. The objective of a malware scanner should be diametrically opposite to what we observe.