Of course we cannot always share details about our work with customers, but nevertheless it is nice to show our technical achievements and share some of our implemented solutions.
There are sunny days, and there are cloudy days.
For Linux servers the days are mostly sunny. A broad community of open source developers, from Linux Kernel developers, to software engineers to security gurus: The combination makes Linux a top-tier, fast and secure Operating System.
Every once in a while there are cloudy days with major vulnerabilities. Every Operating Systems has them. Some are more often affected, some less.
With the recently discovered CopyFail vulnerability (CVE-2026-31431), it's not just a cloudy day for Linux systems; it's a thunderstorm with hail and tornadoes.
The vulnerability allows to become root by executing a specific payload against the algif_aead Kernel module.
Although this Kernel module is not even often loaded ($ lsmod|grep algif), especially not by default, it can be loaded dynamically and can then be exploited through its vulnerability.
It's even possible to exploit CopyFail through a Kubernetes pod, hence theoretically gaining access to the underlying node in combination with other exploits (or with an unprivileged pod).
The big surprise here is that the actual fix was already applied on April 1st in the Linux Kernel (mainline). But when the vulnerability was published on April 29th 2026, most of the Linux distributions hadn't yet a patched Kernel ready for download/patching.
Today, May 1st 2026, is already a different story: Debian - the distribution we use on our servers - released a fixed Kernel package.
The other way, while waiting or scheduling Kernel patches, is a mitigation. The vulnerability can be mitigated by fully disabling (aka not allowing to enable) the module. Blacklisting the module is not enough, as it still allows to manually load the module.
root@debian ~ # echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
This disallows loading the algif_aead immediately. An attempt to do so results in an error, as /bin/false is now executed:
root@debian ~ # modprobe algif_aead
modprobe: ERROR: ../libkmod/libkmod-module.c:1047 command_do() Error running install command '/bin/false' for module algif_aead: retcode 1
modprobe: ERROR: could not insert 'algif_aead': Invalid argument
It's also advised to update the Kernels initramfs after adding the mitigation:
root@debian ~ # update-initramfs -u
As we're using Ansible as central configuration management for our managed and dedicated servers, we've applied the mitigation on all Linux servers using the following Ansible tasks as part of a playbook:
##########################
# Tasks
##########################
- name: MITIGATION - Persistenly disable algif_aead kernel module
lineinfile:
dest: /etc/modprobe.d/disable-algif.conf
regexp: "^install algif_aead"
line: "install algif_aead /bin/false"
state: present
create: yes
register: modprobefile
- name: MITIGATION - Update initramfs
command: update-initramfs -u
when: modprobefile.changed
Our servers are secure - for this vulnerability. But as the vulnerability was detected by using specific AI tools, it's just a matter of time, when the next major vulnerability will be published. And maybe next time it won't be discovered by a security researcher, but from a hacking group.
This is going to change the cat and mouse game in the future. Companies taking weeks to patch their servers will have major problems and will need quick re-thinking of their patching and server management methods.