CVE-2026-43033

What it actually does

This is a Linux kernel memory-corruption flaw in the crypto authencesn implementation used for authenticated encryption with extended sequence numbers, commonly associated with IPsec/ESP-style cryptographic processing. During out-of-place decryption, where the source and destination buffers differ, the vulnerable code can mishandle placement and rearrangement of the high-order sequence bits, leading to improper memory access or corruption in kernel context. Because the bug occurs inside the kernel, successful exploitation may allow a local low-privileged user or process with access to a reachable cryptographic interface or configuration path to crash the system, corrupt kernel memory, disclose sensitive memory contents, or potentially escalate privileges.

Why it matters to the business

A successful attack could result in full compromise or instability of Linux systems, including service outages from kernel crashes and possible attacker elevation from a low-privileged account to kernel-level control. The current EPSS is very low and there is no known CISA KEV listing or public exploit maturity reported, so broad active exploitation is not currently indicated; however, the high CVSS impact means organizations should still prioritize patching exposed Linux workloads, especially systems using IPsec, kernel cryptographic APIs, or multi-user environments where local users or containers may reach vulnerable kernel paths.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged or low-privileged user, such as through a shell account, compromised application, container escape precondition, or another foothold. They then attempt to reach the vulnerable authencesn crypto path by causing the kernel to perform an out-of-place decryption operation using the affected algorithm or a subsystem that relies on it. By carefully controlling buffer sizes, source and destination separation, and cryptographic operation parameters, the attacker triggers the flawed handling of the high-order sequence bits. The resulting memory corruption occurs in kernel space. Depending on kernel configuration, memory layout, hardening features, and exploit reliability, this may lead to a kernel panic, controlled corruption useful for privilege escalation, or leakage/tampering of sensitive kernel memory.

How to fix it

Upgrade the Linux kernel to a vendor-fixed release that includes the upstream fix for the authencesn out-of-place decryption handling issue. No exact fixed package versions were provided in the input, so use the relevant distribution advisory for the deployed kernel stream, including RHEL, Ubuntu, Debian, SUSE, Amazon Linux, Alpine, Android-derived kernels, or appliance/vendor-maintained kernels. After installing the fixed kernel, reboot into the patched kernel and remove or de-prioritize older vulnerable kernels where operationally safe. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling or avoiding configurations that use affected authencesn/IPsec crypto paths when feasible, and applying kernel hardening controls such as lockdown, module restrictions, SELinux/AppArmor, seccomp, container isolation, and least-privilege execution.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not just the installed package, is at a vendor release that documents the authencesn fix. Use commands such as `uname -a`, distribution package queries, and vendor advisory metadata to compare the active kernel against the fixed release. Reboot validation is important because Linux hosts often keep running an older vulnerable kernel after package installation. If source or build metadata is available, confirm that the kernel contains the change preventing placement of the high-order sequence bits at the end of the destination buffer for out-of-place authencesn decryption. For exposure validation, inventory systems that load or expose the authencesn algorithm via `/proc/crypto`, use IPsec/XFRM, or allow untrusted local users, containers, or workloads to interact with kernel crypto functionality.

Typical attack path

1. Gain local execution on a Linux system as a low-privileged user or process.
2. Identify whether the running kernel includes the vulnerable authencesn crypto implementation and whether the relevant crypto/IPsec path is reachable.
3. Prepare a cryptographic operation that performs out-of-place decryption where source and destination buffers are distinct.
4. Trigger the vulnerable authencesn code path with crafted operation parameters to corrupt kernel memory.
5. Use the crash or corruption primitive to cause denial of service, or attempt to shape the corruption into privilege escalation or sensitive memory exposure.
6. Clean up artifacts where possible, such as temporary exploit binaries, shell history, or abnormal crypto/IPsec test commands.

How to detect it

To assess whether this was already exploited, review host telemetry and system logs for kernel memory-corruption symptoms around the vulnerable component. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump directories such as `/var/crash`, kernel oops/panic reports, EDR process telemetry, auditd logs, and any centralized SIEM ingestion of kernel logs. Look for oopses, panics, KASAN/KFENCE reports, slab corruption, general protection faults, or page faults that mention `authencesn`, `crypto`, `esp`, `xfrm`, scatter-gather buffers, or memory corruption. Investigate local processes that executed unusual crypto test tools, IPsec configuration commands, exploit-like binaries in temporary directories, or repeated attempts preceding kernel instability. Also review changes to IPsec/XFRM configuration and suspicious local account activity, especially on multi-user systems. Absence of these artifacts does not prove non-exploitation, because successful kernel exploitation may leave minimal logs or may only appear as unexplained privilege escalation or system instability.

• authencesn
• crypto/authencesn.c
• crypto: authencesn
• Oops:
• kernel BUG
• general protection fault
• BUG: KASAN:
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• BUG: unable to handle kernel paging request
• PANIC:
• Kernel panic
• slab corruption
• corrupted list
• /proc/crypto
• /var/crash
• ip xfrm
• setkey
• swanctl
• ipsec

What your security team should do

• Prioritize patching Linux systems that allow local user access, run multi-tenant workloads, host containers, or use IPsec/ESP or kernel cryptographic features.
• Track vendor advisories for the exact kernel package fixed versions applicable to each distribution and ensure systems reboot into the corrected kernel.
• Hunt for recent kernel crashes, oops events, KASAN reports, slab corruption, or general protection faults mentioning authencesn or crypto code paths.
• Review privileged changes to IPsec/XFRM configuration and unusual local use of AF_ALG or kernel crypto interfaces around the suspected exposure window.
• Restrict untrusted local execution paths and strengthen container isolation while patch rollout is in progress.
• Because this is not currently KEV-listed and EPSS remains low, balance urgency against operational reboot windows, but do not defer indefinitely due to the potential for high-impact local privilege escalation.