← Back to Cybersecurity News Center
Severity
CRITICAL
Priority
0.465
×
Tip
Pick your view
Analyst for full detail, Executive for the short version.
Analyst
Executive
Executive Summary
Qualys researchers disclosed nine privilege escalation vulnerabilities in Linux AppArmor, collectively named CrackArmor, affecting Linux kernel 4.11 and later across an estimated 12.6 million enterprise Linux instances including Ubuntu, Debian, and SUSE (per Qualys researcher disclosure). An unprivileged local user can exploit these flaws to gain root access, escape container isolation, and bypass kernel address randomization, undermining a foundational security control across containerized workloads and multi-tenant environments. Vendor patches are available as of March 2026; no CVE identifiers have been assigned, which blocks automated scanner detection and requires manual triage and patching.
Impact Assessment
CISA KEV Status
Not listed
Attack Vector
HIGH
Exploitable remotely over the internet
Complexity
HIGH
No special conditions required to exploit
Authentication
HIGH
No credentials needed — anyone can attempt
User Interaction
HIGH
Fully automated — no user action needed
Active Exploitation
LOW
No confirmed active exploitation
Affected Product
INFO
Linux kernel 4.11+ (all distributions with AppArmor enabled); Ubuntu, Debian, SUSE; Kubernetes on AppArmor-enabled hosts; Sudo; Postfix, estimated 12.6 million enterprise Linux instances
Are You Exposed?
⚠
You use Linux kernel 4.11+ (all distributions with AppArmor enabled); Ubuntu, Debian, SUSE; Kubernetes on AppArmor-enabled hosts; Sudo; Postfix, estimated 12.6 million enterprise Linux instances → Investigate immediately
⚠
Affected systems are internet-facing → Increased attack surface
✓
You have patched to the latest version → Reduced risk
✓
Systems are behind network segmentation / WAF → Mitigated exposure
Assessment estimated from CVSS base score (no vector available)
Business Context
Qualys researchers disclosed nine privilege escalation vulnerabilities in Linux AppArmor, collectively named CrackArmor, affecting Linux kernel 4.11 and later across an estimated 12.6 million enterprise Linux instances including Ubuntu, Debian, and SUSE (per Qualys researcher disclosure). An unprivileged local user can exploit these flaws to gain root access, escape container isolation, and bypass kernel address randomization, undermining a foundational security control across containerized workloads and multi-tenant environments. Vendor patches are available as of March 2026; no CVE identifiers have been assigned, which blocks automated scanner detection and requires manual triage and patching.
Technical Analysis
CrackArmor comprises nine confused deputy vulnerabilities (CWE-269, CWE-610, CWE-264, CWE-284) in the Linux kernel AppArmor mandatory access control module, present since kernel 4.11 (2017).
Attack vector is local; an unprivileged user manipulates AppArmor security profiles via pseudo-file interfaces exposed by the kernel.
Exploitation paths include: local privilege escalation to root (T1068 , T1548.001 ), container escape on Kubernetes and AppArmor-enabled hosts (T1611 ), bypass of Ubuntu user namespace restrictions, KASLR offset leakage enabling follow-on memory corruption attacks (T1212 ), and hijack execution flow via profile manipulation (T1574 , T1203 ).
CVSS base score is assessed at 9.5 (Critical) by Qualys researchers; official CVSS rating from NVD/vendor pending CVE assignment. No CVE identifiers assigned at time of disclosure, preventing standard NVD/scanner-based detection. Affected systems: Linux kernel 4.11+ with AppArmor enabled; Ubuntu, Debian, SUSE distributions; Kubernetes deployments on AppArmor-enabled nodes; Sudo and Postfix where AppArmor profiles are active. Ubuntu has published patch guidance in the sources section. No public CVE IDs; track via CrackArmor advisory identifier from Qualys and Ubuntu USN tracking. EPSS and CISA KEV data not yet available at time of this report.
Action Checklist IR ENRICHED
Triage Priority:
IMMEDIATE
Escalate to CISO/incident commander if any unpatched multi-tenant host or Kubernetes production cluster node cannot be patched within 72 hours; escalate to external IR firm if compromise indicators (privilege escalation logs, container escape events, kernel address space modifications) are detected in forensic analysis post-discovery.
1
Step 1, Patch immediately: Apply AppArmor kernel patches per Ubuntu advisory and equivalent vendor advisories for Debian and SUSE. Prioritize Kubernetes nodes, multi-tenant hosts, and any system where unprivileged users have local shell access.
IR Detail
Eradication
NIST 800-61r3 §3.2.5
NIST SI-2 (Flaw Remediation)
CIS 3.4 (Address Unauthorized Software)
Compensating Control
For environments without centralized patch management: (1) Use `apt list --upgradable | grep linux` (Ubuntu/Debian) or `zypper list-updates | grep kernel` (SUSE) to identify kernel versions; (2) manually download kernel images from official vendor repositories; (3) test in non-production VM first using `uname -r` to verify kernel version post-reboot; (4) schedule maintenance windows and document each patched host in a spreadsheet with hostname, previous kernel version, new version, and patch date.
Preserve Evidence
Before patching: capture `uname -a`, `cat /etc/os-release`, `sudo aa-status --json > apparmor_baseline.json`, and `cat /proc/cmdline` on all target hosts. Preserve kernel version in syslog (check `/var/log/syslog` or `/var/log/messages` for boot records). Post-patch, compare `uname -r` output and re-capture `aa-status` to confirm profile loading. For Kubernetes: `kubectl get nodes -o wide` and `kubectl describe node <nodename>` to document kernel versions across cluster.
2
Step 2, Audit AppArmor enforcement mode: Run 'sudo aa-status' on all Linux hosts to confirm profiles are in enforce mode, not complain mode. Hosts in complain mode receive no active protection and are fully exposed until patched.
IR Detail
Preparation
NIST 800-61r3 §3.1.1
NIST SI-6 (Security Functionality Verification)
CIS 4.1 (Ensure Audit Logging is Enabled)
Compensating Control
On hosts without root access: (1) request `aa-status` output from system owner via ticket system and document in spreadsheet; (2) parse `/var/lib/apparmor/profiles.db` if readable (shows loaded profiles); (3) check `/sys/module/apparmor/parameters/enabled` — if returns '1', AppArmor is loaded; (4) review `/var/log/syslog` or `/var/log/messages` for 'apparmor=' boot parameter to detect complain mode in dmesg; (5) cross-reference against Kubernetes API: `kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, apparmor: .metadata.annotations}'`
Preserve Evidence
Capture full `aa-status --json` output (or `aa-status` plaintext) for every host; save to timestamped file per hostname. Record enforcement vs. complain mode decision (grep for 'enforce' vs. 'complain' in output). Extract profile names, loaded count, and unloaded profile list. For Kubernetes: capture node annotations and labels that indicate AppArmor runtime (`container.apparmor.security.beta.kubernetes.io/*`). Document in audit log which nodes were verified and on what date.
3
Step 3, Inventory affected hosts: Enumerate all Linux systems running kernel 4.11 or later with AppArmor enabled. Cross-reference against container orchestration inventory (Kubernetes nodes, Docker hosts) and multi-tenant environments. No CVE IDs exist yet; do not rely on vulnerability scanners alone.
IR Detail
Preparation
NIST 800-61r3 §3.1.2
NIST CM-8 (Information System Component Inventory)
CIS 1.1 (Utilize an Inventory of Hardware Assets)
Compensating Control
Manual inventory without CMDB: (1) export host lists from DNS (`dig axfr @nameserver domain.com`), DHCP logs, or network switches (MAC address tables via SSH); (2) iterate using `for host in $(cat hosts.txt); do ssh $host 'echo $host; uname -r; aa-status' >> inventory.csv; done`; (3) for Kubernetes, use `kubectl get nodes --all-namespaces -o wide | awk '{print $1, $7}' > k8s_nodes.txt`; (4) correlate Docker hosts by checking `docker ps -a` across orchestration systems; (5) identify multi-tenant systems by checking `/etc/passwd` for unprivileged user count and container runtime socket permissions (`ls -la /run/docker.sock`, `/var/run/cri.sock`).
Preserve Evidence
Create baseline inventory document: hostname, IP, kernel version (via `uname -r`), AppArmor enabled status (via `aa-status`), container runtime type and version (via `docker --version`, `cri-cli --version`), and date verified. Export to CSV for cross-reference analysis. For Kubernetes: capture `kubectl get nodes -o json > k8s_baseline.json` and `kubectl describe nodes > k8s_node_details.txt`. Store all inventory snapshots in version control or timestamped backup to detect drift. Record which systems have unprivileged user shell access via `/etc/shells` and active sudo policies (`sudo -l`).
4
Step 4, Restrict local access on unpatched hosts: Where patching cannot occur immediately, restrict local interactive login to privileged accounts only on affected hosts. Review and tighten user namespace policies (sysctl kernel.unprivileged_userns_clone) as a compensating control on Ubuntu systems.
IR Detail
Containment
NIST 800-61r3 §3.2.3
NIST AC-3 (Access Enforcement)
NIST AC-2 (Account Management)
CIS 5.2.1 (Ensure permissions on /etc/ssh/sshd_config are configured)
Compensating Control
(1) On unpatched hosts, disable unprivileged user namespace creation (root user action): `echo 'kernel.unprivileged_userns_clone = 0' | sudo tee -a /etc/sysctl.conf && sudo sysctl -p`; (2) restrict SSH login to specific group: modify `/etc/ssh/sshd_config` and add `AllowGroups admin sudo root` (adjust group names per environment), then `sudo systemctl restart sshd`; (3) audit current sessions via `who`, `w`, `ps aux | grep bash` and log off unauthorized users; (4) restrict console login via `/etc/login.defs` and `pam_listfile` in `/etc/pam.d/login` to block unprivileged accounts; (5) use sudo rules (`sudoedit /etc/sudoers`) to allow only approved escalation paths and log all sudo attempts via `sudo visudo` with `Defaults use_pty, Defaults log_input, Defaults log_output`.
Preserve Evidence
Before restriction: capture baseline SSH configuration (`scp root@host:/etc/ssh/sshd_config sshd_config.baseline`), current active user sessions (`w > sessions_baseline.txt`), sudo policies (`sudo -l -U <user> > sudo_baseline.txt` for each user), and sysctl AppArmor/namespace settings (`sysctl -a | grep -E 'apparmor|userns' > sysctl_baseline.txt`). After restriction: verify changes took effect by attempting login as unprivileged user and documenting rejection in `/var/log/auth.log`. Capture new sysctl state and sshd config with timestamps. Retain baseline configs for recovery documentation.
5
Step 5, Notify stakeholders and update detection rules: Inform infrastructure owners and container platform teams of exposure scope. Add CrackArmor-specific monitoring logic (see detection guidance) to SIEM and EDR rules. Reassess AppArmor profile coverage as a standing GRC control after patch deployment and track for CVE assignment to enable future scanner-based validation.
IR Detail
Post-Incident
NIST 800-61r3 §3.4.1
NIST IR-6 (Incident Reporting)
NIST SI-4 (Information System Monitoring)
CIS 6.2 (Activate audit logging)
Compensating Control
For organizations without SIEM: (1) configure rsyslog centralization on unpatched hosts — edit `/etc/rsyslog.d/50-default.conf` to forward auth and kernel logs to central syslog server: `*.* @@syslog-server:514`; (2) on central syslog, create alert rules via `grep` to detect CrackArmor exploitation patterns: `apparmor.*DENIED.*ns_capable|capable`, `audit.*priv_capable`, `sudo.*COMMAND.*ns_create`; (3) export syslog alerts to CSV weekly via `grep -E 'pattern' /var/log/syslog > weekly_audit.csv`; (4) set file-integrity monitoring via `aide --init && aide --check` (or `tripwire`, `samhain`) on critical files (`/etc/apparmor.d/*`, `/etc/sudoers*`, kernel binaries); (5) establish manual log review cadence (daily for patched systems, 4x daily for unpatched multi-tenant hosts).
Preserve Evidence
Document detection rule logic in plaintext (SIEM query examples or regex patterns); capture baseline alert volumes before and after rule deployment to establish signal-to-noise ratio. Record all rule changes in change management log with approval chain. Archive pre-detection-rule baseline logs for 90 days to enable retroactive threat hunting post-patch. Document notification date, recipients, and stakeholder acknowledgment in incident tracker. Post-patch, execute full profile audit (`aa-status --json`) monthly and store timestamped snapshots to verify persistent compliance. Maintain CVE tracking spreadsheet with CrackArmor link, planned patch date, actual patch date, and scanner re-validation date once CVE IDs are assigned.
Recovery Guidance
Post-containment, validate all patched systems with `aa-status --json` to confirm profiles reload correctly at boot and function in enforce mode. Audit all user accounts created or modified during the exposure window (check `/var/log/auth.log` for usermod, useradd, and sudoers changes) and reset passwords for privileged accounts. Perform threat hunt across affected infrastructure for lateral movement artifacts: search logs for unexpected sudo/su attempts, namespace creation, container process escapes, and kernel module loads (check dmesg and `/var/log/audit/audit.log` for apparmor=, cap_*, and execve patterns indicating exploitation attempts).
Key Forensic Artifacts
/var/log/auth.log (sudo, ssh, user login attempts; search for 'priv' and 'apparmor DENIED')
/var/log/syslog or /var/log/messages (kernel and AppArmor enforcement events; parse for 'apparmor=' and 'audit' lines)
/var/log/audit/audit.log or auditctl output (privilege escalation, namespace creation, and capability violations; requires ausearch queries)
Memory dumps or /proc/*/maps (evidence of kernel address space layout and potential KASLR bypass attempts; search for suspicious module addresses)
Container runtime logs (/var/log/docker.log, /var/log/cri-containerd.log, or kubelet logs /var/log/pods/*/kubelet.log; search for escape/exec anomalies and SELinux/AppArmor denial patterns)
Detection Guidance
No CVE identifiers have been assigned; standard vulnerability scanner detection is not available. Use the following manual and behavioral detection approaches.
Kernel and AppArmor log review: Monitor /var/log/kern.log and /var/log/syslog for AppArmor policy load events from unprivileged user contexts; entries containing 'apparmor' with profile load or replace operations initiated outside of root or system processes are anomalous. Pseudo-file access monitoring: Use auditd rules to watch for open/write operations on /sys/kernel/security/apparmor/ by non-root processes. Example auditd rule: '-w /sys/kernel/security/apparmor -p rwxa -k crackarmor_probe'. Privilege escalation indicators: Alert on process trees where a non-root process spawns a root-privileged child without a corresponding sudo or setuid binary in the ancestry chain (T1068 , T1548.001 ). Container escape indicators: On Kubernetes nodes, monitor for processes executing outside expected container namespaces using tools such as Falco. Example Falco rule condition (adapt to your environment): 'spawned_process and not container and container.id != host'. KASLR leak activity: Monitor for unexpected reads of /proc/kallsyms or /proc/modules by unprivileged users, which may indicate reconnaissance preceding a KASLR-bypass exploit chain (T1212 ). Restrict access: 'sysctl -w kernel.kptr_restrict=2'. Patch verification: After applying fixes, confirm kernel version upgrade with 'uname -r' and verify AppArmor module version with 'apparmor_parser --version'. Cross-reference against patched version identifiers published in the Ubuntu USN advisory.
Platform Playbooks
Microsoft Sentinel / Defender
CrowdStrike Falcon
AWS Security
🔒
Microsoft 365 E3
3 log sources
Basic identity + audit. No endpoint advanced hunting. Defender for Endpoint requires separate P1/P2 license.
🛡
Microsoft 365 E5
18 log sources
Full Defender suite: Endpoint P2, Identity, Office 365 P2, Cloud App Security. Advanced hunting across all workloads.
🔍
E5 + Sentinel
27 log sources
All E5 tables + SIEM data (CEF, Syslog, Windows Security Events, Threat Intelligence). Analytics rules, playbooks, workbooks.
Hard indicator (direct match)
Contextual (behavioral query)
Shared platform (review required)
No IOCs or MITRE techniques available for query generation.
No actionable IOCs for CrowdStrike import (benign/contextual indicators excluded).
No hard IOCs available for AWS detection queries (contextual/benign indicators excluded).
Compliance Framework Mappings
T1611
T1574
T1068
T1212
T1203
T1548.001
AC-6
SC-7
SI-2
SI-3
SI-4
AC-3
5.4
6.8
6.1
6.2
7.3
7.4
+1
MITRE ATT&CK Mapping
T1611
Escape to Host
privilege-escalation
T1574
Hijack Execution Flow
persistence
T1068
Exploitation for Privilege Escalation
privilege-escalation
T1212
Exploitation for Credential Access
credential-access
T1203
Exploitation for Client Execution
execution
T1548.001
Setuid and Setgid
privilege-escalation
Guidance Disclaimer
The analysis, framework mappings, and incident response recommendations in this intelligence
item are derived from established industry standards including NIST SP 800-61, NIST SP 800-53,
CIS Controls v8, MITRE ATT&CK, and other recognized frameworks. This content is provided
as supplemental intelligence guidance only and does not constitute professional incident response
services. Organizations should adapt all recommendations to their specific environment, risk
tolerance, and regulatory requirements. This material is not a substitute for your organization's
official incident response plan, legal counsel, or qualified security practitioners.
View All Intelligence →