CVE-2026-31431 is a Linux kernel vulnerability involving the AF_ALG AEAD cryptographic interface. It matters to Docker operators because ordinary containers share their host’s kernel.

Correction — October 30, 2026: The original article claimed that every unprivileged container could escape to host root, and treated a simple kernel version or module check as a complete exposure test. Those statements were too broad. Exposure depends on the host kernel’s patch status, available kernel functionality, and the container’s runtime restrictions. This revision uses the Linux CNA record and Docker’s security documentation as its baseline.

What the Official Record Establishes

The Linux CNA record describes the fix as reverting algif_aead to out-of-place operation. Its CVSS 3.1 score is 7.8 (High), with local access and low privileges required.

The record lists several fixed upstream branches, including 5.10.254, 5.15.204, 6.1.170, 6.6.137, 6.12.85, 6.18.22, 6.19.12, and 7.0. Distribution and Proxmox packages may backport fixes. Use your kernel vendor’s advisory and exact installed package revision, not an upstream version comparison alone.

1. Inventory the Host and Runtime

Run on the actual Docker host:

1
2
3
4

uname -r
cat /etc/os-release
docker version
docker info --format '{{json .SecurityOptions}}'

On Debian-based systems, identify the running kernel’s package:

1

dpkg-query -S "/boot/vmlinuz-$(uname -r)"

If that path is unavailable, use your platform’s package inventory. Docker inside a Proxmox LXC still uses the Proxmox host kernel; updating packages only inside the LXC does not patch that kernel. Docker inside a VM uses the VM’s guest kernel.

Record which advisory confirms the fix for your vendor package. An installed update does not protect the running kernel until that kernel is activated, usually by rebooting.

2. Review Container Restrictions

1
2

docker ps --format 'table {{.Names}}\t{{.Image}}'
docker inspect YOUR_CONTAINER --format 'Privileged={{.HostConfig.Privileged}} SecurityOpt={{json .HostConfig.SecurityOpt}} CapAdd={{json .HostConfig.CapAdd}}'

Replace YOUR_CONTAINER with a real container name. Investigate privileged containers, seccomp=unconfined, and unnecessary added capabilities. An empty per-container SecurityOpt value does not mean seccomp is disabled; check the daemon’s security options too.

Docker’s default seccomp profile blocks many potentially dangerous operations. Its behavior depends on the Engine/profile version. Do not assume a universal escape path, and do not replace the default profile with a tiny custom allowlist copied from a blog: an incomplete profile may stop applications from working or remove protections you intended to keep.

3. Apply the Vendor Kernel Fix

On Debian or Ubuntu, refresh package information and inspect available upgrades:

1
2

sudo apt update
apt list --upgradable

Install the kernel update specified by your vendor through your normal maintenance procedure. On Proxmox, follow Proxmox’s supported update process for its kernel packages. Schedule the reboot, account for VM/container downtime or migration, and retain a known-good boot entry.

After booting the patched kernel:

1
2
3

uname -r
systemctl --failed
docker ps

Confirm the running package revision against the advisory, then test application health. Upgrading the Docker image or Docker Engine alone does not patch the host kernel.

4. Use Temporary Mitigations Only When Justified

If patching must wait, consult your vendor’s specific mitigation guidance. Restrict untrusted local code and container workloads, retain seccomp confinement, and remove unnecessary privileges.

Module listings are diagnostic information, not proof of safety:

1
2

lsmod | grep -E '(^algif_aead|^af_alg)'
modinfo algif_aead

No lsmod entry can mean the module is currently unloaded; it may still autoload. Kernel functionality can also be built in. A blacklist file alone does not unload already active code, and disabling crypto functionality can affect legitimate applications. Avoid presenting either check as a complete vulnerability verdict.

Verification Checklist

  • Identify the kernel that actually isolates the containers.
  • Match its package revision to the vendor’s CVE status.
  • Boot the fixed kernel and confirm the running version.
  • Review privileged and unconfined containers.
  • Verify services after maintenance.
  • Record the advisory and package revision used to establish remediation.

This is an operational verification checklist, not an exploit test. No exploit needs to be run to establish that your vendor’s fixed kernel package is active.

References