There are two CVEs here both reasonably high (CVE-2025-49844 | CVSS Score: 10, CVE-2025-46817 | CVSS Score: 7) and both requiring lua scripting. So key question do we allow / is there enabled and is there in place lua scripting?
If so who can introduce such lua scripts - are they able to introduced by any authorised (admin) on the VM - not remotely / from a restricted area (i.e. binary) etc
The vulnerability requires that an attacker can establish a connection & log in to a Redis server. In CheckMK’s case the Redis server used for each site only listens on a Unix socket that can only be accessed by the site’s Linux user. It does not listen on TCP.
Therefore the only way to exploit this is if an attacker can run arbitrary code as a site user. If they can do that, you have altogether different problems as they can hook into any CheckMK code including code baked into agents distributed to monitored machines where it’s often run with full privileges.
Meaning: I concur with Martin’s evaluation.
Disclaimer: I don’t work for CheckMK. This is solely from my own evaluation of the impact on my own situation.
Again, Redis is only accessible by local processes running under the site’s Linux user. There’s no way for remote code to access it, nor for local code running under different Linux users. In other words I cannot think of any way to attack the running instance for malicious code.
Just because something unsupported is running doesn’t mean that it’s actually possible to attack it.
I’ll gladly be proven wrong here, though. I just don’t think the usual security stance of “only run supported versions” should apply here.
And that’s another thing that isn’t true as absolutely as you state it. Sure, if then vendor of the combined solutions offers an upgrade, do the upgrade. However, if they don’t you have to weigh the cost of doing manual upgrades (in this case: download Redis sources, build the thing yourself, replace the installed/packaged one with the one you built, test it, fix any issues cropping up) with the cost of keeping the vulnerable but maybe not exploitable but packaged version around.
Are you building each Linux kernel from upstream source as soon as it it’s released? Probably not, you probably let your Linux distro take care of kernel updates. And that’s the same principal as the Redis component distributed as part of the CheckMK server package.
No, cause the kernel i run is supported. Hence i don’t need a new one as soon as it’s released. Multiple versions of the same package can be supported. Someone running CheckMK shoud know.
With running an outdated Redis version, CMK has to verify every new reddis CVE to see if it applies to their unsupported version. You don’t have to do that if you run an supported version. It not that hard to grasp.
