Apache vulnerability in 2.4.49
-
Your command produces this output
ea-apache24.x86_64 1:2.4.48-5.el7.cloudlinux @imunify360-ea-php-hardened
so i guess i have to wait for imunify
Just raise a ticket with CloudLInux to find out how you should handle that with their @imunify repo. They probably have a bypass you can enable in the same way as you can for their normal @cl repo. The imunify360.com site provides the following link for raising a support ticket...0 -
@rscalover - I'm glad the CloudLinux team was able to help with that. I can't really say what the issue may have been with the CloudLinux side of things, but if you could post your findings here once it is resolved that would be helpful for everyone. 0 -
@rscalover - I'm glad the CloudLinux team was able to help with that. I can't really say what the issue may have been with the CloudLinux side of things, but if you could post your findings here once it is resolved that would be helpful for everyone.
The cloudlinux-rollout repos are for the cloudlinux os i am running centos 7.9 but since i do have imunify360 cloudlinux will release a patch to fix that vulnerability ETA being October 12 to October 17 2021 so the message is wait for the patch which will arrive via the standard update system (Yum).0 -
Yes, we're hoping to get that out very soon. 0 -
2.4.51 is out now! 0 -
updated. thanks. 0 -
My server received an update httpd -v Server version: Apache/2.4.51 (cPanel) <<--- Server built: Oct 7 2021 15:12:45
you can check with yum check-update if you didn't receive it yet0 -
Hello, Is the default cPanel configuration vulnerable to this? We have checked the Apache access_log for some of our servers and found multiple attempts of this vulnerability from various sources. According to access_logs, the server returned 400 Bad Request to all attempts (Apache 2.4.49 and 50). No attempt got 200 OK status code. This means the servers were not vulnerable and attempts did not succed? Should we be worried? Thanks 0 -
@MegaBytu - the cPanel configuration isn't relevant to the issue as it's purely an Apache problem - it would happen on servers just the same whether they were running cPanel or not. If you have automatic updates enabled and you are updated to 2.4.51 everything is taken care of. 0 -
If you have automatic updates enabled and you are updated to 2.4.51 everything is taken care of.
Hello, Thank you but you did not answer my last question. The cPanel automatic updates are enabled, of course, but for a window of time the servers were running Apache 2.4.49 and 2.4.50, before the automatic update to 2.4.51 was scheduled. Although we forced the automatic update to 2.4.51 prior to the cPanel update cron job (that calls yum update), we identified this attack in attempts using access_log analysis while the version of Apache was 2.4.49 and 2.4.50. According to access_logs, the server returned 400 Bad Request to all attempts (Apache 2.4.49 and 50). No attempt got 200 OK status code. This means the servers were not vulnerable and attempts did not succed? Should we be worried? Thank you.0 -
Unfortunately that just isn't enough detail to say "yes" or "no" with any type of certainty. Our recommendation both here and in tickets is to always speak with a security professional if you ever have a doubt about the state of the server. 0 -
Offtopic, although automatic updates are a good idea, this issue could have been prevented by not enforcing automatic updates (that cannot be disabled or configured) to software that was insufficient tested, such as for example Apache 2.4.49 which was a version only 26 days old ... I understand that this is not completely a cPanel problem, due to the fact that Apache is updated by CentOS's yum update, but cPanel should allow a more detailed customization about how updates are deployed on each server - in the context that automatic updates cannot be disabled. 0 -
Unfortunately that's one we don't get to win no matter what we choose. If we delay the automatic updates, we get half the crowd saying "why hasn't cPanel released this yet?" and if we push them quickly we get "why doesn't cPanel take more time to test that?" With updates from upstream provides, like Apache, we've decided it's best to get those out as quickly as we can in case there are critical updates like what we saw this last week. 0 -
Also, feedback for this case particularly, in the context that cPanel was the first who discovered this issue. Due to the fact that cPanel manages httpd.conf automatically (editing directly httpd.conf being not recommended), we have checked and no Apache installation - on no server (VPS or bare-metal) - has the "Require all denied" directive on / directory, as this would be one of the attack mitigations. Prioir any publicity, cPanel should have enforced an update for httpd.conf, by it's upcp process. There are a lot of issues with cPanel lately (pushing useless software such as WordPress manager plugin, changing prices without any predictibility and making one step forward towards unreliability). 0
Please sign in to leave a comment.
Comments
46 comments