CVE-2026-23268
Received Received - Intake
Confused Deputy Vulnerability in Linux AppArmor Enables Privileged Policy Manipulation

Publication date: 2026-03-18

Last updated on: 2026-04-18

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: apparmor: fix unprivileged local user can do privileged policy management An unprivileged local user can load, replace, and remove profiles by opening the apparmorfs interfaces, via a confused deputy attack, by passing the opened fd to a privileged process, and getting the privileged process to write to the interface. This does require a privileged target that can be manipulated to do the write for the unprivileged process, but once such access is achieved full policy management is possible and all the possible implications that implies: removing confinement, DoS of system or target applications by denying all execution, by-passing the unprivileged user namespace restriction, to exploiting kernel bugs for a local privilege escalation. The policy management interface can not have its permissions simply changed from 0666 to 0600 because non-root processes need to be able to load policy to different policy namespaces. Instead ensure the task writing the interface has privileges that are a subset of the task that opened the interface. This is already done via policy for confined processes, but unconfined can delegate access to the opened fd, by-passing the usual policy check.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-18
Last Modified
2026-04-18
Generated
2026-05-07
AI Q&A
2026-03-18
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel's AppArmor system allows an unprivileged local user to perform privileged policy management actions. Specifically, the user can load, replace, and remove security profiles by exploiting a confused deputy attack. This is done by passing an opened file descriptor (fd) of the apparmorfs interface to a privileged process and tricking that process into writing to the interface on the user's behalf.

Although this requires a privileged target process that can be manipulated, once access is gained, the attacker can fully manage AppArmor policies. This includes removing confinement, causing denial of service by denying execution, bypassing user namespace restrictions, and potentially exploiting kernel bugs to escalate privileges.

The vulnerability arises because the policy management interface cannot simply have its permissions restricted to root-only, as non-root processes need to load policies into different namespaces. The fix ensures that the task writing to the interface has privileges that are a subset of the task that opened it, preventing unconfined processes from delegating access improperly.


How can this vulnerability impact me? :

If exploited, this vulnerability allows an unprivileged local user to gain control over AppArmor policy management, which can have serious security implications.

  • Removing confinement protections, potentially allowing malicious actions without restriction.
  • Causing denial of service (DoS) by denying execution of system or target applications.
  • Bypassing unprivileged user namespace restrictions, which can lead to broader system compromise.
  • Exploiting kernel bugs for local privilege escalation, potentially gaining root access.

How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

I don't know


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, ensure that the task writing to the apparmorfs interface has privileges that are a subset of the task that opened the interface.

This is already enforced via policy for confined processes, but unconfined processes can delegate access to the opened file descriptor, bypassing the usual policy check.

Changing the permissions of the policy management interface from 0666 to 0600 is not a viable solution because non-root processes need to load policy to different policy namespaces.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart