CVE-2026-31431

What it actually does

This is a local privilege-escalation vulnerability in the Linux kernel AF_ALG AEAD crypto socket implementation, specifically the algif_aead path. The vulnerable code attempted in-place AEAD processing even though source and destination buffers come from different memory mappings, creating unsafe memory-handling behavior in the kernel. A local user with the ability to run code can interact with AF_ALG sockets and crafted AEAD operations to trigger kernel memory corruption or incorrect resource handling, potentially gaining kernel-level execution or otherwise elevating privileges. The CVSS vector indicates low attack complexity, no user interaction, local access, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation can allow a low-privileged local user, compromised application account, container workload, or post-exploitation foothold to gain root or kernel-level control of a Linux host. This can lead to credential theft, disabling security controls, tampering with workloads, persistence, data exposure, and full host compromise. Because this issue is listed in CISA KEV, has active in-the-wild exploitation, and has an extremely high EPSS score, organizations should treat affected Linux kernels as high-priority remediation targets. The broad product impact across major Linux distributions, Red Hat OpenShift Container Platform, Amazon Linux, Ubuntu, Debian, openSUSE, and SUSE enterprise products increases operational exposure, especially where shared compute, containers, CI/CD runners, bastion hosts, or multi-user systems are present.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged user, service account, compromised application, or containerized workload on an affected Linux system. They then create AF_ALG sockets and select an AEAD algorithm exposed by the kernel crypto API. By submitting specially structured AEAD encryption or decryption requests that exercise the vulnerable algif_aead in-place handling path, the attacker attempts to corrupt or misuse kernel memory. A reliable exploit can convert that memory corruption into privilege escalation, such as modifying process credentials or achieving kernel-mode code execution. After escalation, the attacker typically spawns a root shell, disables defenses, accesses sensitive files, dumps credentials, tampers with workloads, or installs persistence. Active exploitation has been reported, and the vulnerability is tracked in KEV with a remediation due date of 2026-05-15.

How to fix it

Apply the vendor-provided kernel update for every affected Linux distribution and product. No universal upstream fixed version was provided in the input, so use the latest security-advisory kernel from the relevant vendor for Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, Amazon Linux, Ubuntu, Debian, openSUSE, SUSE Linux Enterprise, and related SUSE products. Because kernel fixes generally require activation, reboot affected systems or live-patch only where the vendor explicitly provides a live patch for this issue. Prioritize internet-facing Linux systems, bastion hosts, virtualization and container hosts, Kubernetes/OpenShift nodes, CI/CD runners, multi-user systems, and systems where untrusted or semi-trusted code can run. As temporary mitigation where operationally feasible, restrict local code execution, remove unnecessary user access, harden container boundaries, prevent untrusted workloads from using host kernel crypto interfaces, and monitor or restrict AF_ALG socket usage; however, mitigation should not replace patching for a KEV-listed actively exploited kernel privilege-escalation vulnerability.

How to confirm the fix worked

Confirm exposure by inventorying running kernel versions and comparing them against the security advisories for the installed distribution and product, not just package names. Verify the active kernel after remediation with commands such as `uname -a`, package-manager kernel queries, and vendor advisory tooling. Ensure the host has rebooted into the fixed kernel or that an approved vendor live patch is active. For container platforms, validate every node kernel, because containers share the host kernel. Confirm that vulnerability scanners and endpoint agents no longer flag the issue after reboot. Where possible, check whether AF_ALG AEAD functionality is present by reviewing `/proc/crypto`, loaded crypto modules, and kernel configuration, but absence or presence of a specific module should not be used as a substitute for vendor patch verification.

Typical attack path

1. Gain local code execution on an affected Linux host through a compromised account, vulnerable application, container escape-adjacent foothold, SSH access, or malware already running with limited privileges.
2. Check that AF_ALG and AEAD crypto support are available through the running kernel and crypto API.
3. Create AF_ALG sockets and bind them to an AEAD algorithm exposed by the kernel.
4. Send crafted AEAD requests designed to trigger the vulnerable algif_aead memory-handling path.
5. Use the resulting kernel memory corruption or incorrect resource handling to escalate privileges to root or kernel-level control.
6. Run post-exploitation actions such as credential access, defense evasion, persistence installation, lateral movement preparation, or tampering with workloads.

How to detect it

Detection should focus on both exploit attempts and post-exploitation, because successful local kernel privilege escalation may leave limited direct evidence. Review kernel logs from `dmesg`, journald, `/var/log/kern.log`, `/var/log/messages`, and crash dump systems for references to AF_ALG, algif_aead, AEAD crypto operations, kernel oops events, general protection faults, use-after-free reports, KASAN reports, or unexplained crashes near suspicious local process activity. If auditd or eBPF telemetry is available, search for unusual creation of AF_ALG sockets, especially by processes that normally do not use kernel crypto APIs, followed by rapid privilege changes, execution of root shells, or modification of persistence locations. Review EDR process trees for low-privileged services spawning shells, package managers, account-management tools, or security-control modifications. In container environments, examine node-level logs for suspicious workloads interacting with kernel interfaces and then causing host-level privileged activity. Because active exploitation is reported and the issue is in KEV, also hunt for generic Linux post-compromise artifacts: new SUID/SGID files, unexpected changes under systemd or cron paths, unauthorized SSH keys, new users, modified sudoers files, disabled logging or EDR services, and credential access tooling. Absence of crash logs does not prove absence of exploitation; a reliable exploit may avoid obvious kernel panics.

• algif_aead
• af_alg
• AF_ALG
• AEAD
• BUG: kernel
• Oops:
• general protection fault
• KASAN:
• kernel NULL pointer dereference
• use-after-free
• /proc/crypto
• /var/log/kern.log
• /var/log/messages
• /var/crash/
• /etc/cron.d/
• /etc/cron.daily/
• /etc/systemd/system/
• /etc/sudoers
• /etc/sudoers.d/
• /root/.ssh/authorized_keys
• chmod u+s
• setuid

What your security team should do

• Treat this as urgent because it is KEV-listed, actively exploited in the wild, has a very high EPSS score, and affects broadly deployed Linux platforms.
• Patch and reboot affected Linux hosts before the KEV due date of 2026-05-15, prioritizing systems that allow local users, containers, build jobs, or third-party workloads.
• Inventory all Linux kernels across servers, endpoints, cloud images, Kubernetes/OpenShift nodes, appliances, and golden images; do not assume containers are protected if the host kernel is vulnerable.
• Review EDR, auditd, syslog, kernel logs, and crash telemetry for signs of AF_ALG/algif_aead abuse, kernel oops events, unexpected root shells, and suspicious privilege transitions.
• Temporarily reduce local attack surface by limiting shell access, disabling unnecessary accounts, restricting untrusted workloads, and isolating high-risk multi-tenant systems until patched.
• Hunt for post-exploitation behavior following possible local privilege escalation, including new SUID binaries, unauthorized SSH keys, modified cron/systemd persistence, disabled security agents, and credential-dumping activity.
• Ensure updated kernels are baked into base images, autoscaling templates, AMIs, VM templates, and container-platform node images to prevent reintroduction of vulnerable kernels.
• Coordinate with Linux distribution vendors for exact fixed kernel package versions and live-patching availability where reboots require maintenance windows.