On April 29th 2026 a high severity local privilege escalation vulnerability was publicly disclosed for multiple Linux distributions.

This vulnerability is caused by a bug in the authencesn template of the AF_ALG kernel crypto API. The bug enables the overwrite of the page cache version of the su binary, which can provide an unprivileged local user with direct access to root on the target system. A full technical writeup can be found by the original research team here .

Exploitability

The proof of concept exploit code is fully viable to perform a local privilege escalation attack for x86 based systems. The Python script includes an obfuscated instruction-set that can easily be adjusted to target other architectures - there are some available online at the time of writing.

A key concern is the breakout of container systems like with Kubernetes. There is limited information available at this point, but it is believed that exploitation of a container could result in the compromise of the host system.

Kubernetes Container Escape

Update 1st May 2026: A Kubernetes breakout proof of concept has been published online.

CVE-2026-31431 extends beyond local privilege escalation. Because the Linux kernel’s page cache is shared across all processes on a host (including across container boundaries) an unprivileged container can corrupt the page cache of a binary used by a privileged container on the same node.

Patch the kernel, as this is the only complete fix. Apply the CVE-2026-31431 kernel patch and restart your nodes.

Mitigation

Check whether the AEAD module is loadable on your system:

grep CONFIG_CRYPTO_USER_API /boot/config-$(uname -r)

If the output includes CONFIG_CRYPTO_USER_API_AEAD=y or =m, the module can be loaded and you should apply the workaround below.

Disable the algif_aead module. This removes the attack path by preventing unprivileged userspace from accessing AEAD operations via AF_ALG sockets. This should not impact normal operations, as key functionality calls userspace libraries or the kernel directly.

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

Rebooting an exploited system will revert the su binary from disk to the page cache, but this will not resolve any initial or persistent access that an attacker may have to your systems.

RedHat (RHEL)

Add the following to the kernel boot options and reboot the system:

initcall_blacklist=algif_aead_init

RedHat also note that either of the two following can be used to block the af_alg interface or the vulnerable algorithm, respectively:

initcall_blacklist=af_alg_init

initcall_blacklist=crypto_authenc_esn_module_init

Ubuntu / Debian

Block the algif module via modprobe and then unload the module:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/manual-disable-algif_aead.conf
sudo rmmod algif_aead 2>/dev/null

You can check if the module is already loaded with the following command:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Alternatively, reboot the system.

Patching and Updates

The upstream kernel fix reverts the algif_aead in-place operation optimisation introduced in 2017, separating the source and destination scatterlists so that page cache pages from splice() can no longer end up in a writable destination.

Patches were committed to the mainline kernel on April 1st 2026, over four weeks before public disclosure. Any system that has not received a kernel update since early April should be treated as at elevated risk.

Distribution CVE Tracking

References