CrackArmor - When Your Linux Security Tool Gives Away Root

In one of the most ironic twists in recent Linux security history, AppArmor—a kernel module explicitly designed to enforce mandatory access controls and restrict privileges—has been found harboring a vulnerability that allows unprivileged users to gain full root access.

Dubbed “CrackArmor” by the Qualys Threat Research Unit (TRU), this chain of vulnerabilities (including CVE-2026-23268 and CVE-2026-23269) has been lurking in the Linux kernel since version 4.11 in 2017. Here is a breakdown of how this exploit works, what to look for in your logs, and how to secure your systems.

The Mechanics: A Classic “Confused Deputy”

CrackArmor is fundamentally a “confused deputy” flaw. A confused deputy vulnerability occurs when an unprivileged user tricks a highly privileged program into performing actions on the user’s behalf.

In Linux, AppArmor profiles are managed by interacting with pseudo-files located at /sys/kernel/security/apparmor/.load, .replace, and .remove. While these files are technically world-writable, the kernel security module strictly checks the permissions of the calling process before applying any changes. If a standard user tries to echo data into these files, the kernel blocks it with a “Permission denied” error.

However, attackers can bypass this by exploiting su or sudo—programs that run as root via the setuid flag. By piping standard error data through the su binary directly into the AppArmor pseudo-files, the kernel sees the root-owned su process executing the write and allows the action.

The Exploit Chain: Turning Mail into a Root Shell

The most fascinating part of CrackArmor is how attackers weaponize this arbitrary profile loading to achieve Local Privilege Escalation (LPE).

1. Deny Capabilities: The attacker uses the su trick to load a malicious AppArmor profile that specifically denies the CAP_SETUID capability to the sudo binary.
2. Trigger the Deputy: The attacker runs a sudo command with a user that is not in the sudoers file.
3. The Postfix Handoff: When sudo fails, it attempts to send an alert email to the administrator using postfix. Normally, sudo drops its root privileges before executing postfix.
4. The Trap: Because AppArmor has denied the CAP_SETUID capability, sudo silently fails to drop its root privileges. It proceeds to execute postfix as root while maintaining the attacker’s environment variables.
5. Root Shell: The attacker passes a custom MAIL_CONFIG environment variable pointing to their own configuration directory, executing arbitrary scripts as root via the Postfix process.

The Impact

The impact of CrackArmor is severe, affecting any distribution that enables AppArmor by default, including Ubuntu, Debian, and SUSE.

• Local Privilege Escalation (LPE): Unprivileged local users can easily escalate to root.
• Container Breakouts: Because AppArmor forms the trust boundary for Linux confinement, compromising it collapses container isolation and sandbox restrictions.
• Denial of Service (DoS): Attackers can remove deeply nested AppArmor subprofiles, which exhausts the kernel stack and triggers a forced system reboot via a kernel panic. They can also load “deny-all” profiles to immediately block legitimate remote access.

Spotting Exploit Attempts in Your Logs

CrackArmor is highly detectable if you know what to look for. Because the exploit relies on manipulating AppArmor via atypical processes, your kernel logs (dmesg or /var/log/kern.log) will tell the story.

Normal Behavior:

[ 20.382371] audit: type=1400 audit(1774679268.301:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="Discord" pid=1952 comm="apparmor_parser"

Why it’s normal: The operation="profile_load" was initiated by comm="apparmor_parser". This is the legitimate system utility designed to parse and load AppArmor profiles.

Malicious Behavior (Exploit Indicators): If an attacker attempts this exploit, you will see anomalies where unexpected binaries attempt to interface with AppArmor pseudo-files. Look out for:

• Atypical Commands: Audit logs showing comm="su" or comm="sudo" performing profile loads or removes.
• Malformed Profile Names: The video transcript notes that when standard error is piped into the .remove file, the system attempts to remove a profile named after the raw error output. You might see logs complaining that a profile does not exist, containing bizarre strings of terminal output instead of a clean application name.
• [cite_start]Denied Actions: If the attacker messes up the pipeline, you will see apparmor="DENIED" logs for standard users trying to write to /sys/kernel/security/apparmor/ pseudo-files.

Mitigations & How to Check for Updates

Patching is the only reliable way to fix this vulnerability, as interim mitigations do not restore the broken kernel logic.

1. Monitor Profiles: Immediately set up alerts for unauthorized or unexpected modifications inside /sys/kernel/security/apparmor/.
2. Scan for Exposure: If you use vulnerability scanners, QIDs such as 386714 and 6032579 have been released to flag vulnerable hosts.
3. Update Your Kernel: Because this is a kernel-level implementation flaw, you must apply the latest security patches provided by your Linux distribution.

You just have to wait for kernel updates to solve the core issue.

How to check for and apply kernel updates:

• Ubuntu CrackArmor Updates

For Questing Quokka (25.10), sudo is actually sudo-rs, where sudo and su are written in Rust, and this package is not affected by this vulnerability.

For Debian/Ubuntu-based systems:

sudo apt update
sudo apt list --upgradable | grep linux-image
sudo apt upgrade

For SUSE-based systems:

sudo zypper refresh
sudo zypper list-updates | grep kernel
sudo zypper update

Note: You must reboot your system after applying a kernel update for the new kernel to take effect.

---

Resources

• Original Qualys Blog Post: CrackArmor: Critical AppArmor Flaws Enable Local Privilege Escalation to Root
• Low Level Security Vulnerability Walkthrough on Youtube
• • Ubuntu CrackArmor Updates