Resolved Plesk, what’s going on here? - Imunify auto installation

[Fede Marsell]

Could you please elaborate on that question. I am not entirely sure I understand it. Sorry.

Once Imunify is installed —even without explicit permission— it begins scanning the server and uploading files it deems suspicious to external servers.

The extent of this behavior is unclear: it's not known whether Imunify uploads entire files or just fragments.

Regardless, this constitutes a serious security breach.

In the console.log, the data transfer is clearly visible:

imav.malwarelib.utils.malware_response: Uploaded file '/var/www/vhosts/domain.com/xxxx.php' to the Malware Response Service with reason: extended-

This is a critical issue — a data leak caused by the unauthorized installation of a third-party extension.

 

[Sebahat.hadzhi]

@Fede Marsell , I consulted with our team about your case. The Malware Response Service is not part of the free Imunify extension, which suggests that you do have a Imunify360 license on the server in question. Therefore, the automatic installation (replacement) of the extension is expected in your case.

The functionality itself is intended to find suspicious files and send them for analysis to CloudLinux servers. Please note that, files containing personal or sensitive information are removed from the pipeline immediately on detection. Cloud scanning can be disabled by running:

imunify360-agent config update '{"MALWARE_SCANNING": {"sends_file_for_analysis": false}}'

but the detection rate will be worse - some scanning methods require a lot of RAM or heavy computing to unpack obfuscated code or separate edge cases, and thus are not practical to run on individual servers.

If you have any additional questions or concerns, please directly get in touch with Plesk or CloudLinux support, as with limited server information we won't be able to precisely address the case.

 

[Fede Marsell]

@Fede Marsell , I consulted with our team about your case. The Malware Response Service is not part of the free Imunify extension, which suggests that you do have a Imunify360 license on the server in question. Therefore, the automatic installation (replacement) of the extension is expected in your case.

The functionality itself is intended to find suspicious files and send them for analysis to CloudLinux servers. Please note that, files containing personal or sensitive information are removed from the pipeline immediately on detection. Cloud scanning can be disabled by running:

imunify360-agent config update '{"MALWARE_SCANNING": {"sends_file_for_analysis": false}}'

but the detection rate will be worse - some scanning methods require a lot of RAM or heavy computing to unpack obfuscated code or separate edge cases, and thus are not practical to run on individual servers.

If you have any additional questions or concerns, please directly get in touch with Plesk or CloudLinux support, as with limited server information we won't be able to precisely address the case.

I've never installed Imunify and I've never purchased a license for this extension. Never.

I manage more than 50 servers with PLESK, and on most of them, Imunify was automatically installed without consent and has sent sensitive information to external servers.

Any user can review its logs. They can see how their files have been transferred to Imunify's external servers.

They just need to check the logs (grep Uploaded /var/log/imunify360/console.log).

I repeat, this is extremely serious.

 

[Sebahat.hadzhi]

According to what I have been told this is a paid functionality and should not be present unless with Imunify license. Nevertheless, as previously mentioned, files containing personal or sensitive information are removed from the pipeline immediately on detection. This has been consulted with CloudLinux and confirmed by their team.

 

[Fede Marsell]

According to what I have been told this is a paid functionality and should not be present unless with Imunify license.

Absolutely not. You are seriously mistaken.

 

[ChristophRo]

The "Malware Scanner" is indeed enabled and usable in the free edition.
In fact it's the only component that is available in the free edition and it gets installed on a Plesk server by default.

While the "Malware Scanner" is somewhat limited in the free edition (like only one scan per month), it will of course still use the function to upload suspicious code to Cloudlinux for further analysis.

I can see that some people may have a problem with that, despite the fact that this behavior is common and widely used in the AV industry.

 

[Sebahat.hadzhi]

While the Malware scanner itself is available, according to our discussion with CloudLinux, the file upload process is part of a paid functionality that should not be available in the free edition. This statement is based on the log provided earlier in the thread. Unfortunately, we can't confirm for sure what's triggering that behavior without server access. Nevertheless, in terms of security breach concerning the files uploaded to CloudLinux - the sensitive data is excluded.

 

[Fede Marsell]

I can see that some people may have a problem with that, despite the fact that this behavior is common and widely used in the AV industry.

The problem is that both the installation of the extension and the data transfer happened without any prior authorization or consent.

This is a serious breach.

 

[trialotto]

While the Malware scanner itself is available, according to our discussion with CloudLinux, the file upload process is part of a paid functionality that should not be available in the free edition. This statement is based on the log provided earlier in the thread. Unfortunately, we can't confirm for sure what's triggering that behavior without server access. Nevertheless, in terms of security breach concerning the files uploaded to CloudLinux - the sensitive data is excluded.

@Sebahat.hadzhi

I think that @Fede Marsell is addressing an issue that should indeed be called a "data leak" in a legal sense.

There is no legal ground for sharing data / uploading data by an extension, if that extension has not been installed explicitly and (legal) conditions have not been agreed with explicitly.

The degree in which the "data leak" occurs and the severity of the "data leak" depends on the information shared / uploaded.

Plesk is - essentially - responsible for the current "data leak" and, if any "data leak" exists in a legal sense, Plesk can be fined in most European countries.

Stated differently, @Fede Marsell addresses an issue that is in the interest of Plesk.

In fact, Plesk should really "control" the data that can be shared / uploaded by limiting that data to (a) a very limited set of data and (b) a limited set of data that is not harmful in any way (and that can never do harm in any sense).

For instance, Plesk should not "allow" Imunify to retrieve WP config files (since they contain access data that you do not want to share) - however, general WP files can be easily shared (since that can never do harm).

