Linux: Improper Privilege Management

What to do

1. Update Linux to 93d4ba49d18e3d7fb41a9927c2d0cca5e9dfefd6 or 15b828a46f305ae9f05a7c16914b3ce273474205 or 4709234fd1b95136ceb789f639b1e7ea5de1b181 or 8f907d345bae8f4b3f004c5abc56bf2dfb851ea7, whichever matches your release line, or a later version.
2. Update Linux Kernel to 3.17 or 4.5 or 4.9 or 5.10.256, whichever matches your release line, or a later version.

Affected products and versions

Version data comes from the organisation that assigned the CVE; 4 further products are omitted here. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector

LocalThe attacker needs local access or must trick a user into running something.

Attack complexity

LowNo special conditions are needed; the attack works reliably.

Privileges required

LowA basic user account is enough.

User interaction

NoneNo action by a victim is required.

Scope

UnchangedImpact stays within the vulnerable component.

Confidentiality

HighAll data handled by the component can be read.

Integrity

HighData or code can be modified at will.

Availability

NoneAvailability is not affected.

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. Scored by CNA.

Official description

In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Improper Privilege Management

Timeline

1. May 15, 2026CVE record published.
2. May 21, 2026CISA published its SSVC assessment (exploitation: poc, automatable: no, technical impact: total).
3. November 10, 2026Record last changed materially (score, affected products, status or references).

References

Recent Improper Privilege Management vulnerabilities

• 7.2 High severity

  open-webui: Improper Privilege Management

  CVE-2026-45395May 15, 2026Open WebUI
• 8.1 High severity

  open-webui: Improper Privilege Management

  CVE-2026-45675May 15, 2026Open WebUI
• 8.8 High severity

  Frontend Admin by DynamiApps: Improper Privilege Management

  CVE-2026-6228May 15, 2026Shabti
• 8.8 High severity

  CRM: Improper Privilege Management

  CVE-2026-42289May 12, 2026ChurchCRM
• 8.8 High severity

  grav: Improper Privilege Management

  CVE-2026-42844May 12, 2026Grav
• 8.8 High severity

  wiki: Improper Privilege Management

  CVE-2026-44224May 12, 2026Requarks

Spotted an error? Tell us.