Unfortunately there is another critical issue with the Linux kernel: CVE-2026-43284 This critical issue affects RH10, RH9 and RH8 based systems and RH7, RH6 based systems are under investigation (but highly likely to be affected too)
At the time of this writing there is no permanent fix yet and the issue(s) is/are still being investigated in detail for RH 7 and RH6 based systems.
Please allow Nethesis to provide more details and directions on Nethserver versions specifically.
ps. For those wondering, a Nethserver 8 cluster (even 1 node) is based on the Wireguard VPN software and not IPSec. So a mitigation method that disables IPSec requirements being loaded should not effect normal NS8 (cluster) operations.
An important message from Rocky Linux regarding a new repository called ‘security’
Will Nethesis adopt, include and take into effect the security repo for Nethserver?
With the introduction of the new security repository and with engineering assistance from CIQ, we are also announcing the immediate availability of a security update addressing the recently disclosed Linux kernel vulnerability known as “Dirty Frag”.
Thanks @laylow for the above fix procedure (currently marked as solution ), which is valid for Rocky Linux 9. Other distributions may provide similar procedures to update the Linux kernel.
In any case, a reboot is required to activate the patched kernel.
The Rocky Linux community and CIQ did great work and, by choosing to release the new security repository with an opt-in policy, confirmed their “1:1 upstream compatibility” approach to updates[1]. We support this choice, so the new security repository will not be enabled by default on NS8 installations.
As always, our ns8-baseos and ns8-appstream Rocky Linux mirrors are actively monitored and synchronized with the respective upstream repositories to ensure updates do not impact NS8 functionality.
Regarding the Red Hat kernel security update[2] we are waiting for, it will be pushed to our mirrors as soon as it is published upstream, as we already did for the CopyFail patch.
At the moment, Red Hat is still determining whether the vulnerability affects older EL6 and EL7 systems, so we cannot yet state whether NS6 and NS7 are affected[3].
About NS8:
on Rocky Linux and other EL9-based distros as alternative to the fix above, it is possible to apply the official mitigation procedure: the IPsec modules esp4 and esp6 are not required by NS8. In a standard NS8 installation they are not even loaded and can be safely blocklisted as described in the mitigation procedure. The same applies to the rxrpc module, which should not be loaded either[4][5].
on Debian a patched kernel is available from the security repository[6][7].
As mentioned above, the new Rocky Linux security repository will not be added to the NS8 mirrors. This choice reflects the Rocky Linux default policy about it. It is still possible to enable it as wanted.
Dirty Flag CVE-2026-43284 was fixed in kernel-5.14.0-611.55.1.el9_7[1].
According to the links above, Fragnesia CVE-2026-46300 has not yet been fixed by Red Hat[2].
His post “explains” the procedure if you already know that the baseos repo isn’t enabled by default (it isn’t on my system, anyway). I didn’t know that. So for anyone else who might be in that situation, the solution is to run dnf upgrade --enablerepo=baseos followed by dnf upgrade --enablerepo=security?
), which is valid for Rocky Linux 9. Other distributions may provide similar procedures to update the Linux kernel.