Support

.php.png is not an executable extension (it would be delivered as-is, not executing any code). It would only execute if another .php file includes it.

There is no such code on your site, which means that the attacker would have to upload and execute this kind of code.

However, since the protections in Admin Tools prevent the attacker from uploading .php files outside the media folder, and the files in the media folder are not executable (because of .htaccess Maker's Frontend Protection feature), the attacker would be unable to upload and execute code which would allow the .php.png files to execute.

Therefore, these files are inert.

Now, you may wonder, why the heck would an attacker try to upload .php.png if it's not going to work. The reason is technical and does not concern you using the Apache (or Lightspeed) web server, but I can tell you. A very long time ago, it was common for NginX servers to be misconfigured in a way that any file could be executed as PHP code if someone appended something like /foo.php or ?foo.php to the URL. For example, trying to access https://www.example.com/images/malicious.png?foo.php would cause the images/malicious.png file to be executed as if it were a PHP file. If the file contained executable PHP code it would hack your site. That's why we used to have UploadShield in Admin Tools and later (since Joomla 3.4) contributed it to Joomla itself. However, this is no longer a concern. NginX has already documented this pitfall so nobody does that mistake anymore.

Apache and Lightspeed —the only two servers which support .htacecss files— never had that problem because processing by PHP is always handled based on the actual file's MIME type or extension, not on the URL contents.

Moreover, if someone does use Admin Tools on NginX they will very likely be using our NginX Conf Maker. The way the generated NginX configuration file works, it does not allow any .php files to be accessed (let alone run), at all — with the exception of Joomla's index.php files in the site root, administrator and cli directories, as well as Joomla's administrator/components/com_joomlaupdate/extract.php. You have to explicitly state which .php files or folders containing .php file you want to allow to execute, and this only executes real files with a a.php extension. Therefore, even if you are using NginX, Admin Tools protects you.

If you want the PHP File Change Scanner to also report .php.png files, yes, you need to add that extension in its configuration.

As a general rule, I would say that you should be looking for files with the pattern .php. in their name and delete them. This pattern is not something legitimate software will ever use for its files.

Sorry for getting very technical, but I can't see a less technical way to explain this. This kind of vulnerability is something I had seen a lot between 2005 and 2009 when I first wrote my Master .htaccess which later (September 2010) grew into Admin Tools' .htaccess Maker and sprawled into the triumvirate of .htaccess Maker, NginX Conf Maker, and Web.Config Maker. I've been working on finding ways sites can be hacked and work around them all these years. This AcyMailing hack at least proves that my paranoia has been more than warranted :)

Sigh… I hate it when people who do not understand the first thing about something spread misinformation about it with an air of authority. I strongly believe in Socrates' words "for what I don't know know, I don't think I know it either". In other words, if you don't fully understand what you're talking about it's best to say so and shut up than pretend you're wise beyond your knowledge.

Apache and Lightspeed have not had that problem for a very long time. They will not execute files whose extension does not end with .php, regardless of what the URL path and query is. Unlike NginX, Apache handles PHP files based on the name of the actual file on disk, not the URL. Moreover, the caveat of accidentally allowing files with double extensions to be executed as PHP has been known and documented since 2001, long before NginX even existed.

Here's how Apache is configured to run PHP files, using Apache's <FilesMatch> directive. Remember that it operates based on the location and file name of the actual file on disk, not what you put in the URL. It normally looks like this:

<FilesMatch \.php$>
  SetHandler application/x-httpd-php
</FilesMatch>

The line between the two tags of the directive may be different and depends on the server configuration and the PHP SAPI being used. The above example is typical when using PHP as an Apache module (mod_php). When using PHP through PHP-FPM (PHP FastCGI Process Manager) it looks more like this SetHandler "proxy:fcgi://127.0.0.1:9082/". But that's not the important part.

The important part is the first line, the part I put in bold type. It is a regular expression which is matching file names. The Regular Expression \.php$ means "anything whose filename ends with .php matched exactly and case-sensitive". A file named foobar.php.png does not fulfil this criterion because its filename ends .php.png, not .php.

If you have a URL like https://www.example.com/images/foobar.php.png/foo.php Apache follows the path and sees that while images/foobar.php.png is a real file, images/foobar.php.png/foo.php is not. It will throw a 404. If you have a URL like https://www.example.com/images/foobar.php.png?foo.php Apache looks for the file in the path, i.e. images/foobar.php.png. Since its filename ends in .php.png, NOT .php, it is not executed by PHP. It is served verbatim with the MIME type image/png. The browser cannot decode this as a PNG image and shows the "broken / missing image" icon in its place. Therefore, no matter what you do, files with double extensions cannot execute as PHP.

A server would only be vulnerable to what the person on the forum said, executing files with double extensions, if the server administrator was a moron and instead of the above typed this:

<FilesMatch \.php>
  SetHandler application/x-httpd-php
</FilesMatch>

This is idiotic. The Regular Expression .php means "anything that has the string literal .php anywhere in its name". This matches foobar.php, foobar.php.png as well as foobar.phpversion.txt. This is a security violation.

The last time I saw a server with this kind of crappy configuration was back in 2003. There was explicit warning against doing that as far back as 2001. If someone is on a server run by a person who does not understand how Apache works and has managed to somehow not read about this explicit warning for over 20 years I would posit that this would be the least of their security worries. I would be extremely worried about the overall security of the server and I'd run away to a host who actually understands how hosting works!

If you want to test if your host is a moron you need to run away from you can do it very simply. Create a file named test.php.txt with the following content:

<?php phpinfo();

If this is a new, empty site, upload it to the site's root and access it, e.g. https://www.example.com/test.php.txt.

If it is an existing Joomla site, upload it into the images folder (using SFTP, or your host's file manager) and access it, e.g. https://www.example.com/images/test.php.txt.

If you see the literal <?php phpinfo(); content you're all good. Breathe.

If, however, you see PHP's status page listing the PHP version and enabled PHP extensions you have an affected host run by a moron. In this case, run away. Move to a different host as fast as you can. If the host has not figure out how to make PHP run correctly, chances are they are unable to run a secure server at all.

Knowledge is power. Knowing how things work allows you to worry about real threats, not imaginary threats. Expending energy on imaginary threats is unproductive, and distracts you from the real threats you need to concern yourself with. You are French. You know all about the Maginot line and how one man's obsession with an imaginary threat handed over France on a plate to the Axis forces. Therefore, you surely understand what I mean here :)