As an another example, Plesk should never "allow" Imunify to scan files or config files that are inherent to the server (since Imunify does not actually do anything with them, Imunify is not that advanced).

In my humble opinion, there is a black box called Imunify with too much unknowns and uncertainty - it is not a good thing that it exists.

Plesk should really consider alternatives to Imunify.

Kind regards......

 

[Fede Marsell]

There is no legal ground for sharing data / uploading data by an extension, if that extension has not been installed explicitly and (legal) conditions have not been agreed with explicitly.

Plesk is - essentially - responsible for the current "data leak" and, if any "data leak" exists in a legal sense, Plesk can be fined in most European countries.

Indeed.

PLESK's official silence on this issue makes the problem even more serious.

 

[trialotto]

@Fede Marsell

The statement

PLESK's official silence on this issue makes the problem even more serious.

is not really accurate.

I can safely assume that Plesk is looking into the matter, before making any (bold or implicit/explicit) statements.

If that assumption can be proven to be incorrect, then there is a case of "negligence".

The legal aspects of this matter are essentially a Gordian Knot - it is hard to say who is responsible or even liable for what, since any responsibility / liability really depends on the factual reality.


Nevertheless, I adhere to your point of view that Plesk should investigate this matter fast and thoroughly.

It simply cannot be the case that an extension can - potentially or factually - be the root cause of any problem related to "data leaks".

In addition, it cannot be the case that an extension like Imunify is introduced and making a mess of Plesk or the proper functioning of Plesk.


In summary, it has been excellent that you pointed out an important topic ......... but we all have to have some patience and confidence.

However, it is always good if you (and others) keep posting, since those posts are essentially reminders to Plesk.


Kind regards....

 

[/dev/null]

We see the same on all our servers. Do not understand why this extension is pushed.

 

[trialotto]

We see the same on all our servers. Do not understand why this extension is pushed.

My educated guess would be that Plesk has a business model, associated with the (paid for) extension.

At least in theory, the combination of "feedback" of all Plesk servers with respect to bad files and bad IPs would allow for the development of a better solution.

It is just a different way of thinking from my side .......... and in any environment of "core + extensions" there is no space for this odd way of thinking.

Stated differently, if Plesk was not that focused on "extensions", then the full ability of Plesk servers could have been used to create a proper solution.

Could, should, would....... it simply is the case that we have to deal with the Imunify extension or that Plesk should be dealing with that extension.

Kind regards....

 

[/dev/null]

My educated guess would be that Plesk has a business model, associated with the (paid for) extension.

At least in theory, the combination of "feedback" of all Plesk servers with respect to bad files and bad IPs would allow for the development of a better solution.

It is just a different way of thinking from my side .......... and in any environment of "core + extensions" there is no space for this odd way of thinking.

Stated differently, if Plesk was not that focused on "extensions", then the full ability of Plesk servers could have been used to create a proper solution.

Could, should, would....... it simply is the case that we have to deal with the Imunify extension or that Plesk should be dealing with that extension.

Kind regards....

 

[/dev/null]

I understand what your saying. Just wondering as we pay for licenses for a 'control panel' who is in 'control ' of the control panel....

For example Site jet was pushed . In the WP toolkit some external option was pushed. And now Immunify with out any notification and perhaps
that was a misunderstanding or something. But the Immunify scan (in the free version) which was pushed takes cpu processing power.
It would be nice if these kind of weird things would not be pushed.

/dev/null

 

[Fede Marsell]

I understand what your saying. Just wondering as we pay for licenses for a 'control panel' who is in 'control ' of the control panel....

For example Site jet was pushed . In the WP toolkit some external option was pushed. And now Immunify with out any notification and perhaps
that was a misunderstanding or something. But the Immunify scan (in the free version) which was pushed takes cpu processing power.
It would be nice if these kind of weird things would not be pushed.

/dev/null

I'd like to know how much money PLESK makes by adding these extensions with such wonderful features (hiring a programmer, payment options sold through Sitejet or WP ToolKit, etc.).

 

[Fede Marsell]

And all options enabled without any consent.

 

[Ekaterina Babenko]

Hello everyone.

My name is Ekaterina and I am product manager of Imunify extension in Plesk.

I investigated this matter with CloudLinux and would like to share with you the findings.
Thank you for your patience.

Imunify is widely acknowledged as a reputable and trusted security extension, consistently demonstrating its effectiveness and reliability across a broad user base.To further ensure data protection, I conducted an internal review in collaboration with the CloudLinux team.

As result of internal check conducted with CloudLinux team they confirmed that extension does not use personal or sensitive data for security analysis and it is removed instantly once found while still being on the server. It means that the personal/sensitive data is not transferred externally or stored on their analysis server.

CloudLinux team has no intent and do not use any personal or sensitive data and only suspicious/malicious information is analysed in order to provide security on the server.

Appreciate your understanding.

 

[Fede Marsell]

Answered in the thread created to report the situation:

Issue - Important: Imunify auto installation and possible data leak

As many PLESK users have seen, a few days ago, the Imunify extension was installed automatically. This installation was carried out without your consent. This fact, in itself, is quite serious. The reason for this post is that it is possible that much of your data has been transferred by this...

talk.plesk.com

 

[s.kazimierczak]

Guys,
Yesterday I tried to access Updates page didn't want to load completely. So I was investigating why... I checked the autoinstaller.log and my DailyMaintenance was stuck at download.immunify360.com for over 3 hours and I needed to kill it. It also caused other processes to hang like enviromentccheckum.