• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx

  • We are developing a new feature in Plesk that will help you promote your websites or business on social media. We want to conduct a one-hour online UX test to present the prototype and collect feedback. If you are interested in the feature, please book a meeting via this link.
    Thank you in advance!
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Zero Day Exploit

Goodfred

Basic Pleskian
Good evening everyone!

I only have the question if I should care because of the actual zero day exploit about log4j.

I heard that apache is vulnerable, too.

Now my question is: Do I have to update Plesk because of this zero day exploit?

It is friday and I hope that I dont need to now and that I can run the updates on monday!

Thank you for answers!

Goodfred
 
I don't even know if Plesk uses Log4j.
I'm quite certain it does not. Perhaps some 3rd party extensions might use it, but I see no sign of it on a couple sample Plesk boxes of ours.

I heard that apache is vulnerable, too.
I think you might be mistaking the apache foundation/organisation with the apache web server. The foundation has a lot of different software projects under it, including log4j and the apache web server, but those are each separate software and this vulnerability is in log4j.
 
This only impact you if you use the affect versions with Log4J and Java, and have the vulnerable configs set to True, which I believe is default for most.
 
Just checked all our servers. Not any presence of Log4j.
Plesk does not use it apparently and is not responsible if you have it on your machine(s). Otherwise I am pretty sure they would fix it.
 
Just checked all our servers. Not any presence of Log4j.
Plesk does not use it apparently and is not responsible if you have it on your machine(s). Otherwise I am pretty sure they would fix it.
Hi there would you mind sharing how did you check for this. I've looked through all my projects composer.json and package.json and I couldnt find anything suspicious. Dont how how to check the server stack and panel software though. Thanks in advance.
 
No official word from Plesk though...
Two days later...
What do you need from Plesk? They don't use java.

Hi there would you mind sharing how did you check for this. I've looked through all my projects composer.json and package.json and I couldnt find anything suspicious. Dont how how to check the server stack and panel software though. Thanks in advance.
If you use composer.json, you're using PHP, not Java. Unless you explicitly set it up, Plesk does not use Java.
 
Hi,



Solutions seems to be published here:

CRS and Log4j / Log4Shell / CVE-2021-44228 – OWASP ModSecurity Core Rule Set

log4j_attack.jpg


Where two ModSecurity changes should do the job:



# Defense against CVE-2021-44228
SecRuleUpdateTargetById 932130 "REQUEST_HEADERS"


# Generic rule against CVE-2021-44228 (Log4j / Log4Shell)
# See CRS and Log4j / Log4Shell / CVE-2021-44228 – OWASP ModSecurity Core Rule Set
SecRule REQUEST_LINE|ARGS|ARGS_NAMES|REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_HEADERS|XML://*|XML://@* "@rx (?:\${[^}]{0,4}\${|\${(?:jndi|ctx))" \
"id:1005,\
phase:2,\
block,\
t:none,t:urlDecodeUni,t:cmdline,\
log,\
msg:'Potential Remote Command Execution: Log4j CVE-2021-44228', \
tag:'application-multi',\
tag:'language-java',\
tag:'platform-multi',\
tag:'attack-rce',\
tag:'OWASP_CRS',\
tag:'capec/1000/152/137/6',\
tag:'PCI/6.5.2',\
tag:'paranoia-level/1',\
ver:'OWASP_CRS/3.4.0-dev',\
severity:'CRITICAL',\
setvar:'tx.rce_score=+%{tx.critical_anomaly_score}',\
setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"
 
Back
Top